Albrecht Schlosser wrote:
> On 12.10.2010, at 18:28, Greg Ercolano wrote:
>> Currently the docs for Fl_Button (under 'Description') says this:
>>
>> Buttons can also generate callbacks in response to FL_SHORTCUT events.
>> The button can either have an explicit shortcut() value
>> *or a letter shortcut can be indicated in the label() with an '&' character*
>> before it. For the label shortcut *it does not matter if Alt is held down,*
>> but *if you have an input field in the same window*, the user will have to
>> *hold down the Alt key* so that the input field does not eat the event first
>> as an FL_KEYBOARD event.
>>
>> I don't think we currently hold to that last sentence, as it seems
>> if there's an input field in the same interface, still regular
>> letter buttons will trigger the shortcuts.
>
> You're right if you read the text literally - however, I think that it meant
> something like
>
> "... but *if you have an input field in the same window*"
>
> add here:
>
> "... that has the focus".
>
> If we add this little omission, then the text and its intention becomes clear:
> Label shortcuts can be triggered no matter what additional modifiers are
> pressed
> or not, as opposed to explicit shortcuts. This doesn't say anything about menu
> bars though, but that's IMHO a special case.
I see. Interesting, and quite possibly true.
My personal opinion on this, current docs aside:
* In my mind the little underbar that appears under a label to
indicate
a shortcut should give a consistent visual cue to the user.
If it means 'Alt' is needed (or in the case of Macs,
'Cloverleaf'),
then it seems to be it should be consistent for both buttons
and menus.
* I think the requirement for a modifier key to access a label
shortcut
is safe, and prevents a common mistake I've seen happen before
where casual typing can cause unintended operations. (For
instance,
in Thunderbird, thinking I'm typing in the text field, but
focus
is in the message viewer, where single letters and the Del
key have
entirely different meanings..!)
* To get single letter button behaviors, I'd think that
wouldn't be
the default for *label* shortcuts, but rather accessible only
to the
programmer who explicitly codes e.g. widget->shortcut('b').
Or, deriving a custom widget to allow 'b', Shift-B and Alt-B
to trigger it via a custom handle() method.
I've actually talked to a few people today about this, asking what
they thought about situations where one thinks they're typing into
a text field, but due to keyboard focus, triggers other unknown
operations..
In one case, before I could even finish, they immediately described the
behavior, it'd happened to them many times, and hate when that happens
;)
I felt the same way..
In the case where Microsoft native buttons appear to be triggered by
regular letters, it's unsure to me if that is actual default behavior
of the button's label shortcut, or if it's custom behavior enabled by
explicit calls the app programmer made, eg. using w->shortcut('x')
to force a letter code shortcut.
I'm also skeptical to use MS as a model, because to be brutally honest,
I'm not sure I trust MS to ever do things the Right Way. ;)
I'd more trust Qt or firefox, or common sense over MS.
MS would make a mistake 25 years ago, and keep it forever
instead of fixing it, just to be compatible. (Backslashes
in pathnames being a favorite example of that! ;)
> I vote for keeping this documented behavior and applying the (maybe slightly
> modified) patch from STR #2243 to achieve the "menubar only with ALT"
> behavior.
> This way we wouldn't break existing apps that rely an the old label shortcut
> behavior.
I'd agree, if it weren't for the fact that possibly bad behavior
can be prevented.
There is a side of me that says 'just leave it', but it's maybe
something worth changing if it's really bad behavior, and the 1.3
transition is a rare opportunity to make such changes. (eg. easily
documented in a 1.1.x -> 1.3.x transition document, which we should
probably be writing anyway ;)
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
