Showing numpad key equivs in menu items

  • So is there no way in Cocoa to assign key equivs by key code instead of by string? The Carbon menu item could be set by glyph (SetMenuItemKeyGlyph) or by key code (SetMenuItemCommandKey), which sure were handy. The key equiv would clearly show numpad glyphs with a rounded rect around them. In Cocoa, how does one make it clear that one menu item's key equiv is regular "1" and another menu item's key equiv is "numpad 1"?

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
  • On May 6, 2013, at 1:19 PM, Steve Mills wrote:

    > So is there no way in Cocoa to assign key equivs by key code instead of by string? The Carbon menu item could be set by glyph (SetMenuItemKeyGlyph) or by key code (SetMenuItemCommandKey), which sure were handy. The key equiv would clearly show numpad glyphs with a rounded rect around them. In Cocoa, how does one make it clear that one menu item's key equiv is regular "1" and another menu item's key equiv is "numpad 1"?

    I don't know if this works, but you might try [menuItem setKeyEquivalentModifierMask:NSNumericPadKeyMask].  That said, I'm not sure that users will understand the distinction between 1 and numpad 1, even with a rounded rect border.  Also, compact keyboard don't have separate numeric keypads.

    Regards,
    Ken
  • On May 6, 2013, at 14:20:44, Ken Thomases <ken...> wrote:

    > I don't know if this works, but you might try [menuItem setKeyEquivalentModifierMask:NSNumericPadKeyMask].  That said, I'm not sure that users will understand the distinction between 1 and numpad 1, even with a rounded rect border.  Also, compact keyboard don't have separate numeric keypads.

    Already tried that. I doesn't draw with a different glyph like Carbon did (and Cocoa *should* be doing). And yeah, not caring about compact keyboards - our users already have real keyboards. :) I'm going to write up a bug. How many years has Cocoa been around and it's still not as complete as Carbon in so many ways. It's like they designed a new mode of transportation, added lots of whiz-bang features inside, but forgot to include an engine. It's so annoying as a developer who's trying to modernize existing apps.

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
  • Steve Mills asked: 

    So is there no way in Cocoa to assign key equivs by key code instead of by string? The Carbon menu item could be set by glyph (SetMenuItemKeyGlyph) or by key code (SetMenuItemCommandKey), which sure were handy. The key equiv would clearly show numpad glyphs with a rounded rect around them. In Cocoa, how does one make it clear that one menu item's key equiv is regular "1" and another menu item's key equiv is "numpad 1"?
     
    In light of the great opportunity for user confusion - because a little rectangle around the number is hardly a "clear" indicator - and the reality that many users do not have a number pad, I think the solution I'd recommend is to rethink the choice of key equivalents so as to obviate the problem.

    That said, if you insist on going down this path, it might work to include NSNumericPadKeyMask in the key equivalent mask for the item.

    But seriously: Think about how much you want to annoy notebook users first.
  • On May 6, 2013, at 11:19 AM, Steve Mills <smills...> wrote:

    > So is there no way in Cocoa to assign key equivs by key code instead of by string? The Carbon menu item could be set by glyph (SetMenuItemKeyGlyph) or by key code (SetMenuItemCommandKey), which sure were handy. The key equiv would clearly show numpad glyphs with a rounded rect around them. In Cocoa, how does one make it clear that one menu item's key equiv is regular "1" and another menu item's key equiv is "numpad 1"?

    Unfortunately there's no NSMenu API to support this. Please vote for one by filing a Radar.

    -eric
  • On May 6, 2013, at 16:58:10, gweston <gweston...> wrote:

    > In light of the great opportunity for user confusion - because a little rectangle around the number is hardly a "clear" indicator - and the reality that many users do not have a number pad, I think the solution I'd recommend is to rethink the choice of key equivalents so as to obviate the problem.

    So a rounded rect around a number is not a clear indictor that it's a different character? People have been able to clearly see the difference between í, ì, and i for hundreds of years, so that's a pretty lame excuse. I've never been confused seeing these numpad glyphs in good ol' Carbon menus.

    > That said, if you insist on going down this path, it might work to include NSNumericPadKeyMask in the key equivalent mask for the item.

    This only affects the key used to trigger it, not the appearance of the glyph in the menu item.

    > But seriously: Think about how much you want to annoy notebook users first.

    OK, we'll annoy them by taking away key equivs they've been used to using in our app for the past umpteen years.

    Why is it that people on these lists prefer giving their opinions instead of technical knowledge?

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
  • On May 6, 2013, at 17:50:23, Eric Schlegel <ericsc...>
    wrote:

    > Unfortunately there's no NSMenu API to support this. Please vote for one by filing a Radar.

    radar://13823585

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
  • Part of the territory. Apple "knows better than you", thus so do its fanboys.

    On Mon, May 6, 2013 at 10:20 PM, Steve Mills <smills...> wrote:
    > On May 6, 2013, at 16:58:10, gweston <gweston...> wrote:
    >
    >> In light of the great opportunity for user confusion - because a little rectangle around the number is hardly a "clear" indicator - and the reality that many users do not have a number pad, I think the solution I'd recommend is to rethink the choice of key equivalents so as to obviate the problem.
    >
    > So a rounded rect around a number is not a clear indictor that it's a different character? People have been able to clearly see the difference between í, ì, and i for hundreds of years, so that's a pretty lame excuse. I've never been confused seeing these numpad glyphs in good ol' Carbon menus.
    >
    >> That said, if you insist on going down this path, it might work to include NSNumericPadKeyMask in the key equivalent mask for the item.
    >
    > This only affects the key used to trigger it, not the appearance of the glyph in the menu item.
    >
    >> But seriously: Think about how much you want to annoy notebook users first.
    >
    > OK, we'll annoy them by taking away key equivs they've been used to using in our app for the past umpteen years.
    >
    > Why is it that people on these lists prefer giving their opinions instead of technical knowledge?
    >
    > --
    > Steve Mills
    > office: 952-818-3871
    > home: 952-401-6255
    > cell: 612-803-6157
  • On May 6, 2013, at 8:20 PM, Steve Mills <smills...> wrote:

    > On May 6, 2013, at 16:58:10, gweston <gweston...> wrote:
    >
    >> In light of the great opportunity for user confusion - because a little rectangle around the number is hardly a "clear" indicator - and the reality that many users do not have a number pad, I think the solution I'd recommend is to rethink the choice of key equivalents so as to obviate the problem.
    >
    > So a rounded rect around a number is not a clear indictor that it's a different character?

    Not really, no. I would imagine this would be particularly unclear for many East Asian users, who seem to enjoy putting western numerals in circles or other shapes for reasons to which I am not privy.

    > People have been able to clearly see the difference between í, ì, and i for hundreds of years

    This is a terrible argument, and you know it not to be true. If you showed those three glyphs to a non-Western person, would they be likely to discern a difference? Depending on the arguments I pass, even my _computer_ won’t distinguish between them.

    By the way, you forgot to include “dotless i" in your example of clearly-differentiable glyphs. But that’s probably because you don't speak Turkish and thus wouldn't recognize a difference between it and a dotted i. But you might complain if hitting the wrong one didn't activate the menu item you expected.

    > , so that's a pretty lame excuse. I've never been confused seeing these numpad glyphs in good ol' Carbon menus.

    That's because at some point you learned their meaning. There's nothing intuitive about putting a number in a round rect to indicate anything is different about that number, much less _what_ specifically is different. For the record, I believe I’ve only encountered this convention in Adobe apps.

    If this were a more practiced convention on OS X, then I'd be quite more disposed towards your argument. But so-called “real” Macs have been shipping without numpads for quite some time, and developers in general have no reason to assume users are familiar with numpad-variant shortcut indicators.

    >
    >> That said, if you insist on going down this path, it might work to include NSNumericPadKeyMask in the key equivalent mask for the item.
    >
    > This only affects the key used to trigger it, not the appearance of the glyph in the menu item.

    I agree with you wholeheartedly that this right here is a bug. If Apple decides to fix it (not likely, I’d guess) then they might pick a more meaningful convention than enclosing the numerals in round rects.

    >
    >> But seriously: Think about how much you want to annoy notebook users first.
    >
    > OK, we'll annoy them by taking away key equivs they've been used to using in our app for the past umpteen years.

    On the one hand, it sucks to break habit.

    On the other hand, the vast majority of Apple computers sold nowadays do not have numpads. This includes desktops. Maybe you ought to consider adopting shortcuts friendlier to such systems? Perhaps you can silently maintain the old ones for backwards compatibility using an app-local NSEvent monitor.

    >
    > Why is it that people on these lists prefer giving their opinions instead of technical knowledge?

    There was a specific technical suggestion offered to you, to which you replied and which is included inline in this email. You seem to be agonizing because it did not result in the effect you desired.

    As for why the replies to this list do not consist solely of technical suggestions tailor-made to the requestor’s rubric: how many times have you agonized over a solution only to realize you're tackling the wrong problem?

    Moreover, we don't know your constraints. We don't share your motivations. We are not mechanical Turks and do not live to answer within parameters.

    --Kyle Sluder
  • On May 7, 2013, at 02:04:09, Kyle Sluder <kyle...> wrote:

    > This is a terrible argument, and you know it not to be true. If you showed those three glyphs to a non-Western person, would they be likely to discern a difference? Depending on the arguments I pass, even my _computer_ won’t distinguish between them.

    Then you have a pretty dumb computer.

    > That's because at some point you learned their meaning. There's nothing intuitive about putting a number in a round rect to indicate anything is different about that number, much less _what_ specifically is different. For the record, I believe I’ve only encountered this convention in Adobe apps.

    And at some point you learned that a crooked angled line with a dash at the top-right meant "option key", even though there have been very few (if any) keyboards manufactured with that symbol printed on the option key. Same with ^ and the control key. That doesn't mean it's wrong to use those symbols.

    > If this were a more practiced convention on OS X, then I'd be quite more disposed towards your argument. But so-called “real” Macs have been shipping without numpads for quite some time, and developers in general have no reason to assume users are familiar with numpad-variant shortcut indicators.

    And most "real" users buy extended keyboards. I've never seen someone who works with spreadsheets NOT have a keyboard with a numpad, or people in the film or music industries who need all the keys they can get.

    > I agree with you wholeheartedly that this right here is a bug. If Apple decides to fix it (not likely, I’d guess) then they might pick a more meaningful convention than enclosing the numerals in round rects.

    If they do, that's just great, but for the past however many years, many users are familiar with the current scheme.

    > Moreover, we don't know your constraints. We don't share your motivations. We are not mechanical Turks and do not live to answer within parameters.

    Exactly, you don't know our constraints or our users. This is a technical list, and I expect technical answers, not opinions that waste everyone's time.

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
  • On May 7, 2013, at 14:25:52, Quincey Morris <quinceymorris...> wrote:

    > 1. The software Steve is dealing with (Finale, I believe he has stated earlier) has special needs. I've used music notation software for note-by-note entry in the past, and it's a horrendous chore without some dedicated keys to assist. You can use a MIDI (piano) keyboard for dedicating keys to pitch entry, but you still need to use keys on the computer keyboard for duration (quarter notes, eighth notes, dotted notes, etc) entry. This used to be what the numeric keypad was dedicated to in Finale, and I guess it still is.
    >
    > It's no use saying that Steve needs to consider whether users *have* a numeric keypad. For users of music notation software that do a lot of note entry, it more or less necessary to have the MIDI keyboard (or to suffer a lot of pain), and it's not unreasonable to predict that such users might also acquire a numeric keypad, if their Mac doesn't already have one.
    >
    > Such software has already established the precedent that it needs lots and lots of keyboard shortcuts. (Finale is well over 10 years old, IIRC.) Steve isn't condemning users to a keyboard shortcut nightmare, he's continuing a well-established though specialized UI pattern. On this point I 100% agree with Steve's right to continue the tradition without molestation.

    Finally, somebody that understands. Thanks for explaining it all.

    > 2. Cocoa doesn't do for shortcut display in menus what Carbon did, and Steve thinks it should. On this point I 100% disagree with his position, or at least his moral outrage. It might be that Cocoa doesn't implement what he's asking for simply because no one asked before, in which case the functionality may appear in the future. On the other hand, if Apple is reluctant to sanction *generally* that apps should make a distinction between numeric keys and numeric keypad keys, I think it's well within Apple's rights to limit the scope of its own frameworks to match such guidelines. In that case, I think Steve needs to quit whining that Apple engineers aren't doing his job for him, and implement his own menu drawing for his specialized case.

    It's not that Apple isn't doing my job for me, it's that they're not doing their own job. Carbon had this ability. They didn't re-add it in Cocoa. That's what I'm complaining about. Apple killed Carbon and said "use Cocoa! It's amazing! Convert all your apps now!" That would be a whole lot easier if Cocoa offered everything that Carbon did.

    > 3. It's a question whether boxed numerals displayed in a menu are a *discoverable* design for presenting numeric keypad shortcuts to the user. On this issue, I tend to agree with the opinions expressed by Greg and Kyle that there's really no discoverable approach that will educate users directly from the menu appearance. (If this were on non-Mac computers, then a representation like "Num 1" might be an acceptable solution, because non-Mac numeric keypads have a "Num Lock" key, which gives the user a clue. But that doesn't help with a Mac numeric keypad.)
    >
    > Under the circumstances, I think there's no good solution except directing users to the documentation or help or tutorial which makes the connection between the menu appearance and the corresponding keys. (Finale and similar apps used to come with a quick-reference card that showed this sort of information. I have no idea if it still does.)
    >
    > However, I don't see a problem in having a discussion on this issue. Someone may come up with a clever idea that even Steve likes.

    Yes, if Apple comes up with better glyphs for numpad keys (and some of the others while they're at it), then that's all the better. Somewhere I recall seeing a little numpad icon beside the actual key character. Even that would be more obvious than a rounded rect around the character.

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
  • Steve Mills said: 

    > Such software has already established the precedent that it needs lots and lots of keyboard shortcuts. (Finale is well over 10 years old, IIRC.) Steve isn't condemning users to a keyboard shortcut nightmare, he's continuing a well-established though specialized UI pattern. On this point I 100% agree with Steve's right to continue the tradition without molestation.

    Finally, somebody that understands. Thanks for explaining it all.
     
    Don't confuse disagreement with lack of understanding. I understood what you were asking perfectly. I didn't say you absolutely shouldn't do it. You might recall that I even made a good faith suggestion for a technique that might accomplish it. But I also offered a reasoned rationale for why carrying that forward *might* not be the best use of your efforts. You reacted with snide hostility to a polite and sincere attempt to help you make your software as good as it could be. Think about that for a bit. (And that goes double for Steven who claimed that making such suggestions was the mark of a "fanboy.")

    > In that case, I think Steve needs to quit whining that Apple engineers aren't doing his job for him, and implement his own menu drawing for his specialized case.

    It's not that Apple isn't doing my job for me, it's that they're not doing their own job. Carbon had this ability. They didn't re-add it in Cocoa. That's what I'm complaining about. Apple killed Carbon and said "use Cocoa! It's amazing! Convert all your apps now!" That would be a whole lot easier if Cocoa offered everything that Carbon did.
     
    You need to consider the possibility that Apple decided that not everything Carbon was able to do was legitimate to carry forward. That some of it might have even been fundamentally detrimental to user experience. It's among the most common reasons for behavior to be deprecated.

    Yes, if Apple comes up with better glyphs for numpad keys (and some of the others while they're at it), then that's all the better. Somewhere I recall seeing a little numpad icon beside the actual key character. Even that would be more obvious than a rounded rect around the character.
     
    You may be surprised to hear that I agree. Remember, I made two arguments. Not everyone has the keys and the glyph isn't sufficiently descriptive. Better glyph immediately eliminates the more problematic half of my concern. You could quite easily do the "little numpad icon" yourself, just like whatever developer created the one you remember.
  • That's the problem with legacy. We learn from the past, and realize
    our mistakes. But sometimes we can't fix them, because users already
    depend on them. Or rather, we do fix them, and anger lots of people
    who need it to keep working the old way. Reminds me of
    http://xkcd.com/1172/ ... "legacy: can't live with it, can't get rid
    of it".

    On Tue, May 7, 2013 at 6:45 PM, gweston <gweston...> wrote:
    > Steve Mills said:
    >
    >> Such software has already established the precedent that it needs lots and
    >> lots of keyboard shortcuts. (Finale is well over 10 years old, IIRC.) Steve
    >> isn't condemning users to a keyboard shortcut nightmare, he's continuing a
    >> well-established though specialized UI pattern. On this point I 100% agree
    >> with Steve's right to continue the tradition without molestation.
    >
    >
    > Finally, somebody that understands. Thanks for explaining it all.
    >
    > Don't confuse disagreement with lack of understanding. I understood what you
    > were asking perfectly. I didn't say you absolutely shouldn't do it. You
    > might recall that I even made a good faith suggestion for a technique that
    > might accomplish it. But I also offered a reasoned rationale for why
    > carrying that forward *might* not be the best use of your efforts. You
    > reacted with snide hostility to a polite and sincere attempt to help you
    > make your software as good as it could be. Think about that for a bit. (And
    > that goes double for Steven who claimed that making such suggestions was the
    > mark of a "fanboy.")
    >
    >
    >
    >> In that case, I think Steve needs to quit whining that Apple engineers
    >> aren't doing his job for him, and implement his own menu drawing for his
    >> specialized case.
    >
    >
    > It's not that Apple isn't doing my job for me, it's that they're not doing
    > their own job. Carbon had this ability. They didn't re-add it in Cocoa.
    > That's what I'm complaining about. Apple killed Carbon and said "use Cocoa!
    > It's amazing! Convert all your apps now!" That would be a whole lot easier
    > if Cocoa offered everything that Carbon did.
    >
    > You need to consider the possibility that Apple decided that not everything
    > Carbon was able to do was legitimate to carry forward. That some of it might
    > have even been fundamentally detrimental to user experience. It's among the
    > most common reasons for behavior to be deprecated.
    >
    >
    >
    > Yes, if Apple comes up with better glyphs for numpad keys (and some of the
    > others while they're at it), then that's all the better. Somewhere I recall
    > seeing a little numpad icon beside the actual key character. Even that would
    > be more obvious than a rounded rect around the character.
    >
    > You may be surprised to hear that I agree. Remember, I made two arguments.
    > Not everyone has the keys and the glyph isn't sufficiently descriptive.
    > Better glyph immediately eliminates the more problematic half of my concern.
    > You could quite easily do the "little numpad icon" yourself, just like
    > whatever developer created the one you remember.
  • On May 7, 2013, at 4:45 PM, gweston <gweston...> wrote:

    >> In that case, I think Steve needs to quit whining that Apple engineers aren't doing his job for him, and implement his own menu drawing for his specialized case.
    >
    > You need to consider the possibility that Apple decided that not everything Carbon was able to do was legitimate to carry forward. That some of it might have even been fundamentally detrimental to user experience. It's among the most common reasons for behavior to be deprecated.

    In this case, it's really more a lack of demonstrated interest as evidenced by Radar. I did a little Radar searching and found one Radar requesting support for numeric keypad command keys. That was from 2002. That bug is still in Analyze and there's no reason we couldn't do it in a future release if there's more interest in this feature expressed by developers. But the fact that it hasn't been done, in this case, has nothing to do with a desire to deprecate the feature.

    Of course, ideally we would have provided every feature in Cocoa that was in active use by Carbon developers already. No debate there. But bugs and features get priority based on demand.

    -eric
  • Hi, I'm Dave, senior engineer at Adobe Systems.

    We definitely want this functionality, in fact filed a DTS incident for (and got some help with) custom-drawing menu items, for the express purpose of drawing an arbitrary string as the "keyboard shortcut" in menus.  and i can tell you the work around was a PITA and is a bit fragile.

    we really want this for the reason originally stated (eg: "Numpad +") but also to draw any string eg: "tap ⇧") as the "shortcut".

    really the only API we need is something like "SetMenuItemShortcutString()", and rather than passing in a character, pass in a string, and have the OS "just take care of it".

    we're wanting this not just for After Effects but also for all "DVA" products (many of the ones in "Creative Cloud")

    so, please consider that "all of adobe wants this"

    On May 7, 2013, at 5:05 PM, Eric Schlegel <ericsc...> wrote:

    >
    > On May 7, 2013, at 4:45 PM, gweston <gweston...> wrote:
    >
    >>> In that case, I think Steve needs to quit whining that Apple engineers aren't doing his job for him, and implement his own menu drawing for his specialized case.
    >>
    >> You need to consider the possibility that Apple decided that not everything Carbon was able to do was legitimate to carry forward. That some of it might have even been fundamentally detrimental to user experience. It's among the most common reasons for behavior to be deprecated.
    >
    > In this case, it's really more a lack of demonstrated interest as evidenced by Radar. I did a little Radar searching and found one Radar requesting support for numeric keypad command keys. That was from 2002. That bug is still in Analyze and there's no reason we couldn't do it in a future release if there's more interest in this feature expressed by developers. But the fact that it hasn't been done, in this case, has nothing to do with a desire to deprecate the feature.
    >
    > Of course, ideally we would have provided every feature in Cocoa that was in active use by Carbon developers already. No debate there. But bugs and features get priority based on demand.
    >
    > -eric
    >
  • On May 8, 2013, at 7:36, "David M. Cotter" <me...> wrote:

    > […] filed a DTS incident for (and got some help with) custom-drawing menu items, for the express purpose of drawing an arbitrary string as the "keyboard shortcut" in menus.  and i can tell you the work around was a PITA and is a bit fragile.

    Would you be able to share this code?

    TextMate also draws a custom string as key equivalent because of Cocoa issues. Carbon worked better but is unavailable when building as 64 bit.

    TextMate’s implementation is here https://github.com/textmate/textmate/blob/master/Frameworks/OakAppKit/src/N
    SMenuItem%20Additions.mm#L170-L189
    and sets the title as an attributed string using an NSTextTableBlock to have the key equivalent string show as the second column. This is fairly unobtrusive and the only (user visible) shortcoming I have found is that it doesn’t left/right align the key/modifier glyphs and writes out F1-Fn instead of using the special glyphs for these keys.

    While it (presently) doesn’t do anything special for the numpad modifier, I also see value in rendering the numpad keys. In my case, the user can setup custom key bindings, and expert users do like to bind some stuff only to the numpad keys.

    I should add that the reason TextMAte uses custom rendering is primarily motivated by not having NSMenuItem handle the key equivalent, as it is unaware of multi-stroke key bindings in progress (dispite being a framework feature) and because it is unable to deal with multiple menu items sharing key equivalent (when the menu items’ action differs).
  • On May 7, 2013, at 5:36 PM, "David M. Cotter" <me...> wrote:

    > Hi, I'm Dave, senior engineer at Adobe Systems.
    >
    > We definitely want this functionality, in fact filed a DTS incident for (and got some help with) custom-drawing menu items, for the express purpose of drawing an arbitrary string as the "keyboard shortcut" in menus.  and i can tell you the work around was a PITA and is a bit fragile.
    >
    > we really want this for the reason originally stated (eg: "Numpad +") but also to draw any string eg: "tap ⇧") as the "shortcut".
    >
    > really the only API we need is something like "SetMenuItemShortcutString()", and rather than passing in a character, pass in a string, and have the OS "just take care of it".
    >
    > we're wanting this not just for After Effects but also for all "DVA" products (many of the ones in "Creative Cloud")
    >
    > so, please consider that "all of adobe wants this"

    The correct way to express this request is to file a Radar: http://bugreport.apple.com

    --Kyle Sluder
  • On May 7, 2013, at 7:00 PM, Allan Odgaard <lists+<cocoa-dev...> wrote:

    > TextMate’s implementation is here https://github.com/textmate/textmate/blob/master/Frameworks/OakAppKit/src/N
    SMenuItem%20Additions.mm#L170-L189
    and sets the title as an attributed string using an NSTextTableBlock to have the key equivalent string show as the second column. This is fairly unobtrusive and the only (user visible) shortcoming I have found is that it doesn’t left/right align the key/modifier glyphs and writes out F1-Fn instead of using the special glyphs for these keys.

    Any reason you're not using a custom view-based NSMenuItem? It might be easier to get good results that way.

    --Kyle Sluder
  • On May 8, 2013, at 9:28, Kyle Sluder <kyle...> wrote:

    >> […] sets the title as an attributed string using an NSTextTableBlock […]
    > Any reason you're not using a custom view-based NSMenuItem? It might be easier to get good results that way.

    A custom view means you have to render everything yourself. That is not only a lot of work as you have to match the OS exactly for the different states a menu item can be in, drawing the selection gradient, and maybe also have to deal with accessibility. But it’s also code that you will need to update if the look of the menus change in the future.

    No doubt in my mind that the sometimes non-optimal glyph alignment is to prefer over the above.
  • > Would you be able to share this code?
    well, it's incomplete at the moment, i haven't sewn it all up.    and besides that i'd have to get permission to share it, as it's "adobe" code.  i'm on sabbatical now so i'm not even really "here" too.

    > TextMate also draws a custom string as key equivalent ... the only (user visible) shortcoming I have found is that it doesn’t left/right align the key/modifier glyphs
    this was a requirement of ours, to have it actually be right aligned, that's why we needed a custom view

    > It would be great if you submitted a radar for this
    sure, just that i'm on vacation and will be for a long while.  and when i get back i don't know that this will be "a priority".  at least it's known that we want this.

    > ability to set key equiv by glyph or key code
    actually our need is to have the ability to have an arbitrary *string* appear as the "shortcut".  we don't care about the actual key equivalent, since we already handle this internally (not using OS)
  • On May 8, 2013, at 23:17, "David M. Cotter" <me...> wrote:

    >> TextMate also draws a custom string as key equivalent ... the only (user visible) shortcoming I have found is that it doesn’t left/right align the key/modifier glyphs
    > this was a requirement of ours, to have it actually be right aligned, that's why we needed a custom view

    The string itself is right-aligned. The issue is with not aligning on the split between the modifier(s) and keys, e.g.:

    Here the modifiers for the C-binding is not aligned correctly with those of the P-bindings.

    A fix could be to enforce a minimum width for the character, but not sure if there are string/paragraph attributes which allow this.

    Another solution I am considering is using an image in the attributed string — this should provide most of the advantages of not replacing the menu item (with a custom view) yet give complete control over rendering of the “activation string”.

    >> ability to set key equiv by glyph or key code
    > actually our need is to have the ability to have an arbitrary *string* appear as the "shortcut".  we don't care about the actual key equivalent, since we already handle this internally (not using OS)

    This API would also fail to align modifiers across strings.
  • On May 7, 2013, at 21:00:00, Allan Odgaard <lists+<cocoa-dev...> wrote:

    > TextMate’s implementation is here https://github.com/textmate/textmate/blob/master/Frameworks/OakAppKit/src/N
    SMenuItem%20Additions.mm#L170-L189
    and sets the title as an attributed string using an NSTextTableBlock to have the key equivalent string show as the second column. This is fairly unobtrusive and the only (user visible) shortcoming I have found is that it doesn’t left/right align the key/modifier glyphs and writes out F1-Fn instead of using the special glyphs for these keys.

    Allan, I've tried using your approach, which works better than what we did before (setting the title to "Do Something      numpad1", so it was never even close to being in the key equiv column). But what do you do about having the actual keyEquivalent set? If I leave that set at, for instance, command-1, it draws to the right of my attributed title. Do you clear the key equiv from menu items and use your own key equiv lookup elsewhere?

    --
    Steve Mills
    office: 952-818-3871
    home: 952-401-6255
    cell: 612-803-6157
previous month may 2013 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Go to today