On 2 Oct 2009, at 15:10, David Lopez wrote: > Thanks Ian and Roman for your remarks. > Here I give you more details about what I'm trying to do: > I'm developing a graphic editor to edit already existent > proprietary-format forms (GUIs). > Those forms usually contain block diagrams using hundreds of > rectangles, lines and polygons, that sometimes act as buttons. > It's common to have overlapping objects, as in the following > diagram in which there are two small boxes (2 and 3) over a big > background box (1). > > +----------------------------+ > | 1 | > | | > | +---------+ +---------+ | > | | 2 | | 3 | | > | | | | | | > | +---------+ +---------+ | > | | > +----------------------------+ > > The "z-axis position" is given by the order in which an object is > defined in the file (same phylosophy as FLTK) > It would be desirable that the editor could provide the function > "send to background / foreground" so that the user could create or > add objects in any order, and then adjust wich one is in background/ > foreground. > The only way I know to change the z-axis order in FLTK when the > objects are already created is to destroy them and then recreate > them in the desired order.
As Matt has already said - you probably don't have to destroy the objects, just remove them from the container widget they are in then re-add them in the "right place". I'm thinking this would work OK, but I'm not sure how confident I am that the rendering order will be exactly what you'd want for your z- order... Should be? I'm not sure - Matt seems to think it can't be guaranteed, and he knows this stuff... > Somebody has a better solution? I have "different" solution... I doubt it is better. A while back I was doing a little toy project that needed "buttons" rendered using OpenGL inside a GL context, and I found a demo that Matt had done showing something broadly similar - he had a container widget based on an Fl_Gl_Window and a class to derive subsidiary widgets from. So these subsidiary widgets all get added to the container widget, and it does all the drawing... The container widget's draw method creates the GL context then executes the draw methods of all its children in that context. This meant I could use GL to render the widgets, and do fancy lighting and alpha blending and textures and, you know, stuff. Didn't try to control the z-order of the widgets, but I can't see any reason why that wouldn't Just Work if the GL context was right. So, that might be an unnecessarily complicated way for you to get the effect you need? Certainly GL would have all the drawing primitives you'd need to render your forms, I imagine? -- Ian _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
