Re: Recent NSMenu changes..
I finally implemented a solution for this long standing issue. You may now change the displayed characters for the key equivalent modifiers by setting some user defaults. The keys are GSControlKeyString GSAlternateKeyString GSShiftKeyString GSCommandKeyString If you use nice Unicode characters (like U21E7 for shift), you can get near the Apple look. If you use empty strings, you can remove these annoying characters all together. Fred On 30.01.2007 14:37, Benhur Stein wrote: On 1/29/07, Fred Kiefer fredkie...@gmx.de wrote: Nicolas Roard schrieb: On 1/29/07, Gregory John Casamento greg_casame...@yahoo.com wrote: All, Perhaps we could put a set of images to represent the key masks needed. The #/+/- scheme adds absolutely nothing and only clutters the interface. It would be better to implement a mechanism which shows some images (pehaps *original* versions of the same symbols used in Cocoa) to represent Control, Command, Shift, and Alt. Images would be better, indeed. You probably do not need to show the shift modifier though -- simply use an uppercase letter (unless it's not a letter, of course). Not sure here. At least reusing the Apple images wont help those of us that don't use an Apple keybord :-) Also when displaying images we need another whole set of changes to the size calculation and drawing code in NSMenuItemCell. Who ever wants to do this is free to do so, but I wont do anything in that direction. Why not use unicode characters? That way there would be no need to insert an image and change calculation, as they are normal characters. For example, something like U2666 or 25C6 or 29EB could be used for control (at least in my control key there is a diamond symbol), something like U21E7 for shift etc. This could be user configurable to better match the symbols one has in his keyboard. If the default installed font is dejavu, we could be sure of having those glyphs in the default installation. Benhur ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
On 1/29/07, Fred Kiefer [EMAIL PROTECTED] wrote: Nicolas Roard schrieb: On 1/29/07, Gregory John Casamento [EMAIL PROTECTED] wrote: All, Perhaps we could put a set of images to represent the key masks needed.The #/+/- scheme adds absolutely nothing and only clutters the interface. It would be better to implement a mechanism which shows some images (pehaps *original* versions of the same symbols used in Cocoa) to represent Control, Command, Shift, and Alt. Images would be better, indeed. You probably do not need to show the shift modifier though -- simply use an uppercase letter (unless it's not a letter, of course). Not sure here. At least reusing the Apple images wont help those of us that don't use an Apple keybord :-) Also when displaying images we need another whole set of changes to the size calculation and drawing code in NSMenuItemCell. Who ever wants to do this is free to do so, but I wont do anything in that direction. Why not use unicode characters? That way there would be no need to insert an image and change calculation, as they are normal characters. For example, something like U2666 or 25C6 or 29EB could be used for control (at least in my control key there is a diamond symbol), something like U21E7 for shift etc. This could be user configurable to better match the symbols one has in his keyboard. If the default installed font is dejavu, we could be sure of having those glyphs in the default installation. Benhur ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
On 30 Jan 2007, [EMAIL PROTECTED] wrote: Why not use unicode characters? Not everyone have their GNUStep set to use unicode, so I don't think this will work. However, I do find the pound sign ugly. Charles -- /* panic?? These should never occur in our application. */ linux-2.6.6/drivers/scsi/aic7xxx/aiclib.c pgpXHSdac1RyN.pgp Description: PGP signature ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
On 1/29/07, Gregory John Casamento [EMAIL PROTECTED] wrote: All, Perhaps we could put a set of images to represent the key masks needed.The #/+/- scheme adds absolutely nothing and only clutters the interface. It would be better to implement a mechanism which shows some images (pehaps *original* versions of the same symbols used in Cocoa) to represent Control, Command, Shift, and Alt. Images would be better, indeed. You probably do not need to show the shift modifier though -- simply use an uppercase letter (unless it's not a letter, of course). -- Nicolas Roard La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher. -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
On 1/29/07, Nicolas Roard [EMAIL PROTECTED] wrote: Images would be better, indeed. You probably do not need to show the shift modifier though -- simply use an uppercase letter (unless it's not a letter, of course). And of course I don't think it's really useful to put the alt modifier as it will here all the time ? -- Nicolas Roard La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher. -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
Nicolas Roard schrieb: On 1/29/07, Gregory John Casamento [EMAIL PROTECTED] wrote: All, Perhaps we could put a set of images to represent the key masks needed.The #/+/- scheme adds absolutely nothing and only clutters the interface. It would be better to implement a mechanism which shows some images (pehaps *original* versions of the same symbols used in Cocoa) to represent Control, Command, Shift, and Alt. Images would be better, indeed. You probably do not need to show the shift modifier though -- simply use an uppercase letter (unless it's not a letter, of course). Not sure here. At least reusing the Apple images wont help those of us that don't use an Apple keybord :-) Also when displaying images we need another whole set of changes to the size calculation and drawing code in NSMenuItemCell. Who ever wants to do this is free to do so, but I wont do anything in that direction. To answer the other mails as well: - Not showing the modifier symbol for Alt wont help. What would you display for a key that works without any modifier? For example F12 could be a short cut and Alt-F12 one as well. How would a user be able to distinguish these? - Showing the full explanation of a modifier is a bubble help is in itself a great idea. But it does not resolve the original problem that we need to display something to give the user an idea, what modifiers have to be used. - The code already tries to remove the shift modifier, when an uppercase letter is given. The code here may be wrong, as I did change Nikolaus original code. Sorry, as I wrote in my first answer, I am not happy with the current approach either. But all the answers up to now suggest that nobody actually sees the problem here or is taking it serious. I am going to drop out of the further discussion until that stage has been reached. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Recent NSMenu changes..
I don't really like the new NSMenuItemCell behaviour which adds #, /, +, ^ to show the key mask before the key equivalent.. i think its unattractive and makes it hard to quickly see the key equivalent, and doesn't increase the comprehension of which keys to press since they don't map to the actual keys to be pressed on the keyboard ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
Matt Rice schrieb: I don't really like the new NSMenuItemCell behaviour which adds #, /, +, ^ to show the key mask before the key equivalent.. i think its unattractive and makes it hard to quickly see the key equivalent, and doesn't increase the comprehension of which keys to press since they don't map to the actual keys to be pressed on the keyboard It is a good point that this does look ugly and that it does not really help a user to judge what modifier she needs to press to get the key equivalent working. I did copy this code from mySTEP because up to then the GNUstep code had only displayed the key equivalent itself. This might in some cases even be a non printable character like return or escape, so some change was needed. But our old code also did not show the key modifier. I think in May last year Richard corrected the GUI code to respect the key equivalent modifier, since then other modifier apart from ALT where possible, but the GUI did not give a glue about which modifier where needed. So seeing an s as the key modifier you had to go through all the possible modifier combinations to trigger the short cut. This clearly needed to be changed. The question now is, if you have a better proposal on how to display the modifier? Any idea here would be welcome. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
On 2007-01-28 12:53:23 -0800 Fred Kiefer [EMAIL PROTECTED] wrote: Matt Rice schrieb: I don't really like the new NSMenuItemCell behaviour which adds #, /, +, ^ to show the key mask before the key equivalent.. i think its unattractive and makes it hard to quickly see the key equivalent, and doesn't increase the comprehension of which keys to press since they don't map to the actual keys to be pressed on the keyboard It is a good point that this does look ugly and that it does not really help a user to judge what modifier she needs to press to get the key equivalent working. I did copy this code from mySTEP because up to then the GNUstep code had only displayed the key equivalent itself. This might in some cases even be a non printable character like return or escape, so some change was needed. But our old code also did not show the key modifier. I think in May last year Richard corrected the GUI code to respect the key equivalent modifier, since then other modifier apart from ALT where possible, but the GUI did not give a glue about which modifier where needed. So seeing an s as the key modifier you had to go through all the possible modifier combinations to trigger the short cut. This clearly needed to be changed. The question now is, if you have a better proposal on how to display the modifier? Any idea here would be welcome. Not really, the only thing i could think of was something like using tooltips to give a textual representation of the key equivalent e.g. Quit: Terminates the application. Key equivalent: command-q Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
All, Perhaps we could put a set of images to represent the key masks needed.The #/+/- scheme adds absolutely nothing and only clutters the interface. It would be better to implement a mechanism which shows some images (pehaps *original* versions of the same symbols used in Cocoa) to represent Control, Command, Shift, and Alt. GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: gnustep-dev@gnu.org Sent: Sunday, January 28, 2007 3:53:23 PM Subject: Re: Recent NSMenu changes.. Matt Rice schrieb: I don't really like the new NSMenuItemCell behaviour which adds #, /, +, ^ to show the key mask before the key equivalent.. i think its unattractive and makes it hard to quickly see the key equivalent, and doesn't increase the comprehension of which keys to press since they don't map to the actual keys to be pressed on the keyboard It is a good point that this does look ugly and that it does not really help a user to judge what modifier she needs to press to get the key equivalent working. I did copy this code from mySTEP because up to then the GNUstep code had only displayed the key equivalent itself. This might in some cases even be a non printable character like return or escape, so some change was needed. But our old code also did not show the key modifier. I think in May last year Richard corrected the GUI code to respect the key equivalent modifier, since then other modifier apart from ALT where possible, but the GUI did not give a glue about which modifier where needed. So seeing an s as the key modifier you had to go through all the possible modifier combinations to trigger the short cut. This clearly needed to be changed. The question now is, if you have a better proposal on how to display the modifier? Any idea here would be welcome. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
