[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Willem Rein Oudshoorn
Subject: Re: [semi-PATCH] menu title bar sizing & menu close button
Date: 14 Mar 2003 20:30:50 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Serg Stoyan <address@hidden> writes:

> Hello Michael,
> > Here are a few modifications for NSMenuView.m.
> > 
> > =====
> > First: menus without items have a titlebar sized to just the title of
> > the menu. However, when you tear such a menu off the close button gets
> > plopped on there. This first fix adds some space in the NSMenuView
> > -sizeToFit to account for our button.
> > =====
> > 
> > (once again, I can't reach the CVS server so this is ugly, sorry.)
> > 
> > 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
>   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 you'r proposed solution will keep the menu 101 pixels
wide instead of the intended 110.

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.

>> * 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

-[NSControl setRefusesFirstResponder: YES]

should do the trick.  So I guess it is a bug, but please
prove me wrong.

Wim Oudshoorn.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]