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

[Willem Rein Oudshoorn]

Fred Kiefer <FredKiefer@gmx.de> writes:

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

I agree with this sentiment.  However, the whole NSMenu cluster 
is depricated for quite a long time. 

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

I know.  I forgot to change the code in NSMenu to check for protocol
adherence.

[PERSONAL PREFERENCE RANT ON]
        
   Actually the check in NSMenu that menurepresentation is an instance
   of the NSMenView class was the reason for making the protocol.

   I really dislikes these checks.  

   If I am allowed to set the menurepresentation and I do not want to
   subclass NSMenView, why is this stupid library forbidding this?
   Just tell me what to implement and let me decide how I organize my
   inheritance structure!

[PERSONAL PREFERENCE RANT OFF]


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

Than my attempt at documenting the protocol failed.  I intended
it to be documentation that can be used to write a custom
NSMenuView class.  

> Wouldn't it be better to flag the
> unused methods of the class NSMenuView in some way?

Well, just flagging is not enough.  You want to document two 
things:

a - What the implementation in the NSMenuView class does
b - When you want to override/change the behaviour, how
    it should behave so it will work together with 
    NSMenu and other NSMenuView implementations.


[REMOVED section from Fred explaining that NSControl 
also has methods that are not always needed]
> 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. 

Completely agree.

>If your new superclass could be hidden from the
> outside world (as will be GSPopupMenuView) I would not reject it.

For this I had two approaches in mind, but I am not sure which one
would be best.

A - The only visible "object" is the NSMenuView protocol.
    the fact that we have a default implementation is hidden.
 
    [This deviates from the specs]

B - We have two visible "object"s the NSMenuView protocol
    and the NSMenuView class.

    The NSMenuView class implements the NSMenuView protocol
    and the methods specified in the Apple documentation
    Version????

    [This keeps backward compatibility with the API].

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

True.  

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

Yes I agree with this approach.   It was definitely the way
I would have started.  (before I got sidetracked by work
and life outside work.)

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

Well, you are right that there is actually no reason not to 
implement horizontal popup menus.  (also there is no
compelling reason to implement them.)

The best structure really depends on how to handle horizontal
menus, and how strict we want to follow the depricated interface
of Apple.


Option A
--------
  We stick to Apples documentation (although it says it is
  depricated and the methods do NOT work on MacOSX or
  YellowBox ...)

  - advantages:
    * We stay compatible with old GNUstep releases.
    * There is documentation by Apple

  - disadvantages:
    * The NSMenuView class becomes more cumbersome

Option B
--------
 We choose our own path with respect how to handle menus
 and horizontal menus in particular.  
 
 - advantages:
    * It is easier to replace the menurepresentation
      with custom menurepresentations.  For example
      to implement native menus.
    * It is cleaner (IMHO)  

 - disadvantages:
    * It is not strictly following Apple



My preference is B.  But I realized that that is not
something to do lightly and therefore I did not do this.

I still think that for documentation purposes it makes
sense to have a protocol. 
(If not a formal protocol, make it an informal.)

So for the short term my proposal would be:

- Keep protocol
- Improve documentation protocol

slightly longer term:

- Take a second look at the menu classes and how much
  we gain by using seperate implementations.
 

Wim Oudshoorn.