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

[Gregory John Casamento]

URL:
<http://savannah.gnu.org/bugs/?36764>

Summary: GUI does not currently support loading with standard
localized directories...
Project: GNUstep
Submitted by: gcasa
Submitted on: Sun 01 Jul 2012 06:46:25 PM EDT
Category: Gui/AppKit
Severity: 3 - Normal
Item Group: Change Request
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

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.





_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Fred Kiefer]

Update of bug #36764 (project gnustep):

Category: Gui/AppKit => Base/Foundation

_______________________________________________________

Follow-up 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.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Nachricht gesendet von/durch Savannah
http://savannah.gnu.org/

[Gregory John Casamento]

Follow-up Comment #2, bug #36764 (project gnustep):

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

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Richard Frith-Macdonald]

Follow-up Comment #3, bug #36764 (project gnustep):

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

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Fred Kiefer]

Follow-up Comment #4, bug #36764 (project gnustep):

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.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Nachricht gesendet von/durch Savannah
http://savannah.gnu.org/

[Fred Kiefer]

Follow-up Comment #5, bug #36764 (project gnustep):

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.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Nachricht gesendet von/durch Savannah
http://savannah.gnu.org/

[Gregory Casamento]

Fred,

Just a bit about the model loading process...

Currently there is something like this implemented already. When I
designed the model loading system I made it so that you could add
model loading classes via frameworks or libraries (e.g. Renaissance...
although this never happened). There is a class method called
"+priority" which defines the priority that each model type should be
considered in.

Later, GC

Post by Fred Kiefer
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.
_______________________________________________________
<http://savannah.gnu.org/bugs/?36764>
_______________________________________________
Nachricht gesendet von/durch Savannah
http://savannah.gnu.org/

[Richard Frith-Macdonald]

Follow-up Comment #6, bug #36764 (project gnustep):

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.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Fred Kiefer]

Follow-up Comment #7, bug #36764 (project gnustep):

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.


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Nachricht gesendet von/durch Savannah
http://savannah.gnu.org/

[Richard Frith-Macdonald]

Follow-up Comment #8, bug #36764 (project gnustep):

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.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Richard Frith-Macdonald]

Follow-up Comment #9, bug #36764 (project gnustep):

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.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Richard Frith-Macdonald]

Update of bug #36764 (project gnustep):

Category: Base/Foundation => Gui/AppKit

_______________________________________________________

Follow-up Comment #10:

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

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[Fred Kiefer]

Follow-up Comment #11, bug #36764 (project gnustep):

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.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Nachricht gesendet von/durch Savannah
http://savannah.gnu.org/

[Fred Kiefer]

Update of bug #36764 (project gnustep):

Status: None => Ready For Test
Assigned to: None => FredKiefer
Open/Closed: Open => In Test

_______________________________________________________

Follow-up 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.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Nachricht gesendet von/durch Savannah
http://savannah.gnu.org/

[Fred Kiefer]

Update of bug #36764 (project gnustep):

Status: Ready For Test => Fixed
Open/Closed: In Test => Closed


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36764>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/