Greg Ercolano wrote: > ... > I assume there's some 'better way' that other widget kits use > to allow redefining the look of base widgets. Is there some generally > accepted technique other widget kits offer for this?
Well, for most GTK+ themes you essentially define images, colors, fonts, etc. for every widget, much like CSS does for HTML. As you might expect there are performance issues with this approach, and GTK+ suffers from many of the same inefficiencies that Motif and Xt have (which use X resources instead of theme files). Both GTK+ and Qt support executable theme plugins as well; they use a similar method of overriding the drawing methods of widgets (and one of the plugins can read those theme files...) Of course, when you build a custom widget then many of the standard theme attributes often don't get applied... > ... > Kinda hacky. Is there a better way that fits the FLTK1 model? 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.) Then the theme/scheme just needs to override the special symbols and box types to affect every widget in an application, even custom widgets as long as they draw themselves using the standard UI boxtypes and symbols. Longer term we can look at supporting plugins that auto-register on application startup, however I'd be concerned about the performance impact... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
