bug-gnustep
[Top][All Lists]
Advanced

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

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


From: Fred Kiefer
Subject: Re: NSMenuView and popups (was: Re: [PATCH] Menus in lowerleft corner)
Date: Tue, 08 Apr 2003 23:40:48 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020903

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.







reply via email to

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