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.