On 31.10.2011 22:27, Greg Ercolano wrote: > I've got a request to improve an existing FLTK app to display > custom graphics in the scrollbar's background of an Fl_Browser derived widget. > > Similar to how FileMerge on OSX shows the location of differences > in the file as tick marks in the scroller's background.. a clever use > of maximizing the UI's real estate. > > So basically looking to take control of Fl_Scrollbar's background drawing > to draw custom graphics over the bg, but beneath the scroller tab.
You could take a look at fl_diff [1] to see an example how it is done there (fldiff marks difference sections in a file and does something more), but this would probably only be the part how to change the scrollbar's look. > AFAIK, there's no way to derive from Fl_Scrollbar that would affect > Fl_Browser, without making a copy of the Fl_Browser code, changing > its name, and re-implemting it to use a custom Fl_Scrollbar class. Well, it's probably a little hacky to do it *this* way, but as it is currently, Fl_Browser_ as well as Fl_Scroll expose their scrollbar widgets publicly. They are in both cases called scrollbar and hscrollbar. So you could probably simply delete the allocated scrollbar widgets and replace them with your own derived classes. Although I wouldn't recommend doing so, this *could* be a way to go, and maybe we could make it "official" by documenting it or adding an official API like Fl_Browser_::scrollbar(Fl_Scrollbar *) to set a custom scrollbar widget. One problem could be that the derived scrollbar class (and thus Fl_Scrollbar as its base class) might need some virtual methods that are currently not virtual. But I don't know... > Assuming this is not possible, perhaps one way of allowing an app > to customize the scroller's background would be with an optional > background drawing callback, which would provide the callback with > x/y/w/h values to draw whatever it wants over the scroller's background. This would be something very special (and maybe the next step would be to make an extra callback for drawing the slider), so I don't like this idea very much. > Is there a better way? Votes for or against? If we could make a somewhat official API to replace the scrollbars with derived classes, we'd get the custom draw() method without further action (draw() is already virtual), hence I suggest to go this way (maybe first without official documentation, at least as a proof of concept), then later (a) documented as a special feature, and/or (b) with an official API to replace the scrollbars with derived classes. Albrecht [1] svn: http://svn.easysw.com/public/fltk/applications/trunk/fldiff _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
