Adding to the fltk.development thread rather than the STR/RFE itself.
I just wanted to make a few comments relating to Greg's insights in
http://www.fltk.org/newsgroups.php?gfltk.development+v:14629
My vision, for want of a better word, but it's more like looking
through a window with rain on the outside and condensation inside,
went as follows. It may change as other people chip in their ideas.
I wasn't planning on deriving from Fl_Valuator as such because I
thought that some of the concepts don't fit cleanly with having
two sliders (eg. how does 'step()' work, which slider moves when
you click in the trough, does value() return high or low, etc).
I had wondered about a similar Fl_Double_Valuator type base class
which provide a smaller interface. Some methods would obviously be
similar, such as handle_push(), handle_drag() and handle_release()
taking care of when() handling, etc. However, the two classes would
be separate, and would not follow the Liskov Substitution Principle.
See also http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
The first real on-screen widget would be the basic trough and sliders,
as shown in the DoubleSlider example code.
The next level(s) up would then add boxes, labels or fields for the
display/edit of the min/low/high/max values.
Then Greg hit me straight between the eyes with a whole load of things
I had never even considered. [I still don't understand what the moving
gif is actually doing].
- keyboard/arrow key activation: yes, but needs some consensus on
whether to move the low or high slider, or both. Does focus select
the widget as a whole, or the last active slider(s)?
- clicking in the trough locks the sliders and they move together
(with or without an additional graticule)
- having a Date slider. That's a good one. I think that there should
be hooks in the lower levels that allow the programmer to provide
conversion between their Date or Foo format and the internal double.
A DateSlider could use a Julian Date representation for example.
- representing this as a group containing two Fl_Valuator sliders.
That's something I haven't got my head around. Are they stalactites
and stalagmites, with one growing down representing max to high, and
the other growing up representing min to low, with the group drawing
between them? Isn't this going to require the group to intervene in
the event handling and dynamic widget resizing as the sliders move?
- round button sliders on a central rail, or rectangle/triangle combos,
or user supplied shapes. Are these not just [extensions to] themes?
The need for an Fl_Double_Valuator base class isn't clear to me yet.
At the moment I can't see how you would use an Fl_Double_Valuator for
anything other than a linear min/low/high/max linear double slider,
but maybe someone else has something esoteric in mind.
Anyway, that's enough rambling for the moment. I won't have time to
actually do anything about this for a while, so there's plenty of
scope for discussing ideas.
Cheers
D.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
