On 17.05.2012, at 09:03, Jim Jozwiak wrote: > One user criticized my application as too bright on the screen although I > prefer to think of it as "cheerful." Thus, I have been experimenting with > the plastic scheme. My application, Nut, looks horrid with the plastic > scheme because many widgets don't get plasticized. For instance, if I give a > widget some kind of SHADOW box attribute, FLTK does not do the color muting > on that widget, and also misses packs within scrolls within groups within > wizards. Even if the plastic scheme has no distinctive representation of a > shadow box, wouldn't it be logical to still use color muting to draw the > interior or background of all widgets if the whole app is brought up with the > plastic scheme? Am I misunderstanding how it is supposed to work?
The scheme interface in 1.3 is not too smart. The basic idea is to replace the functions that draw the standard box types (FL_UP_BOX, etc) with functions that draw other boxes. So if you need a better looking FL_SHADOW_BOX, simply use the API to provide a new function that draws one that matches better. (there is a bit more going on behind the scenes, for example differen arrow drawing code and a pattern on the slider boxes, but that's mostly it) http://www.fltk.org/doc-1.3/group__fl__drawings.html#ga475ff2bbcafeb30d4551f635e42d6259 http://www.fltk.org/doc-1.3/classFl.html#a73e0e8fefe8707817ca6fd6437c4869b http://www.fltk.org/doc-1.3/group__callback__functions.html#gae409de0010a065c2b325aca0b2d92583 (Fl_Box_Draw_F) I personally prefer GTK+ and made it the default style in FLTK 3, providing a theme "classic" to get that Window95 look back, if desired. - Matthias _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
