Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
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 intention I'd like to implement the following behavior which I think makes sense, to me at least: when() Flags | Mouse Behavior | Keyboard Behavior --|-|-- NEVER | change: no callback | change: no callback | no change: no callback | no change: N/A --|-|-- CHANGED| change: callback on PUSH, changed()=true| change: callback on PUSH, changed()=true | no change: no callback | no change: N/A --|-|-- NOT_CHANGED | change: no callback | change: no callback | no change: callback on PUSH, changed()=false| no change: N/A --|-|-- CHANGED + | change: callback on PUSH, changed()=true| change: callback on PUSH, changed()=true NOT_CHANGED | no change: callback on PUSH, changed()=false| no change: N/A --|-|-- RELEASE| change: callback on RELEASE, changed()=true | change: callback on RELEASE, changed()=true | no change: no callback | no change: N/A --|-|-- RELEASE + | change: callback on RELEASE, changed()=true | change: callback on RELEASE, changed()=true CHANGED| no change: no callback | no change: N/A --|-|-- RELEASE + | change: no callback | change: no callback NOT_CHANGED | no change: callback on RELEASE, changed()=false | no change: N/A --|-|-- RELEASE + | change: callback on RELEASE, changed()=true | change: callback on RELEASE, changed()=true CHANGED + | no change: callback on RELEASE, changed()=false | no change: N/A NOT_CHANGED | | +-- Notes on the above: N/A: Not Applicable.. there is no way to keyboard navigate the tabs without making a change. RELEASE: this has (and will continue to be) the default when() value of Fl_Tabs. This default behavior will remain the same. 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 RELEASE) You can compare the above to the current radio + browser behavior: http://seriss.com/people/erco/fltk/when-behavior-03-26-2013.html Looking for comments on the above suggestion for tab behavior, and possible problems if any adding this might cause. (I can think of none, other than apps that change when() for Fl_Tabs that would suddenly inherit the new behavior; to date, Fl_Tabs has totally ignored the value of when()) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
*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*) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
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 testing I noticed some inconsistencies with changed()'s value, so started adding that to the table too. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
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() behavior
for Fl_Radio_Button and Fl_Tabs.
(Since Fl_Tabs don't support when() yet, only the radio buttons are worth
using)
When you run the app, change the 'when()' chooser to apply that setting
to the radio buttons and tabs. Then click the radio buttons to see the
behavior
of the callback messages in the terminal, ie. clicking the same button more
than once, etc.
The tests I noted previously were all with the mouse buttons only.
Keyboard nav clicks is a whole other story (e.g. with spacebar or button
shortcuts to trigger radio buttons); callbacks were only ever invoked on
key-down events, and the when() flag behavior seems broken a bit:
WHEN FLAG BEHAVIOR OF RADIO BUTTONS
---
K1) NEVER -- keypress *never* invokes callback (OK)
K2) CHANGED -- keypress invokes callback on PUSH only if
changed (OK)
K3) NOT_CHANGED -- keypress *never* invokes callback (BAD?)
K4) RELEASE -- keypress invokes callback on PUSH *whether
changed or not* (BAD)
K5) CHANGED+NOT_CHANGED -- keypress invokes callback on PUSH *only if
changed* (BAD)
K6) RELEASE+CHANGED -- keypress causes *two callbacks on PUSH* if
changed, *once on no change* (BAD)
K7) RELEASE+NOT_CHANGED -- keypress causes callback on PUSH *whether
changed or not* (BAD?)
Kind of an odd mix of behaviors for the keyboard. Seems like NOT_CHANGED is
ignored
(The K2 + K5 behavior are the same, and K4 + K7 are the same). The presence
of
RELEASE seems to cause NOT_CHANGED behavior. Weird. This should maybe be
'fixed'
if we can agree on the right behavior.
_
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Tabs.H
#include FL/Fl_Group.H
#include FL/Fl_Button.H
#include FL/Fl_Radio_Button.H
#include FL/Fl_Choice.H
#include FL/Fl_Box.H
// Test when() behavior of tabs and radio buttons
Fl_Tabs *G_tabs = 0;
Fl_Radio_Button *G_radio1 = 0;
Fl_Radio_Button *G_radio2 = 0;
Fl_Radio_Button *G_radio3 = 0;
Fl_Choice *G_choice = 0;
void Tabs_CB(Fl_Widget*w,void*) {
printf(TABS Callback, changed()=%d\n, w-changed());
}
void Radio_CB(Fl_Widget*w,void*) {
printf(RADIO Callback, changed()=%d\n, w-changed());
}
void When_CB(Fl_Widget*w,void*) {
int when = 0;
const char *s = G_choice-text();
if ( strcmp(s,NEVER )==0) when = FL_WHEN_NEVER;
if ( strcmp(s,CHANGED)==0) when = FL_WHEN_CHANGED;
if ( strcmp(s,NOT_CHANGED)==0) when = FL_WHEN_NOT_CHANGED;
if ( strcmp(s,RELEASE)==0) when = FL_WHEN_RELEASE;
if ( strcmp(s,CHANGED+NOT_CHANGED)==0) when =
FL_WHEN_CHANGED|FL_WHEN_NOT_CHANGED;
if ( strcmp(s,RELEASE+CHANGED)==0) when =
FL_WHEN_RELEASE|FL_WHEN_CHANGED;
if ( strcmp(s,RELEASE+NOT_CHANGED)==0) when =
FL_WHEN_RELEASE|FL_WHEN_NOT_CHANGED;
// Apply new when value to radio button and tabs widget..
G_radio1-when(when);
G_radio2-when(when);
G_radio3-when(when);
G_tabs-when(when);
printf(WHEN IS NOW %d (%s)\n, when, s);
}
int main(int argc, char *argv[]) {
Fl_Window *win = new Fl_Window(500,200,Tabs Example);
{
G_tabs = new Fl_Tabs(10,10,500-20-110,200-20);
{
// Aaa tab
Fl_Group *aaa = new Fl_Group(10,35,500-20-110,200-45,Aaa);
{
new Fl_Box(50,40,aaa-w()-100,20,These buttons do nothing);
Fl_Button *b1 = new Fl_Button(50, 60,90,25,Button A1);
b1-color(88+1);
Fl_Button *b2 = new Fl_Button(50, 90,90,25,Button A2);
b2-color(88+2);
Fl_Button *b3 = new Fl_Button(50,120,90,25,Button A3);
b3-color(88+3);
}
aaa-end();
// Bbb tab
Fl_Group *bbb = new Fl_Group(10,35,500-10,200-35,Bbb);
{
new Fl_Box(50,40,aaa-w()-100,20,These buttons do nothing);
Fl_Button *b1 = new Fl_Button( 50,60,90,25,Button B1);
b1-color(88+1);
Fl_Button *b2 = new Fl_Button(150,60,90,25,Button B2);
b2-color(88+3);
Fl_Button *b3 = new Fl_Button(250,60,90,25,Button B3);
b3-color(88+5);
Fl_Button *b4 = new Fl_Button( 50,90,90,25,Button B4);
b4-color(88+2);
Fl_Button *b5 = new Fl_Button(150,90,90,25,Button B5);
b5-color(88+4);
Fl_Button *b6 = new Fl_Button(250,90,90,25,Button B6);
b6-color(88+6);
}
bbb-end();
}
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
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 interacted, but apparently that notion was incorrect in the details... 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? Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
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 when options, so had (at best) a vague notion of how they interacted, Ya, ditto. 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 multiple states that are similar to radio buttons. I can't use Fl_Tree or Fl_Table as examples, as I'm working on those.. Overall, radio and browsers are similar when it comes to mouse clicks, though there are some oddball behaviors. The keyboard behavior is different; the browser is more consistent with what I'd expect, but has some odd behavior too. 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 RED indicates behavior I think is *wrong and should be fixed*. BLUE indicates behavior I thought *odd* but maybe shouldn't be fixed, not sure. Hover over the colored text to see tooltips for what I think the behavior *should* be. PS. Making that table made me dizzy. PPS. One consistently asymmetrical behavior I notice with mouse clicks in both radio and browser that might be intentional (though I can't think why offhand): WHEN_CHANGED -- callback invoked on *PUSH* WHEN_NOT_CHANGED -- callback invoked on *RELEASE* Not sure why both aren't on the same stroke, as I would think both would work on PUSH unless amended by WHEN_RELEASE.. though maybe that's not how WHEN_RELEASE is supposed to work, and perhaps there's a reason for this during odd things such as DRAGGING. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
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
multiple states that are similar to radio buttons.
[..]
So here's a big table comparing the when() behavior..
http://seriss.com/people/erco/fltk/when-behavior-03-26-2013.html
Here's the test program used to generate that table.
I'm still fleshing out the data for that table; I keep finding new
boundary cases that have to be documented separately (eg. behavior of clicks
on the empty area of browser), which is why there's now two tables
at the above link:
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Tabs.H
#include FL/Fl_Group.H
#include FL/Fl_Button.H
#include FL/Fl_Radio_Button.H
#include FL/Fl_Choice.H
#include FL/Fl_Box.H
#include FL/Fl_Browser.H
Fl_Tabs *G_tabs = 0;
Fl_Radio_Button *G_radio1 = 0;
Fl_Radio_Button *G_radio2 = 0;
Fl_Radio_Button *G_radio3 = 0;
Fl_Choice *G_choice = 0;
Fl_Browser *G_brow_hold = 0;
Fl_Browser *G_brow_mult = 0;
void Widget_CB(Fl_Widget*w,void*v) {
const char *msg = (const char*)v;
if (strcmp(msg,MULTI BROWSER)==0|| strcmp(msg,HOLD BROWSER)==0) {
Fl_Browser *b = (Fl_Browser*)w;
printf(%s Callback, changed()=%d value()=%d text()='%s'\n, msg,
w-changed(),b-value(),b-text(b-value()));
} else {
printf(%s Callback, changed()=%d\n, msg, w-changed());
}
}
void When_CB(Fl_Widget*w,void*) {
int when = 0;
const char *s = G_choice-text();
if ( strcmp(s,NEVER )==0) when = FL_WHEN_NEVER;
if ( strcmp(s,CHANGED)==0) when = FL_WHEN_CHANGED;
if ( strcmp(s,NOT_CHANGED)==0) when = FL_WHEN_NOT_CHANGED;
if ( strcmp(s,RELEASE)==0) when = FL_WHEN_RELEASE;
if ( strcmp(s,CHANGED+NOT_CHANGED)==0) when =
FL_WHEN_CHANGED|FL_WHEN_NOT_CHANGED;
if ( strcmp(s,RELEASE+CHANGED)==0) when =
FL_WHEN_RELEASE|FL_WHEN_CHANGED;
if ( strcmp(s,RELEASE+NOT_CHANGED)==0) when =
FL_WHEN_RELEASE|FL_WHEN_NOT_CHANGED;
if ( strcmp(s,RELEASE+CHANGED+NOT_CHANGED)==0) when =
FL_WHEN_RELEASE|FL_WHEN_CHANGED|FL_WHEN_NOT_CHANGED;
// Apply new when value to radio button and tabs widget..
G_radio1-when(when);
G_radio2-when(when);
G_radio3-when(when);
G_tabs-when(when);
G_brow_hold-when(when);
G_brow_mult-when(when);
printf(\n*** WHEN IS NOW %d (%s)\n, when, s);
}
int main(int argc, char *argv[]) {
Fl_Window *win = new Fl_Window(720,200,Tabs Example);
{
G_tabs = new Fl_Tabs(10,10,500-20-110,200-20);
{
// Aaa tab
Fl_Group *aaa = new Fl_Group(10,35,500-20-110,200-45,Aaa);
{
new Fl_Box(50,40,aaa-w()-100,20,These buttons do nothing);
Fl_Button *b1 = new Fl_Button(50, 60,90,25,Button A1);
b1-color(88+1);
Fl_Button *b2 = new Fl_Button(50, 90,90,25,Button A2);
b2-color(88+2);
Fl_Button *b3 = new Fl_Button(50,120,90,25,Button A3);
b3-color(88+3);
}
aaa-end();
// Bbb tab
Fl_Group *bbb = new Fl_Group(10,35,500-10,200-35,Bbb);
{
new Fl_Box(50,40,aaa-w()-100,20,These buttons do nothing);
Fl_Button *b1 = new Fl_Button( 50,60,90,25,Button B1);
b1-color(88+1);
Fl_Button *b2 = new Fl_Button(150,60,90,25,Button B2);
b2-color(88+3);
Fl_Button *b3 = new Fl_Button(250,60,90,25,Button B3);
b3-color(88+5);
Fl_Button *b4 = new Fl_Button( 50,90,90,25,Button B4);
b4-color(88+2);
Fl_Button *b5 = new Fl_Button(150,90,90,25,Button B5);
b5-color(88+4);
Fl_Button *b6 = new Fl_Button(250,90,90,25,Button B6);
b6-color(88+6);
}
bbb-end();
}
G_tabs-end();
G_tabs-callback(Widget_CB, (void*)TABS);
G_choice = new Fl_Choice(500-100-10,30,100,25,when());
G_choice-align(FL_ALIGN_TOP);
G_choice-add(NEVER);
G_choice-add(CHANGED);
G_choice-add(NOT_CHANGED);
G_choice-add(RELEASE);
G_choice-add(CHANGED+NOT_CHANGED);
G_choice-add(RELEASE+CHANGED);
G_choice-add(RELEASE+NOT_CHANGED);
G_choice-add(RELEASE+CHANGED+NOT_CHANGED);
G_choice-callback(When_CB);
G_choice-textsize(9);
Fl_Group *rg = new Fl_Group(G_choice-x(), G_choice-y()+35, 100,100);
rg-color(50);
rg-begin();
G_radio1 = new Fl_Radio_Button(rg-x(),rg-y()+00,rg-w(),25,Radio
1);
G_radio1-callback(Widget_CB,(void*)RADIO1);
G_radio2 = new Fl_Radio_Button(rg-x(),rg-y()+30,rg-w(),25,Radio
2);
[fltk.development] RFC: Adding when() support in Fl_Tabs
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 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_NOT_CHANGED -- invokes callback when click /doesn't/ change a button's state (no callback if change) 3) FL_WHEN_CHANGED|FL_WHEN_NOT_CHANGED -- invokes callback when clicked if button changes state or not 4) FL_WHEN_RELEASED-- if none of the above are set, callback invoked if button's state changes In all cases, changed() reflects if a button changed state or not (Fl_Tabs does this as well) And like radio buttons, Fl_Tab's default when() value is FL_WHEN_RELEASED, so the default behavior would be the same as it is now with that default. Anyone see a problem with implementing this into Fl_Tabs? I don't think there'd be any backwards compatible issues, and apps to date shouldn't be messing with when() as to date behavior is not documented. However, it may be prudent to protect the above 'new' behavior with a macro (like FL_ABI_VERSION, or some such) if that might be an issue.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
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_NOT_CHANGED -- invokes callback when click /doesn't/ change a button's state (no callback if change) 3) FL_WHEN_CHANGED|FL_WHEN_NOT_CHANGED -- invokes callback when clicked if button changes state or not 4) FL_WHEN_RELEASED-- if none of the above are set, callback invoked if button's state changes Actually, some elaboration; tests revealed a subtlety I wasn't aware of: A) If only WHEN_RELEASED is set, the callback is invoked only if there was a change *during button RELEASE event* B) If only WHEN_CHANGED is set, the callback is invoked on change *during the button PUSH event* C) If only WHEN_NOT_CHANGED is set, the callback is invoked on no change *during the button PUSH event* D) If WHEN_RELEASED + WHEN_CHANGED, you can get *two callbacks* per click when a button changes state; WHEN_CHANGED causes an event on the PUSH event, WHEN_RELEASED causes an event on the RELEASE event. If the button didn't change, no event. E) If WHEN_RELEASED + WHEN_NOT_CHANGED, if the button changed, you get a callback on *release* only, if the button didn't change, you'll get a callback on *RELEASE* only. In the above: (A) is obvious enough, and WHEN_RELEASED seems to imply WHEN_CHANGED. (B) is interesting in that it seems to imply callbacks are done on push events (unless WHEN_RELEASED is specified) (C) is consistent with (B) for the not-changed state (D) seems odd in that you can get two callbacks per click.. I would think WHEN_RELEASED implies I'd only get a callback on release (E) seems correct in that WHEN_RELEASED causes the NOT_CHANGED callback on release only. So is (D) a bug, or is that an intended side effect of (B)? I must admit I had a dim understanding of the when() flags, because they were always a bit thinly defined in the docs. Trying to nail down my understanding of these flags to properly implement Fl_Tabs, Fl_Table, and Fl_Tree.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
