Am 15.09.2008 um 15:36 schrieb Igor Stasenko:

> 2008/9/15 Andreas Raab <andreas.raab at gmx.de>:
>> Igor Stasenko wrote:
>>>
>>> 2008/9/15 Andreas Raab <andreas.raab at gmx.de>:
>>>>
>>>> BTW, when I wrote Tweak I had this scenario specifically in mind  
>>>> (i.e.,
>>>> potentially support multiple windows from within it) which is why  
>>>> it has
>>>> all
>>>> of these references localized. Fixing this in Morphic is going to  
>>>> be  a
>>>> major job.
>>>>
>>>
>>> Right. I don't plan to go deep with that now (any brave soul here?).
>>> As initial refactoring, i guess that it can be started by replacing
>>> all references to World with message 'self world' or 'self
>>> morphicWorld' , if first is ambiguous.
>>> Then there can be two basic implementations:
>>> Object>>morphicWorld
>>>  ^ self defaultMorphicWorld
>>>
>>> Morph>>morphicWorld
>>> ^ self topmostParent ifNil: [ self defaultMorphicWorld ]
>>>
>>> or something like that.
>>
>> Actually, the easiest way to deal with it is probably by  
>> associating the
>> Morphic world with the Morphic UI process. In other words, wherever  
>> you find
>> "World" or "ActiveWorld" you would replace this with "Processor  
>> activeWorld"
>> which would either return the world (if the process in question is  
>> a Morphic
>> UI process) or nil if it's not.
>>
>> Since concurrent Worlds would likely use concurrent Processes this  
>> should
>> work well, in particular considering that background processes now  
>> at least
>> have an indication that they aren't actually running in a Morphic  
>> process
>> (currently you can get into pretty weirdo situations if a  
>> background process
>> tries to open a browser or schedule a menu etc).
>>
>> This is also similar to Tweak where the active hand is managed as  
>> part of
>> the executing script (and the world can be obtained by querying  
>> that hand).
>>
>> [And do note that it's not enough since as mentioned earlier there  
>> are other
>> places that need fixing. But it's a start for sure]
>>
>
> But what you think, in general, is this good way to go, despite the  
> complexity?
> I'd really like to cut the knot of dependency from Display/UI in VM.
> This can and should be managed completely from the language side (the
> --headless startup command is cool, but it headless :).
> One image would want to have a UI, another - don't.
> Why this should be controlled from outside, isn't it would be better
> to say something like:
> Display disable/enable or HostWindowManager closeAllWindows /
> openNewWindow  in squeak.


The Mac VM already works that way. It does not open a window until the  
image requests one (via beDisplay).

- Bert -