Nigo, many thanks for your valuable comments about the problems you had. This can be very helpful to improve FLTK in the future.
On 14.12.2010 00:19, nigo wrote: > 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. We could probably solve that by allowing to replace the scrollbars by a derived class, but this would need some work and a little redesign of some widgets. Or a user-defined function that returns a new Fl_Scrollbar object, but in fact this could be a derived class. Something like that... > 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. You could solve all this with your own derived scrollbar widget. > 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. Ugly, ugly. ;-) > 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. Maybe this has been asked before. We could make Fl_Widget::draw_focus() virtual, and that's it. I can imagine to do this even for FLTK 1.3. > 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. Yes, I wouldn't want to start with such code. > I probably forget more, but rest assured it is a lot of ugly code. I can imagine that. Fortunately we are in a position that we can improve our toolkit whenever we find the need to do it. Of course, patches are always welcome. But you could also contribute a lot, if you add a RFE for FLTK 1.4 (the current project name for the next version after 1.3) with your problem report, so that we get an idea what needs to be improved. Maybe you can also find something you forgot in this posting. I can't promise anything, since we are now trying to push the FLTK 1.3 release, but if we have the information, then we can use it for designing the next release. Thanks in advance Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
