manolo gouy wrote: > Albrecht: I have here a little lift to give to your morale :=)
Thanks, but my morale is okay. ;-) > The print demo no longer loose widgets, because > I removed a clip to window that works well (and is useful) under Mac > but made all these widgets disappear in the print demo page under MSWin. > This is in uploaded FLTK.pdf (Make sure to update your files > relatively to the changes I brought this morning to the svn). I had seen the clipping problems _after_ your removal of the window clipping from the Windows code. However, the print demo works now, and maybe there was an old file involved (the dependencies are not up-to-date, as we know). I'll update the makedepend files later today when I have more time. In fact I didn't see much difference with or w/o the Windows window clipping call. My experience was that it worked more or less, depending on if the print dialog occluded the main window or not. Thus, I thought that it had to do with some basic window clipping that came from the visibility of the main window (system clipping area ?). But I couldn't get a clue what was really happening... One more observation, though. Maybe you can compare with the Mac version: When I tried the unittests demo, I could see some red lines at the right side and the bottom in the "viewport" test. This looked as if the window clipping width and height were off by one pixel. I changed it to be w-1 and h-1, and the red lines disappeared. Of course, this was before you removed the clipping from the Windows code. Currently the red lines are visible at all four corners. I'm not sure if this is: (a) Windows specific (b) Fl_Printer specific (c) a general clipping question. > So we definitely have a clip problem under MSWindows. I am also > certain of that after having deactivated all clip statements > (add x=y=-1000; w=h=4000; at the top of fl_push_clip() function) > and having seen that the missing widgets of the scroll demo reappeared > together, though, with many others that needed be clipped away. Yep, tried it - confirmed. > I'll look in detail into this problem. Thanks very much! > Many thanks for having added as_group() and as_window(). > The corresponding code is so elegant in its simplicity! Yes, indeed. :-) > I'll change Fl_Printer::print_widget() using these new functions. Okay, that would be fine. > Could you consider adding "as_gl_window()" as well? This could be > useful for our print objective. An Fl_Gl_Window could be > detected and processed adequately, that is, with function glReadPixels > that reads the screen pixels of a GL window. I considered it, and I'm hesitating. I can see that we need a way to find out what kind of window we have, but I didn't want to add one function for each kind of window: maybe we would also need as_cairo_window(), overlay, glut, ... . And I certainly wouldn't want to add one function for each _widget_ type. But that's only my current opinion, or better: /feeling/. The main point I wanted to solve was to be able to distinguish widgets, groups, and windows. These are essential points in the widget hierarchy. There are also some flags() used for window types: menu_window and tooltip_window, and there is a proposal for xclass (or something similar) to use to distinguish window types. Maybe we can find a better way to get all this together, and [ thinking ... ] perhaps the best way would be to add a [virtual?] window_type() method to Fl_Window with another byte or int internal bit field. Maybe - I don't know. Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
