On Thu, 19 Aug 2004 14:33:37 +0200, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > > I was wondering what is the plan to deal with layered widgets ( i.e. > > widgets that cover each other ) ? Currently this doesn't seem to work, > > and some gtk code that works fine in X11 is not working with dfb. I > > couldn't find the code implementing z-order for subsurfaces or > > surfaces. > > There's no code in DirectFB dealing with the z-order of sub surfaces, > because there is neither an order nor any hierarchy except the capability > to be a sub surface. > > The order is defined by the application, or in this case by GDK.
I'm trying to understand where should I look for the z-order code, so far I couldn't find any GDK code that implements this. My feeling was that they assume the windowing system ( x11, win32 ) deals with the hierarchy and hiding obscured widgets. In java - there is a well known problem with mixing AWT and Swing widgets, since swing implements its own zorder and awt uses the native window system - the result is unpredictible behavior and broken order. My assumption was that the z-order should be implemented as low as possible - since multiple widget sets could be used in the same application. > > I tried to change the code to use CreateSurface or CreateWindow for > > the childs - but so far I get the same problem, no layering works. > > CreateWindow() and CreateSurface() allocate extra memory which would > grow quickly if they are called for each child window. In X11 only the > root window is allocated in memory, other windows are embedded in this > window like the sub surfaces are in DirectFB toplevel windows. I understand, it makes sense to use gdk SubSurfaces for child widgets - I was just trying to find a fix to the ordering problem. > > Also, looking at the sources I couldn't find where ( and how ) the > > parent/child relation between surfaces and windows is implemented. > > You'd have to look at the GDK DirectFB sources, or even GTK? I looked at both. It seems GTK does some ordering for window-less widgets ( button, etc ), the problem happens only with widgets that have a gdk window - in our case SWT is forcing gtk_fixed to get a gdk window with gtk_fixed_set_has_window. I don't know why SWT does this - but if I remove the call to has_window, a lot of stuff breaks. > > If you provide a small example which works in GDK X11, but doesn't in > GDK DirectFB, I will try to fix it. I'll try to write the equivalent gdk code and send it to you. > I think there was a bug with obscured widgets, e.g. using tabbed dialogs. Yes, obscured widgets are the main problem - if anything changes, a repaint happens and they end up on top. I wonder if this has some performance implications as well - if obscured widgets wouldn't get paint event it may be faster. Costin
