[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GUI - Comments



Hi Adrian,


AR> OK some thoughts  about the GUI.  I like it.

Thanks 8-)

AR> Here is the basis for a signal/slot mechanism similar to
AR> Qt.

It sounds good, but I'll have to reflect about it first (to fully  
understand it ;)


h4>> What kind(s) of target surface(s) for mouse
AR>  pointers should exist?</h4>
AR>
AR> Are you talking about the actual pixmap representing
AR> the mouse cursor? This can be handled nicely.

No. I mean the "area" or "base" on which the mouse pointer moves around.  
This is for example the screen.

AR> The 2d API can supply the outside with a surface
AR> which represents mouse pointers, as well as GC's
AR> for drawing into them.  These surfaces would bee
AR> representations for something defined in the GGI.

But that's also something to consider. I'd implement MPs as special  
sprites, but perhaps this one is better.


AR> <li>For Drag'n'Drop and similar mechanisms it
AR> is very useful if the
AR>  mouse pointer can temporarily take the look of
AR>  the dragged
AR> item or be merged with it.</li>

AR> Maybe not.  As far as the user is concerned,
AR> the mouse pointer is an object dragging the
AR> object conerned, they are distinct.  From a

For this I invented this "merging". Of course only internally. It would  
"merge" the pointer and the dragged object to one single pixmap / graphics  
object, so that it can easily be controlled by the mouse pointer code  
(without having some extra code waiting for the mouse ptr to be moved).

Of course this would be transparent to the programmer.

AR> while the mouse pointer would probably have to
AR> be a pixmap.

This however is more serious...


Cu
        Christian



Christian Reiniger (Germany)
e-mail: warewolf@chris2.mayn.de