Re: request for comment on how to implement menus
- Bjorn Winckler wrote:
> I think I was a bit unclear in my previous post, so in order to understandThat sounds very good to me.
> the problem I will say something about the menu handling in Cocoa.
> Hopefully this will clarify the situation.
> 1. The text on that goes on the right hand side of the menu item is handled
> by Cocoa. You can only specify which "accelerator key" should go there
> (specifically, you can specify a printable key, e.g. "o", and modifiers, e.g.
> "Cmd") and Cocoa will do the drawing. Hence, it is not possible to display
> things like ":e". (I'm just restating what Jiang said in his post here.)
> 2. There are no "menu accelerators", where one letter of the menu item is
> underlined and pressing Alt+'that letter' brings up a menu and then pressing
> another letter will select a menu item in that menu. That is, you cannot
> navigate through menus with the keyboard (correct me if I'm wrong here, but
> I don't know of any way to do so).
> 3. Cocoa intercepts key presses, checks if any menu item is "bound" to that
> key combination (the Cmd key is always part of such a binding). If Cocoa
> finds a menu item bound the key combination, it briefly highlights the menu
> on the menu bar which contains that menu item, and calls the 'action
> message' of that menu item. This 'feature' can be disabled by hacking a
> little, so that key presses go straight to Vim, but this means that the menu
> won't get highlighted (a minor disturbance, but this is the behaviour you
> expect from an OS X application, so I would like to preserve it.)
> Now to get back to my proposal. If there was a command like this in Vim:
> :menukeyequiv File.Open <D-o>
> Then, you could make all the usual bindings (i.e. the usual ones for an OS X
> app) in a .vim file which gets sourced some time after menu.vim has been
> sourced (thus also making it possible to internationalize key equivalents).
> The implementation of :menukeyequiv itself would simply pass the key
> combination (e.g. <D-o>) and the appropriate vimmenu_T* ( File.Open) to the
> GUI, which can then set the key equivalent of the menu item. Then, if the
> user presses <D-o>, Cocoa intercepts this event, sees that it is bound to
> the "Open" menu item under the "File" menu and calls its action message (in
> this case, vimMenuItemAction:, which tells Vim to execute a menu item with
> The negative side effect of this is noticed if somebody tries to remap <D-o>Well, if someone wants to map <D-o> he will have to remove any menu item
> with :map, since :map will think that <D-o> is not already bound to
> something. When the user then presses <D-o> it is intercepted by the GUI
> and the <D-o> event never reaches Vim. Of course, if you make it clear (
> e.g. in :help MacVim) what is going on, then this should not be such a big
> problem. (The key equivalent would be forced to contain the Cmd modifier
> because this is expected behaviour.)
that captures this key. I don't think this is a problem, people are
aware a key may already be in use. The only problem may be that
removing the menu can be a bit complicated. Ideally there would be a
menu command to delete the menu associated with a specific key. But
having the user find the menu and using the menu name itself would also
> Without something like I outline above, you can of course do what the CarbonIt also means you have to keep key mappings and menu entries in sync,
> port does: make all the usual (as in "OS X app usual") bindings in a .vim
> file (<D-o>, <D-c>, etc.) with :map, but this means that the text on the
> right hand side of all menu items will be empty, and the menu highlighting I
> mentioned above won't work. From a OS X point of view this is quite
> confusing, but it I guess it makes "Vim-sense".
everything is there twice.
> Since I am trying to make Vim more OS X like I would strongly prefer the wayAgreed.
> I suggested above (i.e. I want the key equiv text on the right hand side
> _and_ the highlighting), but I will not do it if it is deemed to clash too
> much with how Vim works.
> I agree...this is how it could be done: I would implement a Vim commandSounds good to me.
> called e.g. ':action' which is used like this:
> :action vimNewWindow:
> When executed, ':action' passes the argument (vimNewWindow:, the name of an
> action message) to the GUI. Then it would be possible to do this:
> :menu File.New\ Window :action vimNewWindow:
> That seems like a good solution to me...any objections?
hundred-and-one symptoms of being an internet addict:
50. The last girl you picked up was only a jpeg.
/// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php