Re: [semi-PATCH] menu title bar sizing & menu close button

[Serg Stoyan]

Hello Willem,

> Serg Stoyan <stoyan@hologr.com> writes:

[striped Michael explanations]

> > > In NSMenuView sizeToFit (around line 511):
> > > 
> > > >>>>>
> > > // the close button is 15 pixels, 4 for padding.
> > > float    neededImageAndTitleWidth = [_font widthOfString: [_menu
> > > title]] + 15.0+ 4.0;
> > > <<<<<
> 
> [ Snipped some comments here]
> 
> >   This makes all menus wider because 15+4 pixels _always_ added.
> 
> No, actually it does not.  Basically the code loops like:
> 
> while we have an menu item:
>    neededImageAndTitleWidth = 
>      MAX (neededImageAndTitleWidth, menu item width)
> 
> So adjusting the the initial setting of neededImage...Width
> will only increase the lower bound of the width and this is
> correct.

  Logically you're right. Practically it works with my patch. I guess the
  reason of wider menus is following: after initial setup of
  neededImageAndTitleWidth to widthOfString + 15 + 4,
  neededImageAndTitleWidth increase one more time on 15 (or so) pixels.
  This is explains why my patch works and why with Michael's one menus
  starts to be wider. Anyway I'll start to investigate this situation.

> >   Attached patch (NSMenuView.m.patch) makes adding 10 pixels (why 10?
> >   got it in empiric way) only if neededImageAndTitleWidth not changed
> >   after cycling through the menu items (menu title string is wider
> >   than any menu items or there is no menu items at all).
> 
> This solution will have a problem when:
> 
> Menu Title is 100 pixels wide
> Menu content is 101 pixels wide
> 
> Then yore proposed solution will keep the menu 101 pixels
> wide instead of the intended 110.

  See above. 

> Also I think this whole sizeToFit method could be cleaned up.
> But I have not looked at it carefully so it is perhaps as
> complicated as it looks.

  I think sizeToFit must be more clear to understand. Thank you for kicking
  my mind. ;) I'm starting to clear sizeToFit up.

> >> * NSButton does not honor (NSControl) setRefusesFirstResponder:. I'm
> >> not sure if thats correct or a bug. However, it does cause the
> >> dottedRect to appear in the close button -- ugly.
> >
> >   As I can understand NeXT and Apple documentation, control have to
> >   override acceptsFirstResponder and return NO when no need to draw
> >   dotted rectangle. 
> >
> Hm, I could not find this.  As far as I could determine the call

  NSButton inheritance is:
  NSControl : NSView : NSResponder : NSObject

  So looking at NSResponder -> acceptsFirstResponder:
[cite on]
   Overridden by subclasses to return YES if the receiver can handle key
   events and action messages sent up the responder chain. NSResponder's
   implementation returns NO, indicating that by default a responder object
   doesn't agree to become first responder. Objects that aren't first
   responder can receive mouse event messages, but no other event or action
   messages.
[cite off]

> -[NSControl setRefusesFirstResponder: YES]
> 
> should do the trick.  So I guess it is a bug, but please
> prove me wrong.

  It has to do the trick, but... First of all it doesn't. And second it is
  not OpenStep compliant (but how cares?:).

  Anyway let's clear situation: setRefusesFirstResponder doesn't work, have
  to be fixed and is a Cocoa way, overriding of acceptsFirstResponder works
  and it is an OpenStep way and thus more general in use (as example for
  NSButton subclasses).

-- 
Serg Stoyan