Re: NSPopUpButton related new patches

[Serg Stoyan]

Hello Nicola,

> > > In other words, yes, I think it's definitely
> > > gnustep-gui's responsibility to make sure things are displayed
> > > properly :-) and images are not drawn over key equivalents :-) 
> > > it's a bug we need to fix.
> > 
> >     Now it's fixed (NSMenuItemCell.m.patch). It's also moves code
> >     that drawing right arrow from drawKeyEquivalentWithFrame: into
> >     drawImageWithFrame: so key equivalent draws only if no image
> >     (right arrow in menu or any other like in NSPopUpButton).
> 
> Interesting.  
> 
> <looking at the code>
> 
> Hmmm - there is a trick here. :-)

[snip]

> This feature is nice ... I'm not sure if we want to loose it.

At first sight it's nice feature, but...
I can't imagine situation when I want to set image for submenu item.
Moreover this feature leads to ugly looking application menus. On
the other hand menu items (which doesn't have submenus) sometimes needs
images, like items in "Windows" submenu (state image?). Sure this is
only IMHO and subject to discuss. So if I understand correctly we have
the following properties for menu items:

- tile (draws if exist);
- key equivalent (draws if exist and item has no submenu);
- state image (draws if item has no submenu).

> This feature is why the '->' image of menu items with submenus is
> drawn as if it were a key equivalent (effectively, it graphically
> replaces the key equivalent).  It can't be drawn in the actual
> 'drawImage:' method, as that method is used to draw the (optional)
> menuItem image.
> 
> Of course we need to fix the bug.
> 
> Any ideas of how to do ?  We might drop the 'feature' of having an
> image for menu items having submenus if really there is no better way
> out.

If people vote for leaving this feature, I've attached patch that fixes
that bug in other way.

-- 
Serg Stoyan

NSMenuItemCell.m.patch
Description: Binary data