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
Localization of GNUstep strings
I just updated the GNUstep gui localization files for English and German. While doing so I noticed a few issues with our current localization handling. One was in base, where the switch to output missing localization values would always write out nil, not very helpful while looking for the missing keys. The other problem was harder. In gui we override the _() and NSLocalizedString macros to use the gui bundle to resolve the localization. This is needed and great, but needs the include of GSGuiPrivate.h in the gui source file to work and this was missing for a lot of your files where localization had only been added recently. We also have a process issue here. All the localization files were last updated 2006 and for many important languages we don't even have localizations. It would be great, if all the non-English native speakers could adopt there own language and create translations for it. Creating and updating these files is really easy. All I had to do was: cd gui/Resources make_strings -L German ../Source/*.m Before every release of gui we should update these files and add the missing new translations. Fred PS: I find the way you have to write the non-ASCII characters a bit clumsy, but I didn't want to switch to UTF-8. ___ 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: Localization of GNUstep strings
Selon Fred Kiefer fredkie...@gmx.de: [snip] cd gui/Resources make_strings -L German ../Source/*.m Before every release of gui we should update these files and add the missing new translations. Fred PS: I find the way you have to write the non-ASCII characters a bit clumsy, but I didn't want to switch to UTF-8. Clumsy looks like an understatment :o) Seriously though, is utf-8 an option ? I'm willing to start a french translation and I would prefer something easier for all accentuated caracters. Philippe ___ 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: Localization of GNUstep strings
Selon p.o.rous...@free.fr: Selon Fred Kiefer fredkie...@gmx.de: [snip] cd gui/Resources make_strings -L German ../Source/*.m Before every release of gui we should update these files and add the missing new translations. Fred PS: I find the way you have to write the non-ASCII characters a bit clumsy, but I didn't want to switch to UTF-8. Clumsy looks like an understatment :o) Seriously though, is utf-8 an option ? I'm willing to start a french translation and I would prefer something easier for all accentuated caracters. Here's my first take on a French.lproj. Answering to myself, yes utf-8 is an option and that's what I used. You just have to had the 3 bytes marker at the beginning of the file (and that's ugly imho). Gorm panels of gnustep-gui (and maybe something else) need to be translated too I guess. Can you give me a hint on how to do that ? Philippe Localizable.strings Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
