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.

> Cheers,
>  - Andreas


-- 
Best regards,
Igor Stasenko AKA sig.