On 9 Oct 2009, at 21:40, Jonathan wrote: >>> I'm trying to create an MDI (had to learn what it means...).
>> Pretty. But I don't see why that has to be (or would want to be) MDI. >> I don't much care for the MDI idiom, I admit. > > I like the MDI, I guess I'm going for a sort of SolidWorks look. On the basis of the screen-shots you show, I am not sure that you're app actually is MDI, so possibly you still are not quite grasping the difference between MDI and SDI here. Also, I would *very strongly* advise against basing your GUI design on any other app you happen to have liked in the past. What you must do is understand the workflow *for your application* and see what *your users* need to do, and develop the GUI to best suit that need. "Emulating" some established GUI design is rarely the best solution: You have know way of knowing what constraints the developers of the other app were dealing with, and why they made the design choices that they did make. It is very unlikely that your case will be the same... <rant mode> As a general aside, this habit of "copying" some existing well-known GUI is a common problem amongst linux developers, and accounts for a *lot* of why non-technical users find linux apps "clunky" - the developers have forced their application to fit some GUI idiom that is not best suited to the apps own natural flow... You never find Apple doing that. Indeed they spend a lot of time and money with proper designers doing the exact opposite. The end result is that end users rave about how well Apple apps work, despite the fact that under the skin they are often no better (sometimes worse) than the linux equivalent... </rant mode> >> A non-modal window with the border disabled would take you a long >> way, I suspect. > > Non-modal seems to do the trick. I managed to disable the border > and it looks just like without set_non_modal. Without adding the > windows to MainWin I can show them with just one call to show(). I > just had to tweak my Fl_DragBox widget a bit to accommodate the > lack of parent window. The only thing that bugs me a little is that > now the windows can move outside of MainWin. Well, first off, I don't generally think that constraining tool windows to lie inside the main window is actually a useful design idiom, so I don't see that as a problem. However, if you *do* want to constrain the tool windows, it is easy to do. If your tool windows are a derived class (I think yours are) then it is a simple matter to override the draw(), or perhaps the position() method, or both. Then maybe add a member var to your class that holds the bounding window (e.g. Fl_Window * bounding_win) which the constructor inits to NULL. In the draw() method (say) check if bounding_win is set - if it is, obtain the x,y,w,h of the bounding window and position your tool window accordingly... (else just draw the tool window wherever it happens to lie)... Job done. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
