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
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
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
