[squeak-dev] Looking for HostWindowPlugin usage code

>
> Am 13.09.2008 um 23:54 schrieb Igor Stasenko:
>
>> Hello all,
>>
>> i can't find any sources which using a HostWindowPlugin (Areithfa
>> Ffenestri) from language side.
>> Can anyone provide some pointers?
>
>
> AFAIK it has only been used with Tweak yet (which does not rely on global
> state like Morphic). Code should be at
>
> ftp://ftp.smalltalkconsulting.com/experimental/
>

> 2008/9/14 Bert Freudenberg <[hidden email]>:
>>
>> Am 13.09.2008 um 23:54 schrieb Igor Stasenko:
>>
>>> Hello all,
>>>
>>> i can't find any sources which using a HostWindowPlugin (Areithfa
>>> Ffenestri) from language side.
>>> Can anyone provide some pointers?
>>
>>
>> AFAIK it has only been used with Tweak yet (which does not rely on  
>> global
>> state like Morphic). Code should be at
>>
>> ftp://ftp.smalltalkconsulting.com/experimental/
>>
>
> Thanks. I'd like to know if there was any attempts to replace a
> default squeak window/display by this stuff.
> In the code i see there are a subclass of DisplayScreen. But there no
> methods found, which can install/deinstall a hostwindowproxy as
> display.
> i'm thinking that it is very good to move in that direction.
>
>> - Bert -
>>
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> The deal with tweak was that when we looked at it four years ago when Tim
> and I were building Areithfa Ffenestri.
> We found that it used instance variables to hold onto the Display and the
> Sensor.
> Lurking somewhere is a change set that ensured a new Window was setup with
> Areithfa Ffenestri and hooked into the
> newly created Tweak World, then the EventSensor polling loop would dispatch
> the incoming event to the proper Tweak World based on the window index that
> is on each event (if the VM supports it).
>
> Thus Tweak would poll it's instance based event queue, and dispatch incoming
> events, and when drawing was required it would resolve drawing to the
> instance variable
> that pointed to the proper window index, thus allowing drawing in individual
> windows based on the the Tweak World.
>
> However I think Michael has build more on this model for iSqueak
>

> On Sep 14, 2008, at 1:43 AM, Igor Stasenko wrote:
>
>> 2008/9/14 Bert Freudenberg <[hidden email]>:
>>>
>>> Am 13.09.2008 um 23:54 schrieb Igor Stasenko:
>>>
>>>> Hello all,
>>>>
>>>> i can't find any sources which using a HostWindowPlugin (Areithfa
>>>> Ffenestri) from language side.
>>>> Can anyone provide some pointers?
>>>
>>>
>>> AFAIK it has only been used with Tweak yet (which does not rely on global
>>> state like Morphic). Code should be at
>>>
>>> ftp://ftp.smalltalkconsulting.com/experimental/
>>>
>>
>> Thanks. I'd like to know if there was any attempts to replace a
>> default squeak window/display by this stuff.
>> In the code i see there are a subclass of DisplayScreen. But there no
>> methods found, which can install/deinstall a hostwindowproxy as
>> display.
>> i'm thinking that it is very good to move in that direction.
>>
>>> - Bert -
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>

> Igor Stasenko wrote:
>>
>> I think that same could be applied to morphic without much pain.
>> The point why i asking, i want to try to completely replace core VM
>> functionality with HostWindow plugin. To make all stuff concerning
>> windowing / display will be governed by HostWindowPlugin.
>
> As long as you're only planning to support a single window, it's pretty
> simple. As a matter of fact, check out the new Squeakland image - it
> includes a zoom mode which virtualizes all of the Display operations and
> something similar could easily be hooked into a Ffenestri backend.
>

> It gets much more tricky once you're trying to support more than one Morphic
> world though, since the assumption that there's only ever a single active
> Morphic world is so widely distributed in the code. Check this out, for
> example:
>
> SystemNavigation new browseAllSelect:[:cm|
>  (cm hasLiteral: (Smalltalk associationAt: #World))
>    or:[cm hasLiteral: (Smalltalk associationAt: #ActiveWorld)]]
>
> There are literally *hundreds* of references all over the places that
> require fixing, plus their senders, the senders of their senders etc. And
> there is even more to it than only those globals - text editing for example
> uses a single shared undo buffer which gets screwed up if you ever have more
> than a single editing context.
>
> 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.
>

> 2008/9/15 Andreas Raab <[hidden email]>:
>> 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.

> Igor Stasenko wrote:
>>
>> 2008/9/15 Andreas Raab <[hidden email]>:
>>>
>>> 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]
>

> 2008/9/15 Andreas Raab <[hidden email]>:
>> Igor Stasenko wrote:
>>>
>>> 2008/9/15 Andreas Raab <[hidden email]>:
>>>>
>>>> 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.