[PPlay] GUI - 1st summary (3/3)

[WareWolf@chris2.mayn.de (WareWolf)]

Hi Adrian,


AR> > (1) User input
AR> > --------------
AR> >
[...]
AR> > Keyboard input is needed almost exclusively in form of keystrokes
AR> > (together with modifiers such al shift, ctrl etc), so there should be a
[...]
AR> We need key press and key released events.

You mean for some key repeat function?
This would be handled internally by the GUI system (precisely: the  
keyboard buffer).


AR> > (5) Windows (not the @³+$%&§#@+* thing from M$!)
AR> > -----------
AR> >
AR> > My personal preference would be to let the windows provide a "virtual
AR> > screen", i.e. simulate a screen (with appropriate dimensions, color
AR> > depth and frame buffer), in which other objects etc can be drawn - just
AR> > like the "real" "main" screen.
AR> Framebuffer?  Does this mean things drawn into the window get drawn
AR> into a different block of memory from that of their parent window?

I again changed my mind - I don't think that would be a good Idea for  
windows (it's simply far too inefficient).

But there certainly will be some widget simulating a "screen" including  
framebuffer and several 2d layers.

The framebuffer is here important because I don't want to have to wait for  
OpenGL finish drawing in this "SubScreen" before being able to draw to the  
screen myself.

AR> That seems very odd.  Maybe what you mean can be satisfied like this:
AR>   The 2d api provides surfaces.  A surface can be defined which is
AR> a region of a parent surface (much like an XImage can have a subimage).
AR> So we can say each window owns such a surface.

Yes, this will be the behavior of "usual" windows (and I don't think we  
will need "unusual" ones...).


Cu
        Christian


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