Re: NSMenu* and NSPopuUp* issues

[Serg Stoyan]

Hello David,

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

  No. It is not ignored. Just some delay in implementing.

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

  Why? Again, I don't against inclusion this code into GNUstep. I just want
  to hear any reason why we did so. Beacuse people want this? Ok. Is it
  official position of GNUstep developers to include any code that people
  want? Ok, I'll bring this back.

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

  Ok, I'll include code related to horizontal menu into GNUstep until
  bundle (and theme support as general) is not implemented.

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

  Since GNUstep is free OpenStep implementation, this is not feature
  removal, but that's not problem.

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

  Agree.

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

  Ok, I see.

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

  Agree. And I was wrong.

-- 
Serg Stoyan