[Pharo-project] Throwing out the windowing support from core VM features

Igor Stasenko siguctua at gmail.com
Sat Sep 13 09:51:55 EDT 2008


2008/9/13 Stéphane Ducasse <stephane.ducasse at inria.fr>:
>
> On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote:
>
>> 2008/9/13 Stéphane Ducasse <stephane.ducasse at 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.


More information about the Pharo-dev mailing list