On 04/15/13 00:48, Duncan Gibson wrote:
> I'm diverting this to fltk.development rather than this specific RFE...
Sorry about cluttering up your STR, but I was on a roll.
Tried to move it to fltk.dev, but I'd've (*) had to make an intro
and write for a wider audience.. just the thought of it was
messing up my flow.
> Greg wrote:
>> It occurs to me maybe I should write an article or make a video or
>> something on how to make an FLTK widget, all the wacky details and
>> implications. I wish I had one when I was writing Fl_Tree and Fl_Table,
>> as there's a lot of stuff about keyboard nav and when() that I didn't
>> know about until much later.. making it hard to go back and retrofit..!
>
> It would certainly be useful to have a set of hints on all of the
> areas that need to be considered, and in what order they should be
> addressed during development. For example, I rarely customize a new
> desktop and always stick to the default themes, so I have no idea
> whether themes have to be built in from the start, or if they are
> easy or difficult to retrofit later.
>
> It might actually be useful and fun to work through the design and
> implementation of a new widget, one step at a time, using such a set
> of hints, and eliciting feedback from the [widget] developers along
> the way, in order to (a) debug and improve the hints, and (b) give
> the basis for a "Designing your own widget" page in the documentation.
Yes, a short list would be good at least.
Your widget is interesting in that it has two moving parts.
In that cases it usually helps to split the widget up into
separate widgets, one widget per moving part, so that each
"thing" that needs focus will be handled by FLTK's own
event delivery system through the widget hierarchy, which
would also gracefully handle things like focus, keynav, etc.
I think your widget could maybe be a simple Fl_Group that
could host two Fl_Valuator widgets to handle the two tabs,
but it might get tricky.
You wouldn't want to overlap them (that would be bad, as they'd
disagree over the common real estate for mouse clicks), but perhaps
abutting them side-by-side, and let the parent widget handle
changing their sizes to always be abutting.
That might get tricky though if you decide to support "locked"
behavior, where dragging in the trough between the two tabs moves both.
You'd probably want the parent's handle() method to take control at
that point, as the parent will doubtless want to resize both valuator's
xywh dimensions to keep them abutting while the range is changing.
I suppose another route to go would be to make completely custom
"tab" widgets that only have the tab as their governing real estate,
and dragging them just changes their xywh position. The widget could
have a VERTICAL | HORIZONTAL flag so that its position could be limited
to a single dimension of travel, and could have an xmin/xmax ymin/ymax
to limit travel along that axis, which the parent group widget could
maintain. Then the parent would own the 'trough' and could handle
an optional graticule and 'locking bar' that could be slid around
to lock the two tabs together.
It's definitely easier to plan and conceive new widgets from the
perspective of understanding the big picture of FLTK's underlying
mechanisms (when()/focus/handle()/event delivery/etc).. which is
why it's so important to have something in our docs on how to
write custom widgets. This way when folks go off to write custom
widgets, they don't leave stuff out.
There should probably be separate sections describing different
types of widgets, like buttons vs. text vs. tables vs. browsers
vs. file browsers vs. radio buttons vs. simple drawing areas, etc.
and describe which fltk features each uses, and explain common
programming patterns used by these widgets.
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
