Opened 11 years ago

Closed 10 years ago

#3682 closed enhancement (invalid)

Smart BAlert knows when to Escape

Reported by: jonas.kirilla Owned by: axeld
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

I think it would be safe to give BAlert enough intelligence for itself to set escape as the shortcut key for a Cancel button, under these certain conditions:

  1. It should be done as late as possible. (Not in the constructor.) Preferrably in BAlert's Go() method, so as to give the user plenty of time to set up shortcut keys before the system starts guessing.
  1. It should be conditionalized on an English locale, as soon as that is supported. ("Cancel" might mean something else in some other language. Other languages would need a different string. The feature would be turned off for unknown languages/locales.)
  1. Additionally, these conditions should be met:
- there exists a button named Cancel
- the Cancel button has no shortcut key set
- no other button has B_ESCAPE set as its shortcut key

Change History (6)

comment:1 by jonas.kirilla, 11 years ago

I think this would play nicely with both applications that set shortcuts and apps that don't.

comment:2 by pulkomandy, 10 years ago

This is one of the reason I wanted to centralize some strings in a common set and not let the dev choose them freely. In this system there would be a #define B_CANCEL_BUTTON "Cancel" (or something else) set by each locale. This way it is easy to identify which button is "ok", which one is "cancel" and so on. Allowing you to detect the right button every time, whatever the locale is, and without adding too much code.

comment:3 by axeld, 10 years ago

I think you should never use string comparison for this.

comment:4 by jonas.kirilla, 10 years ago

Feel free to close as invalid.

(I wish there was a status called "rejected" or "denied". An idea could very well be rejected for good reasons without being invalid. The way I see it, if "denied" is at the beginning of a spectrum where an idea may be deemed difficult to implement well, or may have undesirable side-effects, etc, "invalid" would be for ideas and requests at the far end of the spectrum and reserved for misunderstandings and utter failure at thinking straight.)

comment:5 by mmadia, 10 years ago

If additional ticket resolutions, "rejected" or "denied" are desirable by other developers, it could be added while inside an ssh session.

cd ~
trac-admin trac resolution add rejected

Trac may need to be restarted, see ~/admin-notes/howto-restart-trac.txt

comment:6 by axeld, 10 years ago

Resolution: invalid
Status: newclosed

I think "invalid" is good enough - it doesn't render the ideas invalid, only the ticket. You can always look at the contents to build your opinion.

Note: See TracTickets for help on using tickets.