[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSMenu* and NSPopuUp* issues
From: |
David Ayers |
Subject: |
Re: NSMenu* and NSPopuUp* issues |
Date: |
Tue, 08 Apr 2003 12:24:08 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 |
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.
- Re: NSMenu* and NSPopuUp* issues, Jeff Teunissen, 2003/04/01
- Re: NSMenu* and NSPopuUp* issues, Philippe C.D. Robert, 2003/04/02
- Re: NSMenu* and NSPopuUp* issues, Fred Kiefer, 2003/04/07
- Re: NSMenu* and NSPopuUp* issues, Serg Stoyan, 2003/04/08
- Re: NSMenu* and NSPopuUp* issues,
David Ayers <=
- Re: NSMenu* and NSPopuUp* issues, Richard Frith-Macdonald, 2003/04/08
- Re: NSMenu* and NSPopuUp* issues, Willem Rein Oudshoorn, 2003/04/08
- Contributing code issues (was: Re: NSMenu* and NSPopuUp* issues), Michael Hanni, 2003/04/08
- Re: NSMenu* and NSPopuUp* issues, Serg Stoyan, 2003/04/09
- Re: NSMenu* and NSPopuUp* issues, Richard Frith-Macdonald, 2003/04/09
- Re: NSMenu* and NSPopuUp* issues, Serg Stoyan, 2003/04/09
- Re: NSMenu* and NSPopuUp* issues, Richard Frith-Macdonald, 2003/04/09
- Re: NSMenu* and NSPopuUp* issues, Serg Stoyan, 2003/04/09
- Re: NSMenu* and NSPopuUp* issues, Serg Stoyan, 2003/04/08
- Re: NSMenu* and NSPopuUp* issues, David Ayers, 2003/04/08