Re: NSMenu* and NSPopuUp* issues

[David Ayers]

Hi Serg,

I'm sorry, I didn't gt into this earlier, but I was trying to keep out 
of gui related topics for now.  Bad move, maybe.

Serg Stoyan wrote:

> 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".
Does this mean they should be ignored?

> >  > 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.
What kind of proof did you expect?  I think that a integration with the 
native desktop envirmenmt is important. Maybe it shouldn't be first 
proiority, and maybe not in the -gui library itself (I just don't know 
which approach is best).  But I do think horizontal menues should be 
part of GNUstep.

> > 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?
Maybe this theme bundle should have been added in the same commit that 
removed code from the -gui library?

> > 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.
Ease of maintance should not generally lead to feature removal, but to 
improved code organization.  (Sometimes it may lead to feature removal, 
but I believe the thread did justify that this particular feature should 
remain.)

> > 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.
>  
Given the number of times that you argued, that theme bundles would 
solve any objections people had, one could get the idea, that you 
implied supplying one.  But I guess you never did say it.

> > 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.
Maybe because people were expecting the theme bundle you proposed?

> > 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?
The problem with NSCoding and backward compatibility is that you won't 
notice until it is too late.  If anyone developing with current 
gnustep-cvs saves a nib file now, that nib file will not be able to be 
used by other people using the latest -gui release.  I think changes in 
encoding/decoding of core classes should always be prominantly posted, 
so that anyone developing apps using archives can be aware of it.  And I 
also believe that archives should always be kept backward compatible to 
at least the latest official release.

I haven't looked into how it is broke, but please fix it, and then ask 
all app maintainers to update thier nibs which they have saved since it 
was broken, before they announce an official release, if they use 
gnustep cvs.

> 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. 
I don't see how you can refer to horizontal menues as 'some "bloatware" 
that came to mind'.  It was an awkward extension, but it did come from 
our reference implementation.  Yes, it got removed because our reference 
implementation didn't care about different desktop environments 
anymore.  Yes, may be the OpenStep spec should have not been so 
inflexible on menu implementation.  But in I think it is a viable issue 
for usability.  I have no objections to focusing on keeping GNUstep 
consistent with itself across plattforms, and to allow theme bundles to 
add consistency with the deployment desktop environement.  But instead 
of removing this feature that was subject to a major discussion, it 
should be replaces with a technical superior alternative.  You have 
suggested the approach yourself, but consider following through with 
it.  I'm sure Fred would be willing to help.  (If not, and no one else 
volunteers, then I'll jump in.)

Cheers,
Dave

PS: Don't get me wrong, I also appreciate the cleanup!.  But please make 
it a matter of code organization rather than feature removal in this 
case.  I have similar issues when trying to accomadate GDL2 patches by 
users wishing to integrate usage of (currently) undocumented classes of 
Cocoa that partially don't exist in base.  It's not always easy, but 
it's important to try.