Re: NSMenuView and popups (was: Re: [PATCH] Menus in lowerleft corner)

[Fred Kiefer]

Hi Wim,

sorry, for never replying to this mail. It somehow got lost while I was 
preparing for my holiday trip.

Willem Rein Oudshoorn wrote:
> Fred Kiefer <FredKiefer@gmx.de> writes:
> > Willem Rein Oudshoorn wrote:
> > > > Since the NSMenuViewWindowTitleBar-thingie is created in NSMenuView's
> > > > initWithFrame, and the NSMenu creating the NSMenuView doesn't know its owned by
> > > > a popup until right after its init, we are slightly screwed. I suppose we could
> > > > catch this on the first sizeToFit in NSMenuView -- like we catch the left
> > > > offset?
>
> > > NSMenuView class into two:  GSPopupMenuView and GSMenuView.
> > > But your suggestion is easier and Fred Kiefer might object
> > > to the split.
> >
> > looks as if there was some misunderstanding. I am strongly in favour
> > of such a change. If there is sufficent difference between these cases
> > split them up!
> > What I don't like is, that you came up with a new protocoll for
> > NSMenuView, which is not there in MacOSX nor Openstep and which is
> > also not required for this change, as both classes will have the
> > superclass NSMenuView.
>
>
> Is there any other reason why you are against the protocol instead
> of not being present in OpenStep / MacOSX?  

This the stronger of the two arguments against it. When there is no 
reason to deviate from the published interface don't do so.
The other one was only hinted here and stated in the other mail: You 
don't get any benefit from the protocol, as still only subclasses of 
NSMenuView are usable.

> Also note that I see it more as an informal protocol codifying 
> the interaction between NSMenuView with NSMenu, NSMenuItem and other 
> NSMenuView's.

Documentation of used interfaces could be a valid reason to interduce an 
interface. But the result of this is not really convincing. This is no 
actual usable protocol, in any stronger design sense, but just a list of 
currently used methods. Wouldn't it be better to flag the unused methods 
of the class NSMenuView in some way?

> The disadvantage if inheriting from NSMenuView are the methods:
>
> - setHorizontal
> - setWindowFrameForAttachingToRect:onScreen:preferredEdge:popUpSelectedItem:
>
> which are not always appropriate for the different kind of menus.
> or methods like:
>
> - attachedMenu
>
> which should belong to NSMenu.

You are right here. But just look at the subclasses of NSControl, some 
of them don't even have cells and still have all the methods to handle 
them. From a purely theoretical point of few this is nonsense but in a 
less optimal world safe us from loads of superclasses. It is one of the 
great beauties of OpenStep that it only did require so few classes. They 
may be implemented with a lot more going on in the background, but you 
don't have to see and know this. We should stick with that prinziple. If 
your new superclass could be hidden from the outside world (as will be 
GSPopupMenuView) I would not reject it.


> Also in my opinion the hierarchy should look like:
>
>
>     GSMenuView  (implements informally the NSMenuView protocol)
>        |
>        |
>    +---+--------------+
> GSPopupMenuView   NSMenuView

JUst have a short look at the actual code differences between these two 
classes. Apart from the few additional methods not used by the popup 
subclass there wont be much in NSMenuView.

> Instead of:
>
>    NSMenuView
>       |
>    GSPopupMenuView

What about implementing this as a first step and if you are still not 
satisfied with the result we discuss what should be moved to a new 
superclass GSMenuView.

> Because what do you imagine that setHorizontal: YES on 
> the GSPopupMenuView should do?

You better don't ask me! I have a rather clear idea for this.

> Also, remember that according to the documentation the 
> NSMenuView class and friends do not work and are depricated.