To solve STR#2939 "Fl_Tabs not honoring when(FL_WHEN_NOT_CHANGED)"
noticed that Fl_Tabs doesn't really make use of when() at all.
It seems to me tabs are very much like radio buttons, so it seems
it would make sense to model Fl_Tabs handling of when() after radio button's.
With radio buttons, the
On 03/25/13 19:37, Greg Ercolano wrote:
> With radio buttons, the behavior is:
>
>0) FL_WHEN_NEVER -- callback never invoked
>1) FL_WHEN_CHANGED -- invokes callback when click
> changes a button's state (no callback if no change)
>2) FL_WHEN_N
On 03/25/13 22:51, Greg Ercolano wrote:
> On 03/25/13 19:37, Greg Ercolano wrote:
>> With radio buttons, the behavior is:
>> [..]
>
> Actually, some elaboration; tests revealed a subtlety I wasn't aware of:
> [..]
Oh, and here's a test program (below) I was using to check when() behavio
> Actually, some elaboration; tests revealed a subtlety I wasn't
> aware of:
Huh; that's not quite what I expected, either.
Though, now I think of it, I'm not sure what I *did* expect the behaviour to be.
I only rarely use the "when" options, so had (at best) a vague notion of how
they inte
On 03/26/13 01:54, MacArthur, Ian (Selex ES, UK) wrote:
>> Actually, some elaboration; tests revealed a subtlety I wasn't aware of:
>
> Huh; that's not quite what I expected, either.
> Though, now I think of it, I'm not sure what I *did* expect the behaviour to
> be.
> I only rarely use the "
On 03/26/13 10:47, Greg Ercolano wrote:
>> I wonder if it is worth poking at a few non-radio buttons
>> and see if that is "the same" or whether some of these behaviours
>> are peculiar to the radio-button case?
>
> Good idea; Fl_Browser is the only one I can think of that has
> multip
> So here's a big table comparing the when() behavior of radio and
> browser, comparing mouse clicks and keyboard nav clicks:
> http://seriss.com/people/erco/fltk/when-behavior-03-26-2013.html
Fixed that table up a bit to make it easier to read.
Hit Reload to see the changes.
During t
OK, so since Fl_Tabs currently has no defined when() behavior,
it seems we can define the behavior of the non-default values how we want,
as long as the "default behavior" remains unchanged.
Having looked exhaustively at similar widgets (Fl_Radio_Button & Fl_Browser)
to divine the when() flags int
*correction*
On 03/29/13 17:40, Greg Ercolano wrote:
> The above departs from the current behavior of Fl_Browser and Fl_Radio_Button
> in that the keyboard behavior for PUSH vs. RELEASE follows the same logic as
> the mouse.
> (In the other widgets, keyboard callbacks are always on *PUSH*)
__
