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 <fredkie...@gmx.de> 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 <fredkie...@gmx.de > > <mailto:fredkie...@gmx.de>> 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)
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
