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 <[EMAIL PROTECTED]>:
2008/9/13 Stéphane Ducasse <[EMAIL PROTECTED]>:
On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote:
2008/9/13 Stéphane Ducasse <[EMAIL PROTECTED]>:
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
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
