Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m

[Gregory Casamento]

Fred,

The alternate menu issue is not "void", but it's not really relevant to
the reorganization discussion and, perhaps, we should talk about it
separately.  What I was trying to say is that we should handle
alternate menu items to prevent them from appearing in the menu since,
to the user, they appear as duplications.  So, yes, it was just a general statement about not handling alternate items.

These are just my thoughts on the whole thing, I'm not shooting either solution down....

To me the problem with the way it looks with _organizeMenu is this:

1) It looks a lot different than what the developer might specify in Gorm/IB.   If a user creates a nib using Gorm/IB, it will be transformed in ways that aren't readily apparent.  I guess the solution here is documentation.  
2) Spacers at the top level don't really fit..  this is more of an aesthetic comment than anything else.   .

Those are the only real problems I currently see with using _organizeMenu as it stands.

What I like about my approach is that it changes the menu as little as possible.   There are only three things that happen:

1) Changing the title of the menu to the name of the app...
2) Changing the menu item which has the app's name to "Info" and
3) Adding a "Quit" item to the end of the root menu.

Ultimately, though, what Riccardo says is true.  There is no "perfect" solution to this since, in either case, we're transforming the menu... the difference is only a matter of degree.

I think the best compromise I can see is, when the menu is displayed vertically, to not show the separator items in the main/top level menu.   They make the menu look messy to me.  Maybe if they were rendered differently that might help.

Just as a note... I thought I saw someone mention putting menu transformation into a method in GSTheme.   I liked that idea.. again... separate from this discussion.

Later, GC

On Mon, Mar 2, 2009 at 7:41 AM, Fred Kiefer <address@hidden> wrote:

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.

-- 
Gregory Casamento
Open Logic Corporation, Principal Consultant
## GNUstep Chief Maintainer
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell), (301)362-9640 (Home)