fl_choice + keyboard behavior

[Dave Jordan]

It seems that whatever you do with the keyboard, you're going to get the default return value from fl_choice().

steps to reproduce:

run code below

click titlebar X

use right arrow key to put marquee on No

press enter

code exits anyway. Inappropriate, IMHO.

run again

click on No

code appropriately does not exit

*********************

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/fl_ask.H>

void wcb(Fl_Widget* w, void *v) {

if(fl_choice("Quit?", "No", "Yes", 0) == 1)
w->hide();
}

int main() {

Fl_Window *w = new Fl_Window(100, 100, 100, 100);
w->callback(wcb);
w->show();
return Fl::run();
}

[Ian MacArthur]

On 31 May 2021, at 20:02, Dave Jordan wrote:
>
> It seems that whatever you do with the keyboard, you're going to get the default return value from fl_choice().
>
> steps to reproduce:
> run code below
> click titlebar X
> use right arrow key to put marquee on No
> press enter
> code exits anyway. Inappropriate, IMHO.

Really?
Hmm, I’m less sure.
As best I can recall, most of the toolkits I’ve used expect spacebar as the default way of enacting the selected widget, with <return> or <enter> often associated with some other action - which sounds like what you are seeing here.

(Which behaviour, I assume, dates back to the way nurses et al behaved, back in the day...)

What toolkit behaviour are you comparing this too / expecting?

TBH, I’m not actually sure what the default Win32 behaviour is in that circumstance - is that what you are comparing this too?

[Greg Ercolano]

    With the following:

#include <stdio.h>

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/fl_ask.H>

int main() {
  switch ( fl_choice("Quit?", "No", "Yes", 0) ) {
    case 0: fprintf(stderr,"NO");  break;
    case 1: fprintf(stderr,"YES"); break;
  }
  return 0;
}

    To use keyboard focus to click No with the keyboard: Right Arrow, Spacebar
    because spacebar pushes the buttons.

    Enter always picks Yes because the Yes button is an Fl_Return_Button, as shown
    by the "Enter arrow" on the button, indicating Enter always accepts that key,
    and is the 'default'. (That's what makes it "the default")

    From the docs:

The Fl_Return_Button is a subclass of Fl_Button that generates a
callback when it is pressed or when the user presses the Enter key.

    Since fl_choice() and other members of fl_ask.h and fl_message.h are very simple
    alert dialogs that date back to early history of XForms and old gl forms compatibility,
    they are, well, "old". I rarely use them except for very quick applications, and usually
    for final releases, replace their use with my own dialogs.

    If you want more control over the dialogs (and most people do), you can make your
    own dialogs derived from Fl_Window + Fl_Button that can do whatever you want,
    and can have more modern iconography, copy/pastable dialog text, etc..

[Ian MacArthur]

On 31 May 2021, at 20:53, Ian MacArthur wrote:
>
> (Which behaviour, I assume, dates back to the way nurses et al behaved, back in the day...)

Doh! Spellcheck!

Ncurses there, not nurses.

I’m not sure what the behaviour of nurses would have to do with this.

[Dave Jordan]

Not comparing to any particular platform, and you may be right. I'll have to start paying attention to the behavior in the commercial apps I use. But look at it this way: You have a Yes with a right-angled arrow drawn on it, you have a No with a marquee around the label, what does a typical user expect out of the Enter key? Especially since s/he *caused* the marquee to be around No?

Anyhow if you all are ok with it, so am I (I needed to make sure this wasn't a bug that had been overlooked for 30 years, just in case someone would rush right over to the code and fix it the way I thought it should work :).

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/D6C4FE58-6C61-4F23-A0A2-E4E05F0CFCCB%40gmail.com.

[Dave Jordan]

okay, that all makes perfect sense. I guess I will do just that.

In the short term, I also just realized that fl_choice("Quit?", "No", 0, "Yes")  disables any execution without clicking.

--

You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/2c2a5e1a-2a2f-4e2f-cc48-3873b278511c%40seriss.com.

[Bill Spitzak]

Tried this on gnome, try "zenity --entry" for the best example. It appears they still have Return pushing the OK button and Escape pushing the Cancel button, no matter what widget has focus.

However "zenity --question --extra-button foo" shows three buttons where Return pushes the one with focus (and does nothing if the text label has focus which you can get with Tab) but Escape always pushes the "No" button.

I guess I can see an excuse for the different behavior depending on whether there is a text field or not, but it looks like this is not well decided. There appears to be no icon indicating Enter works.

FLTK used what was considered standard design for dialogs in 1995, based mosly on Macintosh with some Windows and general CDE behavior, and some influence from what Forms did before.

It would be nice I guess if Enter pushed the button with the selection if it was not used as a Shortcut by any other widget but I don't think the event delivery in FLTK is set up to do that.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/CAPdW6bLw9tKWJvfHZxd6TbEDw5KPK7dDEwatyzBb_uYg42zkig%40mail.gmail.com.

[Dave Jordan]

On Tue, Jun 1, 2021 at 11:51 AM Bill Spitzak <spi...@gmail.com> wrote:

Tried this on gnome, try "zenity --entry" for the best example. It appears they still have Return pushing the OK button and Escape pushing the Cancel button, no matter what widget has focus.

However "zenity --question --extra-button foo" shows three buttons where Return pushes the one with focus (and does nothing if the text label has focus which you can get with Tab) but Escape always pushes the "No" button.

this is pretty close to if not exactly how i am going to make my dialog window + buttons behave.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/CAL-8oAhYBcmAVK6FL9-gi7%2Bk0%3D9squDq%2Bz1VHuACmPK3mpjx-A%40mail.gmail.com.