2008/9/13 Michael Rueger <[EMAIL PROTECTED]>: > 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
