Greg Ercolano wrote: > Michael Sweet wrote: >> Box types and symbols would be the traditional method. >> >> The base widgets and composite UI bits (scrollbar parts, tabs, and the >> various menu widgets) could use special box types that can be replaced >> (FL_BUTTON_BOX, FL_SCROLL_DOWN_BOX, etc.), with symbols for any icons >> (arrows for scrollbars, arrows for menu buttons, etc.) > > Mmm, this sounds familiar. > > Now that I think about it, this was brought up on fltk.general > a few years ago: > > "Smooth Boxtypes": > http://fltk.org/newsgroups.php?gfltk.general+v:21037 > http://fltk.org/newsgroups.php?gfltk.general+v:21038 > http://fltk.org/newsgroups.php?gfltk.general+v:21042 > http://www.satellite-music.de/smoothbox/ > > I should probably make an example on my cheat page > just so I don't forget..! > > I also forgot about the new gtk+ scheme that matthias reminds > the OP about in that thread. I should look at that, since that's > kinda what I want to achieve in my apps. > > Are things like the "plastic" and "gtk+" schemes implemented > using the public API, or are they also wired in at a lower level? > (I assume the latter, otherwise there'd probably be an example > test program showing how to do this.)
Aside from the Fl::scheme() integration, there is a small amount of "wire" in Fl_Light_Button, Fl_Menu, Fl_Scrollbar, and Fl_Slider draw methods. For Fl_Light_Button (which actually handles drawing the radio and check box buttons) and Fl_Menu we override the drawing of the checks and radio dots. These could be represented as box types and check/dot symbols and overridden using public APIs. For Fl_Slider and Fl_Scrollbar we add grippers to the scroller - again, this could be done using "gripper" box types (pressed and normal). -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
