Re: [PATCH] NSMenu patch version 2.

[Willem Rein Oudshoorn]

Fred Kiefer <FredKiefer@gmx.de> writes:

> Hi Wim,
> 
> What I did not understadnd about your changes is the introduction of
> the NSMenuView protocol. I could not find this in my MacOSX
> documentation and I also see no additional value in it.  The code in
> the (deprecated) method setMenuRepresentation: checks if the handed
> in view is a subclass of NSMenuView, so anything else never could be
> used. Also most of the interaction between the MenuView and the Menu
> is generic and will be used by all menu views, whichever way they
> will draw. I would say that allowing for subclasses is sufficient
> here. And perhaps we could even move some of the declaration of the
> interface between the menu and its view into a private file.


Let me try to explain my reasoning behind adding the NSMenuView protocol.
Some of them are personal preferences, some of them might be 
considered technical arguments.  Let me say beforehand that I am 
not very attached to the protocol so if there are good reasons
to remove the protocol again I will not object.


* [PERSONAL]  I do not like the fact that you are forced to subclass.
  If I now what I am doing I should be allowed to put any object
  as a menurepresentation.  That is why I like informal protocols
  better than requiring a subclass.

* [PERSONAL]  The coupling between NSMenu and NSMenuView is tight
  and for me was a little hard to understand.  By trying to make
  explicit what the expected behaviour is of an NSMenuView I
  hope it somehow becomes easier to understand.

* [TECHNICAL]  The NSMenuView class now implements 
  3 look and feels:

   - Horizontal menus
   - Vertical menus
   - Popupbuttons

  I think it is cleaner if they are seperated into 3 classes:
  GSHorizontalMenuView, NSMenuView, GSPopupButtonMenuView.
  Or something similar.  In order to make this separation possible
  It would be better not to force someone to subclass an 
  already somewhat bloated class.


Compatibility with Apple
------------------------

I do not think that Apple compatibility is very important 
with respect to the NSMenu/NSMenuView/NSMenuItem split.
First of all:

* OpenStep specification does not mention NSMenuView, NSMenuItem at all.

* Apple documentation supplied by WebObjects 4.5 does mention NSMenuView
  as being currently under development.

* Apple MacOSX documentation claims that NSMenView is not used at
  all for drawing menus and that setting menurepresentation does
  not work.



Problems with NSMenu
--------------------

The split in an NSMenu and NSMenuView is, in my opinion,
a good split.   However, the way it is done now has its
share of problems.   The main source of the problems
is the way Apple/NeXT(?) did design the split.  If you are 
interested I can write down what I do not like about 
Apple's split and how it could be done differently.

As for why Apple/NeXT did it the way they did I can 
only guess.  But I think that:

* Porting AppKit to other platforms, like YellowBox
  and/or Rhapsody. (??)  Forced them to rewrite the
  NSMenu code to implement a more native look and feel.
  
  This probably triggered the introduction of the NSMenuView
  class.

* But they were hampered by API and binary compatibility 
  on OpenStep.  So they could not change the code and
  logic of the NSMenu and friends to make it 
  nice and consistent.  Also there was probably not 
  a great demand for a nice NSMenu (View|Item|..) 
  design.  



Summary
-------

The NSMenuView protocol is here because I think that
in nice consistent implementation of the NSMenu(View|Item...)
there is a central place for such an protocol.

Second.  It think it makes the implementation clearer.


I realize that I have not written down at all how I 
envision the NSMenu... to work.  But in all honesty,
I do not think I will implement it.  (time time...)

Hope this answers your question.


Wim Oudshoorn.