And Fl_Text_Display use fl_rectf so that I can't set background image for it without rewriting plenty of draw methods. And it will be a difficutl to update these draw methods if fltk updated.
I hope there is an abstract layer that can be used to customize the look of fltk, and easy to be update with the updating of fltk. > While in theory you can use Fl::set_boxtype() to retheme your app you will be > very limited. > > Some months ago I attempted a cairo-drawn aqua-like theme by dynamically > generating images to be tiled by the different boxtypes and eventually cache > them. > > I found several problems but the major one was that scrollbars are the suck. > > They do not use symbols for the arrowheads but call fl_polygon() and directly > draw them. That makes it impossible to reskin them to look any other way. > > Additionally, scrollbars use a single boxtype for both the "buttons" and the > slider bar, making it hard to reskin them with different looks for the arrows > and the main bar. Not to mention different looks for the top and bottom > arrow, like in aqua. > > It is possible to use a special boxtype that caches its call parameters, say > last three calls, and then infers what part it is drawing, relying on the > weak assumption that buttons and slider bar are drawn in a set order and > comparing the horizontal and vertical positions&sizes. Then you could > dispatch to the appropiate drawing code. That makes for a complex and ugly > box drawing code, but it should work without modifying the library. > > The next problem is the dashed "focus rectangle" which doesnt take into > account that your button might not be rectangular but elipsoidal. There is no > way to replace its drawing code either so no blue/orange outline around your > text boxes as in aqua/android. > > You can disable it and paint an overlay on your main window by subclassing > your main window class and coding a custing draw() method that draws children > and then overlays your desired focus effect with a lot of widget > introspection trickery and damage() wizardry. Be warned it WILL fail if you > have embedded native windows as they clip your painting (at least on win32). > You will also have to be keep track of app focus loses. > > I probably forget more, but rest assured it is a lot of ugly code. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
