Hello all,
i can't find any sources which using a HostWindowPlugin (Areithfa Ffenestri) from language side. Can anyone provide some pointers?
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/
- Bert -
2008/9/14 Bert Freudenberg bert@freudenbergs.de:
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 -
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 bert@freudenbergs.de:
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 johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
2008/9/14 John M McIntosh johnmci@smalltalkconsulting.com:
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
Thanks for details. 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.
Btw, I can't find the platform sources for unix port. Is they exist or not?
On Sep 14, 2008, at 1:43 AM, Igor Stasenko wrote:
2008/9/14 Bert Freudenberg bert@freudenbergs.de:
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 johnmci@smalltalkconsulting.com 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.
Cheers, - Andreas
2008/9/15 Andreas Raab andreas.raab@gmx.de:
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.
Thanks for pointers. I'm looking forward for virtualizing a Display part to make it easier to use multiple Displays, and, of course, use it in Hydra.
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.
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.
Cheers,
- Andreas
Igor Stasenko wrote:
2008/9/15 Andreas Raab andreas.raab@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]
Cheers, - Andreas
2008/9/15 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
2008/9/15 Andreas Raab andreas.raab@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
Am 15.09.2008 um 15:36 schrieb Igor Stasenko:
2008/9/15 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
2008/9/15 Andreas Raab andreas.raab@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 -
squeak-dev@lists.squeakfoundation.org