gnustep-dev
[Top][All Lists]
Advanced

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

Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoa


From: Fred Kiefer
Subject: Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
Date: Mon, 02 Mar 2009 13:41:40 +0100
User-agent: Thunderbird 2.0.0.19 (X11/20081227)

Sorry Greg, it really is a bit hard to follow you. Does this mean that
your argument that my code would duplicate menu items is void, as this
was just a general statement about GNUstep not handling alternate menu
items? And your second argument that you don't want to see these
separator items is again a rather general statement, not that much
related to the specific way of doing the menu reorganisation.

This just leaves the new argument, that you don't like menu
reorganisation as we never know why the developer organised it that way
in the first place. So yes, in the future there could be some menus that
any form or automatic menu reorganisation handles less than optimal. But
could we discuss that, when we run into real problems?
If you don't come up with something better, I will go ahead and make
these changes.

Fred

Gregory Casamento wrote:
> Your code isn't duplicating the item.  It's including items which are
> alternates which are (by definition) duplications of the items they
> serve as alternates for. :)  
> 
> What I was saying is that I believe that we need to implement handling
> for alternate menu items. :)
> 
> I am aware that my code duplicates the quit item.  I had meant to change
> it to delete the one under Info so, in effect, it would move it.
> 
> In general, I don't like the idea of doing a lot of manipulation on the
> menu because we have to guess what the developer was trying to achieve.
> 
> GC
> 
> On Fri, Feb 27, 2009 at 4:03 AM, Fred Kiefer <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     Now you left me puzzled. Which menu items get duplicated by my
>     reorganisation code? I tried to reproduce this with FlexiSheet and Bean
>     and I am very sure that each item only appears once.
>     In FlexiSheet I see an issue with the missing German language string for
>     "Services" as there we have a German menu NIB, but otherwise everything
>     is as expected.
>     On the contrary your code is duplicating the quit menu item, but that
>     isn't that bad, is it?
> 
>     I am not sure about the separator items. I fully agree that they don't
>     look great in our current drawing style. But the idea of structuring
>     even a vertical a menu seems correct to me. We could try to replace the
>     separator item drawing with something that just displays a vertical or
>     horizontal line, this will make the menu item size computation a bid
>     harder, but surely looks a lot better.
> 
>     Now we have two differing opinions. How to proceed from here? Are there
>     any other points of view out there?
> 
>     Gregory Casamento wrote:
>     > Differing philosophies is, I believe, the case.   The reason I
>     made the
>     > change I did is because I felt it was important to do as little
>     > transformation on the menu as possible since it would be easier to
>     > predict where the items would end up.  My code merely changes the
>     > title,  changes the name of one of the menus to Info (the first menu)
>     > and adds "quit" item.
>     >
>     > I think I would feel better about the transformations you're doing in
>     > your solution if it didn't duplicate the items and didn't include
>     > separators in the main menu.     I guess one thing we could do, in
>     > general, is get rid of separator items altogether when displaying
>     > vertically.   I think putting menu transformation into a theme is
>     > definitely a good idea.   Different themes may have different ways of
>     > organizing the menus.
>     >
>     > On an unrelated note, the solution to the duplicate items may be
>     because
>     > of alternate menu items.   We should look into implementing that
>     > sometime soon.





reply via email to

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