Hi,
I fully agree with OmniBrowser becoming the default browser.
I was merely questioning whether the current browser should remain (in the
image, or as a package), or disappear completely.
I assumed that it would need to remain - perhaps that assumption is
incorrect.

And, whatever the default browser happens to be, the integration issues with
regard to getting 'hooks' in the right place still remain.
For example, Shout highlighting in the Debugger will still require overrides
or hooks or patches of some kind.
Now, if there was an OmniDebugger...  :>)
Cheers,
Andy

----- Original Message ----- 
From: "stéphane ducasse" <ducasse at iam.unibe.ch>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, August 25, 2004 8:23 PM
Subject: Re: Lessons learnt from been an integrator


Hi nady

I agree but the code of the browser is crappy, buggy, fragile.
And we **all** need a browser that can change, evolve to meet our needs.
There are a lot of things that are really slwo to do with this browser
and 25 years
of good services may be enough.

Stef

On Aug 25, 2004, at 11:00 AM, Andrew Tween wrote:

> Hi,
> Replacing the default Browser with OmniBrowser *might* make things
> easier.
> However; the default browser would still need to be available, and if
> it is
> available then Shout should still work with it.
> So, whether the default browser remains part of the image, or is split
> out
> into a package, the problem of integrating with it remains the same.
> Then there is mvc - I don't know if OmniBrowser works under mvc (or
> could be
> made to work)??
>
> Although I have come up with one solution, for Shout, using
> AppRegistry,  it
> may not be the best solution.
> We should take some time to consider the options before making changes
> to
> the kernel.
> Perhaps an event model would be more flexible, for instance?
>     Browser triggers #needsCodeMorph , #needsCodeView, #builtMVCView,
> #builtMorphicView , etc. events.
>     And anything can handle those events and change the Browser's
> behaviour.
>
> I am not familiar with Services, I'll take a look.
>
> The big danger in all this is that we introduce a framework that leads
> to as
> many bugs as would be caused by simply allowing packages included in
> the
> full image to override kernel methods.
> So; we need to make kernel changes; but we need to consider carefully
> what
> those changes should be.
> If we are aiming to acheive this for 3.9, then there is no great rush.
> Cheers,
> Andy
>
> ----- Original Message -----
> From: "stéphane ducasse" <ducasse at iam.unibe.ch>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Wednesday, August 25, 2004 6:48 AM
> Subject: Re: Lessons learnt from been an integrator
>
>
> Hi andy
>
> We really think that we should really prepare 3.9 so that the system is
> made better to get new tool like yours.
>
> One possibility would also be to throw away the default browser and
> replace it by omnibrowser. If it is ready for that. Colin what do you
> think?
>
> So the first step is really to send the fix that can go in the kernel,
> thne identify what should be done at the kernel level, have you got a
> look at the services package because this would be really a good basis
> to support RB, shout integration.
> Stef
>
>
>
> On Aug 24, 2004, at 7:27 PM, Andrew Tween wrote:
>
>> With regard to the Full image / Shout / overridden methods ...
>>
>> I have done some work on splitting Shout into ...
>>     1. a changeset of base image changes.
>>         including an MvcTextEditor subclass of AppRegistry (similar to
>> MorphicTextEdtior, but for MVC)
>>
>>     2. a package that makes no changes to existing base image methods.
>>        (Although it does add new methods to base classes)
>>
>> I have achieved the above (see attached files).
>> However; I am not happy with they way the code is looking at the
>> moment.
>> There is a lot of duplication where I have had to create subclasses of
>> some
>> base classes, and some nasty hacks.
>>
>> So, it needs some further work; and a lot of testing - particularly in
>> mvc.
>> But I thought I'd  post what I have so far.
>>
>> Thanks to all who are working on the full image - which, in the
>> future, will
>> be even fuller ;>)
>> Cheers,
>> Andy
>>
>> ----- Original Message -----
>> From: "Marcus Denker" <denker at iam.unibe.ch>
>> To: "The general-purpose Squeak developers list"
>> <squeak-dev at lists.squeakfoundation.org>
>> Sent: Tuesday, August 24, 2004 3:51 PM
>> Subject: Re: Lessons learnt from been an integrator
>>
>>
>>
>> Am 24.08.2004 um 15:57 schrieb Hannes Hirzel:
>>
>>> Hello,
>>>
>>> stéphane ducasse wrote:
>>>> Hi all
>>>>
>>>> here are the lessons we learnt while building the 3.7 image. We
>>>> wanted
>>>> to have shout, rb, connector
>>>> morph in 3.7 but there were too much patches.
>>>
>>> What do you mean by this? Did the packages not load? Or did they
>>> overwrite
>>> important methods?
>> They overwrite many methods. It makes no sense at all to have a system
>> in beta for 4 Months and then change stuff a week before a release.
>>
>>> How did you find out?
>>>
>> By looking at the code?
>>
>>>
>>> Thank you Stef for this report.
>>>
>>> I learn that it is not possible to integrate Ned's connector morphs.
>>> What is the reason? Did you contact Ned? He is often amazing how fast
>>> he fixes things. I remember that he recently put out a new release.
>>> As SM is down currently I cannot check.
>>>
>> Ned posted *a lot* of fixed for morphic to the list. Many of those are
>> required
>> for Connectors, but not all of them got added to 3.7.
>>
>>> It would be very nice to have the connector morphs in 3.7 full. Or
>>> perhaps
>>> it is not a good idea to integrate something which
>>> has not been retested. I would be willing to retest 3.7 full with
>>> Ned's
>>> connector morphs included. However this will surely add a few days
>>> more.
>>>
>>
>> There is no way to add connectors to 3.7, as we can't add all the
>> patches.
>>
>> Maybe people should have put some effort into integrating all the
>> stuff
>> into 3.7
>> when it was possible, but somehow nobody wanted to do that back then.
>> I
>> wrote
>> lots of mails to the list that there is work to be done with regard to
>> harvesting, but
>> everyone seems to be thinking that it is not important.
>>
>>      Marcus
>>
>>
>>
>>
>>
>> ---
>> Outgoing mail is certified Virus Free.
>> Checked by AVG anti-virus system (http://www.grisoft.com).
>> Version: 6.0.716 / Virus Database: 472 - Release Date: 06/07/2004
>> <CodeEditorsUseAppRegistry.4.cs><Shout.3.15-tween.8.mcz>
>
>
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.716 / Virus Database: 472 - Release Date: 05/07/2004
>





---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.716 / Virus Database: 472 - Release Date: 05/07/2004