[Pharo-project] Throwing out the windowing support from core VM features
Hello, i'd like to discuss with you this quite radical idea. I , in particular, not happy that windowing in squeak VM is mandatory. Sure, you can run VM with -headless (or whatever), but this actually not solving anything, since VM still in much of control, how to deal with squeak window and how to manage messages etc. What i would like to see, is to completely detach windowing functionality into a separate VM plugin, making sure that: a) VM can be built w/o this plugin b) a language side is in total control to decide whether create and use window & display or not. This would require to deprecate some of 'blue book' primitives, which coming as built-in VM features , such as: - displayBits & friends - fullDisplayUpdate - keyboard & mouse event handling The point is, that squeak grew out on many platforms and embedded devices. Some of them don't have a usual input devices, like keyboard & mouse, so it is completely pointless to require VM to support I/O with these devices as mandatory option. Same for display. I would be happy to have full control at language side whether i need display or not , instead of having it 'for free' from a start and then using workarounds to not show/use it using command line (while language side still thinks its present). -- Best regards, Igor Stasenko AKA sig.
this sounds interesting. But I think that this is important to still be able to not rely on external libraries when you want. so what is the exact difference between having it for free or optional - ? that you need to implement the primitive on platform where you do not need? - ? that the system is not layered in consequence? Did you check the work made around "ffnestraria" ? Then what is important is to have good more then proof of concepts. This is sometimes that we would be interested in. Stef On Sep 13, 2008, at 8:58 AM, Igor Stasenko wrote:
Hello,
i'd like to discuss with you this quite radical idea. I , in particular, not happy that windowing in squeak VM is mandatory. Sure, you can run VM with -headless (or whatever), but this actually not solving anything, since VM still in much of control, how to deal with squeak window and how to manage messages etc.
What i would like to see, is to completely detach windowing functionality into a separate VM plugin, making sure that: a) VM can be built w/o this plugin b) a language side is in total control to decide whether create and use window & display or not.
This would require to deprecate some of 'blue book' primitives, which coming as built-in VM features , such as: - displayBits & friends - fullDisplayUpdate - keyboard & mouse event handling
The point is, that squeak grew out on many platforms and embedded devices. Some of them don't have a usual input devices, like keyboard & mouse, so it is completely pointless to require VM to support I/O with these devices as mandatory option. Same for display. I would be happy to have full control at language side whether i need display or not , instead of having it 'for free' from a start and then using workarounds to not show/use it using command line (while language side still thinks its present).
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/9/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
this sounds interesting. But I think that this is important to still be able to not rely on external libraries when you want. so what is the exact difference between having it for free or optional - ? that you need to implement the primitive on platform where you do not need? - ? that the system is not layered in consequence?
I think both. Having it 'for free' leads developers to think that they can use it anytime, anywhere, like in String>>showProgressBar. Which from my POV is complete stupidity. And now just check different mailing lists and count complains about unable to getting rid of such 'free' uses, like asking for user input or showing warnings in headless image :) I don't want it 'for free', but instead, i want that language should ask for it, and then, if VM could provide it - start using it. Instead of having 'position & size & fullscreen flag' hanging around in VM -obviously, with good design, this should be completely at language side.
Did you check the work made around "ffnestraria" ?
Surely, this could be taken as a initial base for new plugin. But, as it reads on http://wiki.squeak.org/squeak/3862 : This architecture is for the lowest levels of the system, the virtual machine and dungeon levels of the image. NO support yet exists for Morphic since there is a vast amount of code and class cleanup needed. Tweak has been our sole higher level target thus far since it is somewhat less broken, not to mention the target of our main project remit. Since Pharo now actively adressing different Morphic issues, it would be good for those who doing it (hello Gary) to keep this idea in mind. On embedded systems you don't have a 'window', you just have a display. But on PCs, operating system can provide you many windows , which can play role as displays. What is bad, that at language side you don't have a notion about this, as well as it don't have notion whether keys/mouse are present or not. I think this should be represented by concrete classes, which can answer things like: - hasKeyboard(s) - hasMouse(s) - hasDisplay - hasWindowing for instance, on windoze, you can use a real display using two approached: - one can prefer using a display (which covers a whole area of screen), and should be allowed to control its resolution (if possible). - another one can rather use windowing and treat separate native windows as separate displays.
Then what is important is to have good more then proof of concepts. This is sometimes that we would be interested in.
Stef
-- Best regards, Igor Stasenko AKA sig.
ohh... a small correction. Not #hasDisplay, but #hasDisplays. Which is conceptually VERY important! -- Best regards, Igor Stasenko AKA sig.
Hi Igor, I like your idea very much. This is what a modular should be. This is exactly the way Squeak-GTK is taking. I am waiting for Gwenael to have a version that runs on MacOSX... Cheers, Alexandre On 13 Sep 2008, at 08:58, Igor Stasenko wrote:
Hello,
i'd like to discuss with you this quite radical idea. I , in particular, not happy that windowing in squeak VM is mandatory. Sure, you can run VM with -headless (or whatever), but this actually not solving anything, since VM still in much of control, how to deal with squeak window and how to manage messages etc.
What i would like to see, is to completely detach windowing functionality into a separate VM plugin, making sure that: a) VM can be built w/o this plugin b) a language side is in total control to decide whether create and use window & display or not.
This would require to deprecate some of 'blue book' primitives, which coming as built-in VM features , such as: - displayBits & friends - fullDisplayUpdate - keyboard & mouse event handling
The point is, that squeak grew out on many platforms and embedded devices. Some of them don't have a usual input devices, like keyboard & mouse, so it is completely pointless to require VM to support I/O with these devices as mandatory option. Same for display. I would be happy to have full control at language side whether i need display or not , instead of having it 'for free' from a start and then using workarounds to not show/use it using command line (while language side still thinks its present).
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Igor Stasenko wrote:
ohh... a small correction. Not #hasDisplay, but #hasDisplays.
Which is conceptually VERY important!
And Ffenestri provides support for that. We actually have something running (sort of ;-) ) that opens multiple native windows based on ffenestri. I'm all for factoring out the input and display stuff into plugins, ffenestri is IMHO a good base for that. You can still use bitblt or balloon for display, so you don't necessarily have to rely on external libraries as GTK does. IIRC the newer VMs already delay opening the window and only do it on first access, so a first step in the right direction. But this, again, raises the question of VM building ;-) Michael
2008/9/13 Michael Rueger <m.rueger@acm.org>:
Igor Stasenko wrote:
ohh... a small correction. Not #hasDisplay, but #hasDisplays.
Which is conceptually VERY important!
And Ffenestri provides support for that. We actually have something running (sort of ;-) ) that opens multiple native windows based on ffenestri.
I'm all for factoring out the input and display stuff into plugins, ffenestri is IMHO a good base for that. You can still use bitblt or balloon for display, so you don't necessarily have to rely on external libraries as GTK does.
Right, a good factored code should rely on a basic OS functionality provided. There is no need in extra dependencies on that.
IIRC the newer VMs already delay opening the window and only do it on first access, so a first step in the right direction.
Yeah, but i would prefer to receive a direct instruction from language side to open window/display. And if any code tries to talk or draw things w/o asking anyone if it possible at all, then it should be beaten by exceptions.
But this, again, raises the question of VM building ;-)
Well, i think most of work is on language side, not in VM. First we should consider a model, which can be employed to represent an abstract layer for display and user input. Then, based on it, we can determine a set of primitives required to support such model.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote:
2008/9/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
this sounds interesting. But I think that this is important to still be able to not rely on external libraries when you want. so what is the exact difference between having it for free or optional - ? that you need to implement the primitive on platform where you do not need? - ? that the system is not layered in consequence?
I think both. Having it 'for free' leads developers to think that they can use it anytime, anywhere, like in String>>showProgressBar. Which from my POV is complete stupidity. And now just check different mailing lists and count complains about unable to getting rid of such 'free' uses, like asking for user input or showing warnings in headless image :)
sure this is something that we should fix from an infrastructural point of view using a notification system. At the end we should not that PopUpMenu everywhere but only in one place in the Plafform code.
I don't want it 'for free', but instead, i want that language should ask for it, and then, if VM could provide it - start using it. Instead of having 'position & size & fullscreen flag' hanging around in VM -obviously, with good design, this should be completely at language side.
Did you check the work made around "ffnestraria" ?
Surely, this could be taken as a initial base for new plugin. But, as it reads on http://wiki.squeak.org/squeak/3862 :
This architecture is for the lowest levels of the system, the virtual machine and dungeon levels of the image. NO support yet exists for Morphic since there is a vast amount of code and class cleanup needed.
Yes I think that we should go slowly but removing a lot of morphic cruft will help.
Tweak has been our sole higher level target thus far since it is somewhat less broken, not to mention the target of our main project remit.
Since Pharo now actively adressing different Morphic issues, it would be good for those who doing it (hello Gary) to keep this idea in mind.
Yes
On embedded systems you don't have a 'window', you just have a display. But on PCs, operating system can provide you many windows , which can play role as displays. What is bad, that at language side you don't have a notion about this, as well as it don't have notion whether keys/mouse are present or not. I think this should be represented by concrete classes, which can answer things like: - hasKeyboard(s) - hasMouse(s) - hasDisplay - hasWindowing
for instance, on windoze, you can use a real display using two approached: - one can prefer using a display (which covers a whole area of screen), and should be allowed to control its resolution (if possible). - another one can rather use windowing and treat separate native windows as separate displays.
Then what is important is to have good more then proof of concepts. This is sometimes that we would be interested in.
Stef
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sep 13, 2008, at 10:25 AM, Michael Rueger wrote:
Igor Stasenko wrote:
ohh... a small correction. Not #hasDisplay, but #hasDisplays. Which is conceptually VERY important!
And Ffenestri provides support for that. We actually have something running (sort of ;-) ) that opens multiple native windows based on ffenestri.
I'm all for factoring out the input and display stuff into plugins, ffenestri is IMHO a good base for that. You can still use bitblt or balloon for display, so you don't necessarily have to rely on external libraries as GTK does.
So this is good.
IIRC the newer VMs already delay opening the window and only do it on first access, so a first step in the right direction.
But this, again, raises the question of VM building ;-)
yes!
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/9/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote:
2008/9/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
this sounds interesting. But I think that this is important to still be able to not rely on external libraries when you want. so what is the exact difference between having it for free or optional - ? that you need to implement the primitive on platform where you do not need? - ? that the system is not layered in consequence?
I think both. Having it 'for free' leads developers to think that they can use it anytime, anywhere, like in String>>showProgressBar. Which from my POV is complete stupidity. And now just check different mailing lists and count complains about unable to getting rid of such 'free' uses, like asking for user input or showing warnings in headless image :)
sure this is something that we should fix from an infrastructural point of view using a notification system. At the end we should not that PopUpMenu everywhere but only in one place in the Plafform code.
I don't want it 'for free', but instead, i want that language should ask for it, and then, if VM could provide it - start using it. Instead of having 'position & size & fullscreen flag' hanging around in VM -obviously, with good design, this should be completely at language side.
Did you check the work made around "ffnestraria" ?
Surely, this could be taken as a initial base for new plugin. But, as it reads on http://wiki.squeak.org/squeak/3862 :
This architecture is for the lowest levels of the system, the virtual machine and dungeon levels of the image. NO support yet exists for Morphic since there is a vast amount of code and class cleanup needed.
Yes I think that we should go slowly but removing a lot of morphic cruft will help.
Tweak has been our sole higher level target thus far since it is somewhat less broken, not to mention the target of our main project remit.
Since Pharo now actively adressing different Morphic issues, it would be good for those who doing it (hello Gary) to keep this idea in mind.
Yes
On embedded systems you don't have a 'window', you just have a display. But on PCs, operating system can provide you many windows , which can play role as displays. What is bad, that at language side you don't have a notion about this, as well as it don't have notion whether keys/mouse are present or not. I think this should be represented by concrete classes, which can answer things like: - hasKeyboard(s) - hasMouse(s) - hasDisplay - hasWindowing
for instance, on windoze, you can use a real display using two approached: - one can prefer using a display (which covers a whole area of screen), and should be allowed to control its resolution (if possible). - another one can rather use windowing and treat separate native windows as separate displays.
Then what is important is to have good more then proof of concepts. This is sometimes that we would be interested in.
Stef
Concerning Display & Forms & BitBlt with connection with host window: We already have everything we need in VM!! The only thing which is required to wire things up. Here is components which need to be merged (to work together): - SurfacePlugin & HostWindowPlugin on VM side - DisplayScreen class need to be refactored to create new host window and ask for its surface (which in own turn should be registered by HostWindowPlugin using SurfacePlugin interface). There are also an example in platforms/Cross/plugins/ExampleSurfacePlugin , how to create & register own surface and how to use it at language side. So, we really can throw out almost all windowing stuff from core VM, leaving HostWindowPlugin to handle things. Initially, i guess, that most changes will affect the Display var and DisplayScreen class. For headless mode , a Display could be replaced by NoDisplayScreen - which simply ignoring all calls LazyDisplayScreen - which sits in Display global var until first drawing attempt, and then creates a window and replacing itself by working DisplayScreen. -- Best regards, Igor Stasenko AKA sig.
Thing was even easier than i first thought. I installed the changesets from here: ftp://ftp.smalltalkconsulting.com/experimental/Ffenestri/ Ffenestri-b-2-WindowProxies.3.cs Ffenestri-b-3-MultiHostWindows-Sunits.1.cs Ffenestri-b-3-MultiHostWindows.1.cs Ffenestri-b-4-Events-Morphic.1.cs And did few own changes (see attachment). It can render morphic in a window created by hostwindow plugin. The fix was, to remove a code which ignoring the events from non-main window :) Now, the goal is to create some kind of Display manager, refactor some code to associate an instance of PasteUpMorph with Display instance. Get rid of all direct references to Display - replace it by self defaultDisplay. (or self currentDisplay). and dispatch event handling & drawing based on targeted window/display. I hope someone could help me with that refactoring.. I tried to make a batch for replacing Display refs to message send, but failed. I'm not very good in refactoring tools.. I tried to replace text in all methods with Display: (CompiledMethod allInstances select: [:each | each literals anySatisfy: [:lit | lit isVariableBinding and: [lit key == #Display] ]]) But refactoring based on text source is error prone, it would be good to use RB refactoring to make it precisely. On windoze almost everything is functional - of course there is some visual glitches, but code is stable and not crashing image even when you'll save the image with replaced Display! Try the code yourself. Just file in the changes, and then do: DisplayHostWindow installAsDisplay and when you done: Display uninstall to revert to usual Display 2008/9/13 Igor Stasenko <siguctua@gmail.com>:
2008/9/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote:
2008/9/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
this sounds interesting. But I think that this is important to still be able to not rely on external libraries when you want. so what is the exact difference between having it for free or optional - ? that you need to implement the primitive on platform where you do not need? - ? that the system is not layered in consequence?
I think both. Having it 'for free' leads developers to think that they can use it anytime, anywhere, like in String>>showProgressBar. Which from my POV is complete stupidity. And now just check different mailing lists and count complains about unable to getting rid of such 'free' uses, like asking for user input or showing warnings in headless image :)
sure this is something that we should fix from an infrastructural point of view using a notification system. At the end we should not that PopUpMenu everywhere but only in one place in the Plafform code.
I don't want it 'for free', but instead, i want that language should ask for it, and then, if VM could provide it - start using it. Instead of having 'position & size & fullscreen flag' hanging around in VM -obviously, with good design, this should be completely at language side.
Did you check the work made around "ffnestraria" ?
Surely, this could be taken as a initial base for new plugin. But, as it reads on http://wiki.squeak.org/squeak/3862 :
This architecture is for the lowest levels of the system, the virtual machine and dungeon levels of the image. NO support yet exists for Morphic since there is a vast amount of code and class cleanup needed.
Yes I think that we should go slowly but removing a lot of morphic cruft will help.
Tweak has been our sole higher level target thus far since it is somewhat less broken, not to mention the target of our main project remit.
Since Pharo now actively adressing different Morphic issues, it would be good for those who doing it (hello Gary) to keep this idea in mind.
Yes
On embedded systems you don't have a 'window', you just have a display. But on PCs, operating system can provide you many windows , which can play role as displays. What is bad, that at language side you don't have a notion about this, as well as it don't have notion whether keys/mouse are present or not. I think this should be represented by concrete classes, which can answer things like: - hasKeyboard(s) - hasMouse(s) - hasDisplay - hasWindowing
for instance, on windoze, you can use a real display using two approached: - one can prefer using a display (which covers a whole area of screen), and should be allowed to control its resolution (if possible). - another one can rather use windowing and treat separate native windows as separate displays.
Then what is important is to have good more then proof of concepts. This is sometimes that we would be interested in.
Stef
Concerning Display & Forms & BitBlt with connection with host window: We already have everything we need in VM!! The only thing which is required to wire things up.
Here is components which need to be merged (to work together): - SurfacePlugin & HostWindowPlugin on VM side - DisplayScreen class need to be refactored to create new host window and ask for its surface (which in own turn should be registered by HostWindowPlugin using SurfacePlugin interface).
There are also an example in platforms/Cross/plugins/ExampleSurfacePlugin , how to create & register own surface and how to use it at language side.
So, we really can throw out almost all windowing stuff from core VM, leaving HostWindowPlugin to handle things.
Initially, i guess, that most changes will affect the Display var and DisplayScreen class. For headless mode , a Display could be replaced by NoDisplayScreen - which simply ignoring all calls LazyDisplayScreen - which sits in Display global var until first drawing attempt, and then creates a window and replacing itself by working DisplayScreen.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
sounds cool I have the eyes blinking of excitment :) But I'm on mac :) Stef On Sep 14, 2008, at 9:13 AM, Igor Stasenko wrote:
Thing was even easier than i first thought.
I installed the changesets from here: ftp://ftp.smalltalkconsulting.com/experimental/Ffenestri/
Ffenestri-b-2-WindowProxies.3.cs Ffenestri-b-3-MultiHostWindows-Sunits.1.cs Ffenestri-b-3-MultiHostWindows.1.cs Ffenestri-b-4-Events-Morphic.1.cs
And did few own changes (see attachment).
It can render morphic in a window created by hostwindow plugin. The fix was, to remove a code which ignoring the events from non- main window :)
Now, the goal is to create some kind of Display manager, refactor some code to associate an instance of PasteUpMorph with Display instance. Get rid of all direct references to Display - replace it by self defaultDisplay. (or self currentDisplay).
and dispatch event handling & drawing based on targeted window/ display. I hope someone could help me with that refactoring.. I tried to make a batch for replacing Display refs to message send, but failed. I'm not very good in refactoring tools.. I tried to replace text in all methods with Display: (CompiledMethod allInstances select: [:each | each literals anySatisfy: [:lit | lit isVariableBinding and: [lit key == #Display] ]]) But refactoring based on text source is error prone, it would be good to use RB refactoring to make it precisely.
On windoze almost everything is functional - of course there is some visual glitches, but code is stable and not crashing image even when you'll save the image with replaced Display!
Try the code yourself. Just file in the changes, and then do:
DisplayHostWindow installAsDisplay
and when you done:
Display uninstall
to revert to usual Display
2008/9/13 Igor Stasenko <siguctua@gmail.com>:
2008/9/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote:
2008/9/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
this sounds interesting. But I think that this is important to still be able to not rely on external libraries when you want. so what is the exact difference between having it for free or optional - ? that you need to implement the primitive on platform where you do not need? - ? that the system is not layered in consequence?
I think both. Having it 'for free' leads developers to think that they can use it anytime, anywhere, like in String>>showProgressBar. Which from my POV is complete stupidity. And now just check different mailing lists and count complains about unable to getting rid of such 'free' uses, like asking for user input or showing warnings in headless image :)
sure this is something that we should fix from an infrastructural point of view using a notification system. At the end we should not that PopUpMenu everywhere but only in one place in the Plafform code.
I don't want it 'for free', but instead, i want that language should ask for it, and then, if VM could provide it - start using it. Instead of having 'position & size & fullscreen flag' hanging around in VM -obviously, with good design, this should be completely at language side.
Did you check the work made around "ffnestraria" ?
Surely, this could be taken as a initial base for new plugin. But, as it reads on http://wiki.squeak.org/squeak/3862 :
This architecture is for the lowest levels of the system, the virtual machine and dungeon levels of the image. NO support yet exists for Morphic since there is a vast amount of code and class cleanup needed.
Yes I think that we should go slowly but removing a lot of morphic cruft will help.
Tweak has been our sole higher level target thus far since it is somewhat less broken, not to mention the target of our main project remit.
Since Pharo now actively adressing different Morphic issues, it would be good for those who doing it (hello Gary) to keep this idea in mind.
Yes
On embedded systems you don't have a 'window', you just have a display. But on PCs, operating system can provide you many windows , which can play role as displays. What is bad, that at language side you don't have a notion about this, as well as it don't have notion whether keys/mouse are present or not. I think this should be represented by concrete classes, which can answer things like: - hasKeyboard(s) - hasMouse(s) - hasDisplay - hasWindowing
for instance, on windoze, you can use a real display using two approached: - one can prefer using a display (which covers a whole area of screen), and should be allowed to control its resolution (if possible). - another one can rather use windowing and treat separate native windows as separate displays.
Then what is important is to have good more then proof of concepts. This is sometimes that we would be interested in.
Stef
Concerning Display & Forms & BitBlt with connection with host window: We already have everything we need in VM!! The only thing which is required to wire things up.
Here is components which need to be merged (to work together): - SurfacePlugin & HostWindowPlugin on VM side - DisplayScreen class need to be refactored to create new host window and ask for its surface (which in own turn should be registered by HostWindowPlugin using SurfacePlugin interface).
There are also an example in platforms/Cross/plugins/ExampleSurfacePlugin , how to create & register own surface and how to use it at language side.
So, we really can throw out almost all windowing stuff from core VM, leaving HostWindowPlugin to handle things.
Initially, i guess, that most changes will affect the Display var and DisplayScreen class. For headless mode , a Display could be replaced by NoDisplayScreen - which simply ignoring all calls LazyDisplayScreen - which sits in Display global var until first drawing attempt, and then creates a window and replacing itself by working DisplayScreen.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig. <HostWindowsDisplay. 1.cs>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/9/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
sounds cool I have the eyes blinking of excitment :) But I'm on mac :)
You should try it. There are much more support for Macs than for windoze in these changesets. I had to add own Win32 specific subclass to make it working on windoze. My wish behind all of this is to provide clean separation between core VM and UI. Then, in Hydra each image could create and manage own windows. I just installed an Ubuntu, lets see how far i can get with building squeak VM + freetype on it. I never tried to build squeak on linux, but i expect it will be much easier than on windows.
Stef On Sep 14, 2008, at 9:13 AM, Igor Stasenko wrote:
Thing was even easier than i first thought.
I installed the changesets from here: ftp://ftp.smalltalkconsulting.com/experimental/Ffenestri/
Ffenestri-b-2-WindowProxies.3.cs Ffenestri-b-3-MultiHostWindows-Sunits.1.cs Ffenestri-b-3-MultiHostWindows.1.cs Ffenestri-b-4-Events-Morphic.1.cs
And did few own changes (see attachment).
It can render morphic in a window created by hostwindow plugin. The fix was, to remove a code which ignoring the events from non-main window :)
Now, the goal is to create some kind of Display manager, refactor some code to associate an instance of PasteUpMorph with Display instance. Get rid of all direct references to Display - replace it by self defaultDisplay. (or self currentDisplay).
and dispatch event handling & drawing based on targeted window/display. I hope someone could help me with that refactoring.. I tried to make a batch for replacing Display refs to message send, but failed. I'm not very good in refactoring tools.. I tried to replace text in all methods with Display: (CompiledMethod allInstances select: [:each | each literals anySatisfy: [:lit | lit isVariableBinding and: [lit key == #Display] ]]) But refactoring based on text source is error prone, it would be good to use RB refactoring to make it precisely.
On windoze almost everything is functional - of course there is some visual glitches, but code is stable and not crashing image even when you'll save the image with replaced Display!
Try the code yourself. Just file in the changes, and then do:
DisplayHostWindow installAsDisplay
and when you done:
Display uninstall
to revert to usual Display
2008/9/13 Igor Stasenko <siguctua@gmail.com>:
2008/9/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote:
2008/9/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
this sounds interesting. But I think that this is important to still be able to not rely on external libraries when you want. so what is the exact difference between having it for free or optional - ? that you need to implement the primitive on platform where you do not need? - ? that the system is not layered in consequence?
I think both. Having it 'for free' leads developers to think that they can use it anytime, anywhere, like in String>>showProgressBar. Which from my POV is complete stupidity. And now just check different mailing lists and count complains about unable to getting rid of such 'free' uses, like asking for user input or showing warnings in headless image :)
sure this is something that we should fix from an infrastructural point of view using a notification system. At the end we should not that PopUpMenu everywhere but only in one place in the Plafform code.
I don't want it 'for free', but instead, i want that language should ask for it, and then, if VM could provide it - start using it. Instead of having 'position & size & fullscreen flag' hanging around in VM -obviously, with good design, this should be completely at language side.
Did you check the work made around "ffnestraria" ?
Surely, this could be taken as a initial base for new plugin. But, as it reads on http://wiki.squeak.org/squeak/3862 :
This architecture is for the lowest levels of the system, the virtual machine and dungeon levels of the image. NO support yet exists for Morphic since there is a vast amount of code and class cleanup needed.
Yes I think that we should go slowly but removing a lot of morphic cruft will help.
Tweak has been our sole higher level target thus far since it is somewhat less broken, not to mention the target of our main project remit.
Since Pharo now actively adressing different Morphic issues, it would be good for those who doing it (hello Gary) to keep this idea in mind.
Yes
On embedded systems you don't have a 'window', you just have a display. But on PCs, operating system can provide you many windows , which can play role as displays. What is bad, that at language side you don't have a notion about this, as well as it don't have notion whether keys/mouse are present or not. I think this should be represented by concrete classes, which can answer things like: - hasKeyboard(s) - hasMouse(s) - hasDisplay - hasWindowing
for instance, on windoze, you can use a real display using two approached: - one can prefer using a display (which covers a whole area of screen), and should be allowed to control its resolution (if possible). - another one can rather use windowing and treat separate native windows as separate displays.
Then what is important is to have good more then proof of concepts. This is sometimes that we would be interested in.
Stef
Concerning Display & Forms & BitBlt with connection with host window: We already have everything we need in VM!! The only thing which is required to wire things up.
Here is components which need to be merged (to work together): - SurfacePlugin & HostWindowPlugin on VM side - DisplayScreen class need to be refactored to create new host window and ask for its surface (which in own turn should be registered by HostWindowPlugin using SurfacePlugin interface).
There are also an example in platforms/Cross/plugins/ExampleSurfacePlugin , how to create & register own surface and how to use it at language side.
So, we really can throw out almost all windowing stuff from core VM, leaving HostWindowPlugin to handle things.
Initially, i guess, that most changes will affect the Display var and DisplayScreen class. For headless mode , a Display could be replaced by NoDisplayScreen - which simply ignoring all calls LazyDisplayScreen - which sits in Display global var until first drawing attempt, and then creates a window and replacing itself by working DisplayScreen.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig. <HostWindowsDisplay.1.cs>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor could you publish these changes in Squeaksource?
You should try it. There are much more support for Macs than for windoze in these changesets. I had to add own Win32 specific subclass to make it working on windoze.
My wish behind all of this is to provide clean separation between core VM and UI. Then, in Hydra each image could create and manage own windows.
I just installed an Ubuntu, lets see how far i can get with building squeak VM + freetype on it. I never tried to build squeak on linux, but i expect it will be much easier than on windows.
I hope.
2008/9/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Igor could you publish these changes in Squeaksource?
In what form? Changes include adding ivars to events. This kind of change can't be packaged into MC package. Or can? Also, i found that HostWindowPlugin missing platform sources for unix. At least in trunk SVN branch from which i trying to build VM. So, first before publishing them i need to make sure that they can work w/o HostWindowPluginÑ
You should try it. There are much more support for Macs than for
windoze in these changesets. I had to add own Win32 specific subclass to make it working on windoze.
My wish behind all of this is to provide clean separation between core VM and UI. Then, in Hydra each image could create and manage own windows.
I just installed an Ubuntu, lets see how far i can get with building squeak VM + freetype on it. I never tried to build squeak on linux, but i expect it will be much easier than on windows.
I hope.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Sep 14, 2008, at 12:39 PM, Igor Stasenko wrote:
My wish behind all of this is to provide clean separation between core VM and UI. Then, in Hydra each image could create and manage own windows.
To complicate things on os-x (macintosh, iPhone) any UI related calls can only be done on the main thread. Thus you cannot open a window, draw, or check the window size, etc on thread 27.... Solving this problem on os-x with the current macintosh VMs requires the VM to be clever. This clever coding does not work on the iPhone, although this is an open bug with Apple. For the iPhone we build a "graphic atom" for each display request. On the flush to screen call, we then bundle up the queued atoms and create a "frame update request" which is then executed as a frame region invalidate request on the main thread via a cross thread API call. This triggers (later) an update event on the main thread for the invalidated frame or frames, where we remove the frame update request or requests from the queue, and paint the queued frame updates Another issue which perhaps is not obvious is that FFI calls then might need to run on the main thread, some are not clear, for example executing many QuickTime calls (seemly non UI related) on a secondary thread causes a core dump. -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
2008/9/16 John M McIntosh <johnmci@smalltalkconsulting.com>:
On Sep 14, 2008, at 12:39 PM, Igor Stasenko wrote:
My wish behind all of this is to provide clean separation between core VM and UI. Then, in Hydra each image could create and manage own windows.
To complicate things on os-x (macintosh, iPhone) any UI related calls can only be done on the main thread. Thus you cannot open a window, draw, or check the window size, etc on thread 27....
Solving this problem on os-x with the current macintosh VMs requires the VM to be clever.
This clever coding does not work on the iPhone, although this is an open bug with Apple.
For the iPhone we build a "graphic atom" for each display request. On the flush to screen call, we then bundle up the queued atoms and create a "frame update request" which is then executed as a frame region invalidate request on the main thread via a cross thread API call. This triggers (later) an update event on the main thread for the invalidated frame or frames, where we remove the frame update request or requests from the queue, and paint the queued frame updates
Well, i don't see much problem with it. For instance, to get more uniform model, i wanted to rewrite UI events mechanism with events which i use in Hydra for passing any UI related events to interpreter. In this case, you could have an OS-dependent event sink in main thread, and then dispatch events to be handled in another thread(s). I think that event model, which i introduced in Hydra could do this quite efficiently and with no much complexity overhead. Same could be done in reverse order - when you need to invoke some function only from main thread - you could simply enqueue an event into main thread with proper function, and eventually it will be handled, calling your code and using your params..
Another issue which perhaps is not obvious is that FFI calls then might need to run on the main thread, some are not clear, for example executing many QuickTime calls (seemly non UI related) on a secondary thread causes a core dump.
Well, this kind of problem, fairly, is not related to VM - you can't guarantee thread safety from VM side if you allowing foreign calls. Some calls could work, some could crash a system - its completely depends on a functions which you calling.
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (5)
-
Alexandre Bergel -
Igor Stasenko -
John M McIntosh -
Michael Rueger -
Stéphane Ducasse