Re: NSMenu* and NSPopuUp* issues

[Serg Stoyan]

Hi Fred,

> Hi Serg,
> 
> I was away for two weeks so I did miss out on the whole discussion on
> the removal of horizontal menus. But I must say, that I am shoked by the
> way this was handled by you.
> There have been a few objections (e.g. by Alex Perez and Josh 
> Rendlesham) raised against the decision to remove horizontal menus and 
> against your own statement you still did apply this change.

  These objections is mostly "I wish to" and "I'd prefer to".

[snip]

>   > Personally, I don't like having horizontal menus. The main reason is
>   > what you said: mess in GNUstep menu code. It's hard to maintain and
>   > really noone badly need this. I've not seen any contructive
>   > objections against removing this code from GNUstep. So I'll remove
>   > it.
> 
> If you did not regard those objections as "constructive" you should 
> explain why this is the case. Not just ignore them. This may give the 
> impression that you regard any deviating view as non-constructive.

  See above. And nobody prove why we should keep horizontal menus in
  GNUstep codebase. Implementing it as theme bundle satisfy all needs
  while keep -gui simple and clean for bug fixing and stability.

> In another mail you want to establish youself as the class maintainer
> for the NSMenu class cluster. With your curent attitude towards opposing
> positions, I would strongly by against such a step.

  No problem. I can drop it.

> Now to the real question at hand.
> In the discussion of the horizontal menu issue to seperate items have 
> been mixed:
> 1) The technical support for horizontal menu views.

  Does theme bundle not satisfy your needs?

> 2) User interface policies using horizontal menus.

  For short, we should stick to OPENSTEP or NeXTstep UI, IMHO.

> Of course the later is only possible given the former, but the opposit
> is not necessarily true. I think most people in the GNUstep community
> don't want to use a user interface with horizontal menus ourself. Still
> I cannot think of any reason to oppose the posibility of such an
> interface or of the many other uses a horizontal menu view could be
> brought to. So instead of discussing the later we should only talk about
> the support for horizontal menus in GUI.

  That is.

> So what was the problem with the current code here? As your reasoning is 
> not that explicit I have to come up with my own:
> 
> 1) The class is deprecated in MacOSX and does not exist in OpenStep.
> 
> This is perhaps a reason to drop the whole class, but not for any 
> specific change.

  Agree.

> 2) GNUstep is currently not using this feature.
> 
> True, but there is a lot more in the source where the same is true and 
> we wont remove this. And when we will be implementing other user 
> interface policies we will need it (Although I wont use this). And also 
> there may already be people out there using it.

  Theme bundle.

> 3) This feature bloats up the code of NSMenuView.
> 
> I don't think this was true. There were about six places in the file 
> where the horizontal property was used just to do either one or the 
> other value computation. If such simple code is to hard to maintain, we 
> really should give up on GUI.

  It was at that moment. But it's needed to be finished, polished,
  improved. Are you sure it will remain simple and easy to maintain? 
  I'm not.

> 4) It was broken anyway. ("Semi-working" in your words)
> 
> So which part was working and what did break the other part? I once did 
> use horizontal menus myself, just for funs sake and fixed them at that 
> time. If they were broken again this would be enought reason to fix this 
> not to remove it.

  I mean that it should be cleanup, improve (title bar, positioning,
  resizing) and so on.

> 5) The same can be achieved in a bundle anyway.
> 
> I did not test this, but it surely is true. But having to support an 
> extra bundle to just save some odd twenty lines of code in NSMenuView 
> looks strange to me. We will deviate from a documented (although 
> deprecated) interface and point people to a seperate bundle? And the 
> method setHorizontal: wont be possible this way.

  Exactly. It is not OpenStep compatible and there is no obvious reason to
  keep this in main codebase.

> 6) It will come back as soon as Wims changes to split up NSMenuView get 
> applied.
> 
> Sorry I don't get this. Will we have this code than or not? Vertical and 
> horizontal menus behave just the same. The only difference is in the 
> appearance. The next step in this logic would be to supply separate 
> classes for vertical and horizontal NSScroller or even for NSCell with 
> or without a border. This is possible and may be appropriate in some 
> cases, but I don't see it in this.

  I didn't say this.

> 7) I don't like horizontal menus.
> 
> Ok, this is the only reason I cannot argue with. You have all the right 
> in the world to think so, but this does not allow you to remove this 
> code. Please remember that for some time this was part of the offical 
> interface of MacOSX and GNUstep. We allways claim that we want to do 
> things better than Apple. What they get blaimed for is that they keep on 
> chaning the interface all the time. We should not follow them in this. 
> Especially not when it is just a question of taste.

  It's the same reason as "I like it" and "I'd prefer to use it", no? :)
  But this is the most amount of reasons/objections I've heard.

> BTW. you also did break the comaptibility of the encoding/decoding code. 
> I am not sure if this gets used for the popup, otherwise this wont do a 
> harm.

  Is there a real harm? Did anybody claim for problems with it?

> While I am still upset, there is one other issue I have to set straight:
> I am in favour of splitting up a subclass of NSMenuView for popup 
> buttons. Here the actual behaviour is different and very specific. We 
> also will need a subclass of NSMenu and NSMenuItemCell to support this.
> But what I don't see the need for is horizontal menu. What I did oppose 
> also was the introduction of the NSMenuView protocol as this only make 
> things harder to understand. We don't need this and there is no reason 
> for it at all.

  I see no problem here. It was Wim's suggestions, not mine.

> To finish off more positive: Apart from this change I like the progress 
> of the menu cluster and anyway I would prefer to spend my time 
> programming instead of writing long mails.

  Write horizontal menu bundle, please. :) 

Fred, the main huge reason I removed horizontal code is to reach stable,
finished _working_ implementation of OpenStep. I want to work with real
GNUstep applications instead of playing with horizontal/diagonal/whatever
menus. We'll never finish gnustep-gui if we start implementing all
"bloatware" that comes to our minds. Don't get me wrong, I'm not against
you or horizontal menus, I'm against bloating the GNUstep -base -gui and so
on with extra features. One day we'll reach the 1.0 state and add
horizontal menus, MS Windows-style menus (inside windows), Apple-like top
horizontal menus with status bar and so on. But now we should make all
possible to have stable, bugfree, with enough features to write good
_usable_ apps.

If it's not enough reason, I'll drop maintenance of NSMenu related code
and switch to other things. It's not problem for me cause I understand your
point about how bad I. :)

-- 
Serg Stoyan