Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
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.
Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
Hi, 1. duplication of code for handling menu rearrangement. I think I wrote the original code for this for switching between vertical and horizontal menus, but that' so long ago I don't remember any detail. It sounds like Greg wrote different code to do a similar job at the point when a nib is unarchived. I guess everyone things there should be only one version. I understand it that way too. Everyone things his one is the most important... however we have two different job which share a common problem: - What to do with a NIB file from the mac? It has vertical menus. - How to draw mac-style menus having a GORM file? and, I may add, - independently if we load a NIB or a GORM, how do we display Windows-style menus? among this, we have a problem with rearrangement: We can choose to do a certain kind of conversion when loading a NIB files and greg seems to want to minimize this. On the other hand, we definitively need to do some conversion when displaying horizontal menus with mac style! And even more probably with Windows-style. So I guess the approach no conversion at all is not possible, sorry Gregory. We also see that some of this conversion is the inverse transformation: E.g.: if I load a mac-NIB and then have mac-style menus, I expect to have it look properly, even if it went through two conversions! 2. Now that menus support spacer items, there is debate about how to handle them ... I'm sure the original rearrangment code predates spacers, so it's not surprising if it doesn't do a good job with them. Yes. Personally, I changed my idea to what I discussed with Gregory a while ago: we shouldn't wipe out spacer items, instead we should support them even in GORM files. Why? If we are displaying horizontal menus with a style different than the NeXT style, we could need them. The most extreme scenario: we are writing an application to be used under Windows and we have a perfectly working Windows-theme that emulates menus very well: Separator items are needed then. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
Richard Frith-Macdonald wrote: 3. Some code has some other glitches in it that I don't understand/follow? That was the menu reorganization not working for FlexiSheet that has a German NIB file. Now with the added and corrected localization in gui this is working nicely and remove the last blocking issue from this code. I think we could now switch to my menu reorganization code even in the NIB loading. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
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 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
Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
On 27 Feb 2009, at 09:03, Fred Kiefer 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? Well, I'm really not that familiar with the issue and don't really understand the nature of the disagreement (assuming there is a real disagreement and not just a misunderstanding). The points I'm clear on are ... 1. duplication of code for handling menu rearrangement. I think I wrote the original code for this for switching between vertical and horizontal menus, but that' so long ago I don't remember any detail. It sounds like Greg wrote different code to do a similar job at the point when a nib is unarchived. I guess everyone things there should be only one version. 2. Now that menus support spacer items, there is debate about how to handle them ... I'm sure the original rearrangment code predates spacers, so it's not surprising if it doesn't do a good job with them. 3. Some code has some other glitches in it that I don't understand/ follow? On the issue of spacers ... I think we need to keep the spacer items in the menu so that we retain all the information about them and can therefore switch between horizontal and vertical layouts repeatedly and consistently. However, horizontal and vertical menus should draw them differently of course. A simple option would just be for the drawing code to treat the as if they don't exist when drawing a vertical menu ... ie make them occupy zero space on screen. Visually this would probably be best. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
Hi Greg, this look was what I actually wanted to achive :-) Looks like we don't have a case of not working code, but different goals. We better start out by defining the problem, listing possible solutions and then arguing for or against them. The problem I see is that we have a duplication of menu reorganisation code. Once for switching between horizontal and vertical and another one for loading NIB files. This duplication is bad in itself and will lead to inconsistencies when switching a loaded NIB menu to horizontal (and back again). My solution was to bring the NIB menu as close to the way the menu of normal GNUstep application looks. That is have on the main menu an info item (could also be a sub menu), at the very bottom the quit item and above that the services and hide items, if any. In the info sub menu all the other entries from the application sub menu of the NIB file get collected. The way I implemented that was to look for the Services entry and move everything above that into the info submenu and everything below in the main menu. If you take a look at the main menu of Gorm you will notice almost looks like the one you reject. The only differences are that the converted menu also has some separator items and two additional hide/show entries. You could argue now that the normal menu layout of GNUstep menus is bad. This is a possible point of view, but then we again should try to find a shared view on how to organise menus. Perhaps we can even move the menu reorganisation into a theme? As for the difference to the original code. When I tried to switch of your code the first time without any changes to NSMenu, it ended up with the Services item being the first one and all of the entries that are now gathered in the info submenu being at the end of the main menu. I hope you find my solution better than that. What looks wrong in my implementation is that the menu has the title MainMenu, that needs to be changed. I don't remember that happening to me. Fred Gregory Casamento wrote: I have attached how it looks using the new code (Flexisheet_organizeMenu.jpg). I'm not seeing any difference between that and how it looked before. For reference, with my code, it looks like the attached file Flexisheet_gsnibcode.jpg. Thanks, GC On Tue, Feb 24, 2009 at 5:35 PM, Fred Kiefer fredkie...@gmx.de mailto:fredkie...@gmx.de wrote: Gregory Casamento wrote: Author: gcasa Date: Wed Feb 18 08:38:02 2009 New Revision: 27911 URL: http://svn.gna.org/viewcvs/gnustep?rev=27911view=rev http://svn.gna.org/viewcvs/gnustep?rev=27911view=rev Log: * Source/GSNibLoading.m: Rollback of previous change. Found a minor problem. Modified: libs/gui/trunk/ChangeLog libs/gui/trunk/Source/GSNibLoading.m Greg, could you please explain why you had to undo this change? If there was a problem I am willing to help fixing it. I did not remove this code myself, as I wanted to give you enough time to check, whether my replacement was working. I really would like to the see this code here go away. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
Fred, I have attached how it looks using the new code (Flexisheet_organizeMenu.jpg). I'm not seeing any difference between that and how it looked before. For reference, with my code, it looks like the attached file Flexisheet_gsnibcode.jpg. Thanks, GC On Tue, Feb 24, 2009 at 5:35 PM, Fred Kiefer fredkie...@gmx.de wrote: Gregory Casamento wrote: Author: gcasa Date: Wed Feb 18 08:38:02 2009 New Revision: 27911 URL: http://svn.gna.org/viewcvs/gnustep?rev=27911view=rev Log: * Source/GSNibLoading.m: Rollback of previous change. Found a minor problem. Modified: libs/gui/trunk/ChangeLog libs/gui/trunk/Source/GSNibLoading.m Greg, could you please explain why you had to undo this change? If there was a problem I am willing to help fixing it. I did not remove this code myself, as I wanted to give you enough time to check, whether my replacement was working. I really would like to the see this code here go away. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) attachment: Flexisheet_organizeMenu.jpgattachment: Flexisheet_gsnibcode.jpg___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
Gregory Casamento wrote: Author: gcasa Date: Wed Feb 18 08:38:02 2009 New Revision: 27911 URL: http://svn.gna.org/viewcvs/gnustep?rev=27911view=rev Log: * Source/GSNibLoading.m: Rollback of previous change. Found a minor problem. Modified: libs/gui/trunk/ChangeLog libs/gui/trunk/Source/GSNibLoading.m Greg, could you please explain why you had to undo this change? If there was a problem I am willing to help fixing it. I did not remove this code myself, as I wanted to give you enough time to check, whether my replacement was working. I really would like to the see this code here go away. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
Hey Fred, When I removed my code, the menu started rendering as it had before (i.e. messy with all but a few items in the top level). As you can see, the date was the 18th, so it was just before SCALE, I figured it would be better to roll back the change until I could take a better look at it. I will do that today and tomorrow as I would like to see this code go away too. GC On Tue, Feb 24, 2009 at 5:35 PM, Fred Kiefer fredkie...@gmx.de wrote: Gregory Casamento wrote: Author: gcasa Date: Wed Feb 18 08:38:02 2009 New Revision: 27911 URL: http://svn.gna.org/viewcvs/gnustep?rev=27911view=rev Log: * Source/GSNibLoading.m: Rollback of previous change. Found a minor problem. Modified: libs/gui/trunk/ChangeLog libs/gui/trunk/Source/GSNibLoading.m Greg, could you please explain why you had to undo this change? If there was a problem I am willing to help fixing it. I did not remove this code myself, as I wanted to give you enough time to check, whether my replacement was working. I really would like to the see this code here go away. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev -- 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
