stéphane ducasse wrote:
> Hi gunther
> 
> 
> I would not switch from dolphin to morphic, just for morphic.
> But it depends what you are doing.
> 
> Morphic deserves a massive clean (may be coming back to pre etoy  would 
> be a good move).

Hi

(sorry for interfering)

Maybe also interesting:
I do not know how these things worked in early Macs, but they had their 
own tricks to speed up rendering of windows and graphical elements.

http://www.folklore.org/StoryView.py?project=Macintosh&story=I_Still_Remember_Regions.txt&sortOrder=Sort%20by%20Date&detail=medium&search=regions

I do not really understand how it was realized, how should `drawOn:' 
work more effectively so that it heeds a given clipping region, but they 
apparently knew how to draw overlapping things fast.

(I have never neither worked nor programmed a Mac so I am not familiar 
with those mechanisms)

I only know that also in my morphs' onDraw: method I completely ignore 
the fact how much of it will be actually visible. I do not know how this 
  could be handled conveniently (without breaking my head in 
investigating what parts of the morphs will visible and which will be 
out of sight). Now my (and surely many other morphs) simply draw 
everything. This is the case of PlotMorph2 as well.

> When Morph was only 300 methods. Now the problem is that people with  
> the know how
> will not do it. Also the concurrency model of morphic is not really  good.
> 
> Stef

Long time ago someone liked the idea of Eveline
http://map1.squeakfoundation.org/sm/package/1a0f534c-423b-4cfa-a0d5-17a428eccc46
(but I do not use it actively now)
Maybe its "concurrency" model offered by mechanisms
	Entity after:schedule:
	Entity after:schedule:with:
	Entity after:schedule:with:with:
	Entity after:schedule:with:with:with:
	Entity after:schedule:withAll:
Some time before, someone
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-July/062155.html
noted that these mechanisms could be used also for Morphic. You can see 
for example:

	City beginCall

It is an "event handler". It, among other things, schedules new event with

    self
       after: (randomGenerator negExp: meanTimeBetweenCallAttempts)
       schedule: #beginCall.

They could replace the
	Morph step
	Morph stepTime
These scheduling (thanks to usage of the BidirectionaLinkedList) --- 
i.e. adding a new event to a calendar of events --- has constant time 
complexity. So there is no penalty. And they are little bit more general 
than simple stepping.

But I think that easier way how to make Morphic things clear would be to 
implement it from scratch. Utilization of traits could also heal some 
inherent problems of single inheritance, which caused bloating of the 
Morph class just because of two Morph subclasses in unrelated subtrees 
required to share the same method(s), there was no other way but put it 
to their common ancestor---Morph. Even though for lot of other 
subclasses those methods were useless. So Morph growed and growed.

And I agree that this could not be done if there is no skilled one 
dedicated full time working days and nights, months and years on this.

> 
> 
> On 25 août 05, at 19:26, Günther Schmidt wrote:
> 
> 
>> Tim,
>>
>> so, if the *right* people are working on it, Morphic can be made to  
>> go wooooosh?
>>
>> I've been thinking of switching from Dolphin to Squeak for a couple  
>> of reasons, Morphic in particular, because I just can't see how you  
>> could do the things you can do in Morphic as easily in Dolphin.
>>
>> There have been posts on this topic for some time now, so I guess  
>> it's something that resists fixing?
>>
>> Well in short, I'm asking whether it's reasonable to presume that  
>> this issue will be resolved any time soon or rather not to depend  on 
>> that?
>>
>> Günther
>>
>>
>>
>>
> 
> 
> 


-- 
Matej Košík