bugGNUstep - Bugs: bug #36764, GUI does not currently support...

Group
 
 

bug #36764: GUI does not currently support loading with standard localized directories...

Submitter:  Gregory John Casamento <gcasa>
Submitted:  Sun 01 Jul 2012 10:46:25 PM UTC
   
 
Category:  Gui/AppKit Severity:  3 - Normal
Item Group:  Change Request Status:  Fixed
Privacy:  Public Assigned to:  FredKiefer
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 01 Dec 2013 12:31:35 PM UTC, comment #12: 

I finally got around to rewrite the gui NIB loading to use the base mechanism. That way we should resolve the issue of the wrong laoding order. It should also help to support the new language names already provided by base.

Fred Kiefer <FredKiefer>
Group Member
Wed 17 Oct 2012 09:29:22 PM UTC, comment #11: 

I don't think that we should remove that method, it gets used in the class NSNib as well. Rather we should replace it with an implementation that calls the base NSBundle method with the different NIB/Gorm/XIB extensions to request a NIB resource to load.

After that is sorted out and working we could think about moving on to the newer Apple NIB loading interface, but we would still have to support the old methods.

Fred Kiefer <FredKiefer>
Group Member
Tue 16 Oct 2012 04:51:57 AM UTC, comment #10: 

Any further thoughtson this?
Should we remove -pathForNibResource:?

Richard Frith-Macdonald <CaS>
Group Member
Mon 30 Jul 2012 07:31:06 AM UTC, comment #9: 

I couldn't figure out how to easily write a testcase for this, so what I did to try it out on OSX was:

1. create a new empty app with a single window in the main nib, setting it's title to 'Generic'.
2. copy the MainMenu.nib out of Test.app/Contents/Resources/en.lproj
3. edit the window menu to be 'English' and re-build the app
4. run the app and check that the window title of the running app was 'English'
5. copy the saved MainMenu.nib to Test.app/Contents/Resources
6. run the app and check the enu title ... 'Generic'
7. removed the copied nib
8. run the app and check the title ... 'English'

So on OSX, the order of lookup for the main nib is generic first, then language specific ... it looks like current lookup order in gnustep-gui is wrong, and we should probably change the gui bundle additions code to use the lookup methods from base and get rid of the -pathForNibResource: method.

Richard Frith-Macdonald <CaS>
Group Member
Sun 29 Jul 2012 06:38:35 AM UTC, comment #8: 

I did look at the appkit bundle additions documentation on friday (and I just skimmed through it again) ... I can't actually see anything there which says that these methods lookup resources in the order that gnustep-gui currently does.
I guess we need to create a testcase for resource lookup order usng those methods.

Richard Frith-Macdonald <CaS>
Group Member
Sat 28 Jul 2012 10:54:01 PM UTC, comment #7: 

As always, this could well be, but what we try is to be compatible to the documation Next and Apple published on these methods.
Please have a look at: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSBundle_AppKitAdditions

Now that Apple published 10.8 (Mountain Lion), most of these methods are deprecated anyway. No idea what replaces them.

Fred Kiefer <FredKiefer>
Group Member
Fri 27 Jul 2012 06:33:54 PM UTC, comment #6: 

Could it be that the GUI behavior is wrong (not OSX compatible)?
Do we actually have testcases which show that localised resources in the GUI should be loaded in preference to unlocalised resources?
The OSX bundle documentation says that a bundle should not contain both localised and unlocalised resources, so in theory the same resource file should be retrieved irrespective of the order in which paths are searched.

Richard Frith-Macdonald <CaS>
Group Member
Sat 21 Jul 2012 01:02:31 PM UTC, comment #5: 

I checked again in the base implemenation and this still returns the non-localized paths in preference of the localized ones. And this is even required by the specification from Apple.
This means we still need a specific implementation in gui, but this could be simplified a lot and would in that process support the new localisation names.

I think what we need to do is add a method to GSModelLoaderFactory to get the different extensions (.gorm, .nib and .xib) for NIB files in priority order. Then in pathForNibResource: we would loop over these extensions and for each call [NSBundle pathsForResourcesOfType:inDirectory:] with a nil subPath. Next we loop over the result path and check whether they are for the right file name, but skip over the the non-localized ones. Or rather set a local variable to each matching path, but only break out of the loop for localized paths. When we find a matching path we break out of the file extension loop as well.

Not the most efficient way to implement this, but at the moment I don't see a better method using the base mechanism.

Fred Kiefer <FredKiefer>
Group Member
Tue 10 Jul 2012 10:12:01 PM UTC, comment #4: 

In gui we have our own implementation of resource loading in NSBundleAdditions.m. As I understand it this was done because gui uses the localized paths first, where as base used to have the non-localized oath first. This difference seems to be gone now, if this is true, we should just call the base implementation from gui.

Fred Kiefer <FredKiefer>
Group Member
Mon 09 Jul 2012 06:01:36 PM UTC, comment #3: 

How does this differ from bug £34815 exactly?  What extra needs doing?

Richard Frith-Macdonald <CaS>
Group Member
Tue 03 Jul 2012 07:26:30 PM UTC, comment #2: 

Thanks for all of the input.  I'll follow it when making the changes.  Naturally the existing scheme will be maintained to keep compatibility.

GC

Gregory John Casamento <gcasa>
Group administrator
Mon 02 Jul 2012 08:43:21 PM UTC, comment #1: 

Actually the loading of resources is mostly implemented in base. There we decide which paths to inspect. Gui has a copy of that code with a different orde in pathForNibResource: in NSBundleAdditions.m. (This always makes me wonder where the base order would ever be the more usefull one?)

Whatever you want to change here, should be done in NSBundle.m first.

And please don't remove the old naming schema, it is fine to add the language codes, but removing the full names would break existing applications.

To me it looks like it would be sufficient to add a few more loops for language specific directories in  _bundleResourcePathsWithRootPath:subPath:localization: or addBundlePath().

You just need to figure out a nice way to generate these directory names for a language. Maybe a reverse of the function GSLanguageFromLocale() in GSLocale.m?
BTW the code there looks wrong as it is always using the first two characters of the language code, we rather should check for the underscore.

Fred Kiefer <FredKiefer>
Group Member
Sun 01 Jul 2012 10:46:25 PM UTC, original submission:  

Currently, gnustep-gui uses ONLY the full language names the language names for localization.  

Cocoa currently supports both using the language names and the standard language abbreviations as defined by ISO-3166-Alpha2 - http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2.

I believe that it would be best for GUI to use the language codes defined by the standard mentioned above just as Cocoa does.

Gregory John Casamento <gcasa>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by gcasa (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-01-23 FredKiefer StatusReady For Test Fixed
        Open/ClosedIn Test Closed
    2013-12-01 FredKiefer StatusNone Ready For Test
        Assigned toNone FredKiefer
        Open/ClosedOpen In Test
    2012-10-16 CaS CategoryBase/Foundation Gui/AppKit
    2012-07-02 FredKiefer CategoryGui/AppKit Base/Foundation

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code