Thanks H.G.
I understand, completely, no worries. The bundle ideally contains all libraries and resources to run the app. It’s like a self-contained microcosm. Kinda defeats the purpose of the dylib. But there you have it. For the record, the app is about 25mb. :) But that’s tiny compared to some apps. SCID for Mac is 90mb 40 of which are libraries. GTK and it’s resources are included in the bundle. So all someone has to do is click on it, and it will run. Otherwise they would have to install GTK themselves, and I can vouch what a pain that is.
Best Regards, Josh
I know very little about NLS, and I hadn't time to study your
e-mails about it due to non-computer-related business soaking up
most of my time.
But it seems to me that GTK internationalization (for things like OK
and Cancel buttons) should not be in the bundle, but be part of the
GTK library. Or is that library part of the App?
H.G.
Joshua Pettus schreef op 10/6/2014 9:17
PM:
Darn, one more hurdle…turns out xboard isn’t the only thing that
uses gettext, but GTK itself to translate the buttons and various
menu items. For the life of me, I can’t figure out how to get
GTK2 to stop looking on my system’s locale folder and into the app
bundle’s for it’s gtk20.mo files. Does anyone know how this is
handled? Is it gtk or one of its supporting programs that handles
the button text? I don’t have to fork gtk2 do I?… I haven’t
figured out how other apps do it yet, there must be a way.
Thanks,
Josh
Ha! After studying a lot of code found on
the internet, remembering what HGM taught me,
learning a little more how things work, plus
some very lucky guess work of my own, I found
a working solution to my problem!
In gtk/xboard.c:
#ifdef ENABLE_NLS
//
if (appData.debugMode) {
//
fprintf(debugFP, "locale = %s\n",
setlocale(LC_ALL, NULL));
//
}
+ #ifdef __APPLE__
+ char
*res_path;
+ res_path =
gtkosx_application_get_resource_path ();
+ #undef LOCALEDIR
+ #define LOCALEDIR g_strconcat
(res_path, "/share/locale",
NULL ) //
redefine localedir for OSX bundle
+ #endif
bindtextdomain(PACKAGE, LOCALEDIR);
bind_textdomain_codeset(PACKAGE, "UTF-8"); // needed when
creating markup for the clocks
textdomain(PACKAGE);
#endif
Not bad for someone who doesn’t know
coding. :-)
HGM, I’m sure you have a better solution
with the systems in place, whenever you get
around to it for 4.8.1.
Regards,
Josh Pettus
Hmm, Well I clearly don’t have a
clue as to what I’m doing
I added these lines to xboard.c
main() (mimicking what HGM did for
SVGDIR) I know they would have to be
put in ifdef ENABLE_NLS but I just want
it working.
#ifdef __APPLE__
{
// prepare to catch OX
OpenFile signal, which will tell us
the clicked file
char
*path =
gtkosx_application_get_bundle_path();
theApp
=
g_object_new(GTKOSX_TYPE_APPLICATION,
NULL);
strncpy(dataDir,
path, MSG_SIZ);
snprintf(masterSettings,
MSG_SIZ, "%s/Contents/Resources/etc/xboard.conf",
path);
snprintf(svgDir,
MSG_SIZ, "%s/Contents/Resources/share/xboard/themes/default", path);
+ char
localeDir[MSG_SIZ] = LOCALEDIR;
+ snprintf(localeDir, MSG_SIZ, "%s/Contents/Resources/share/locale",
path);
suppress
= (argc == 1 || argc > 1 && argv[1][00] != '-'); // OSX sends
signal even if name was already
argv[1]!
g_signal_connect(theApp,
"NSApplicationOpenFile",
G_CALLBACK(StartNewXBoard), NULL);
//
we must call application ready before
we can get the signal,
//
and supply a (dummy) menu bar before
that, to avoid problems with dual
apples in it
gtkosx_application_set_menu_bar(theApp,
GTK_MENU_SHELL(gtk_menu_bar_new()));
gtkosx_application_ready(theApp);
if(argc == 1) { //
called without args: OSX open-file
signal might follow
static
char
*fakeArgv[3]
= {NULL,
clickedFile, NULL};
usleep(10000);
// wait 10
msec (and hope this is long enough).
while(gtk_events_pending())
gtk_main_iteration();
// process all events that
came in upto now
suppress = 0; //
future open-file signals should start
new instance
if(clickedFile[0]) { // we
were sent an open-file signal with
filename!
fakeArgv[0] = argv[0];
argc = 2; argv = fakeArgv; //
fake that we were called as "xboard
filename"
}
}
}
#endif
knowing that below there is
bindtextdomain(PACKAGE, LOCALEDIR);
and to xboard.h
+ extern
char
localeDir[];
It compiles but it doesn’t find the
locale folder like I hoped…
Any ideas, or is what I’m doing
complete gibberish?
-Josh
I see, it’s a
form of Cantonese. I could attempt to
make a folder for that. Can’t tell
you how useable that would be. :)
Google Translate doesn’t have it. I
found this site though:
http://www.cantonese.sheik.co.uk/scripts/wordsearch.php?level=0
On Oct 4, 2014, at 9:39 PM, Tim Mann
<address@hidden>
wrote:
For what it's
worth, a little googling tells me
that zh_HK is Hong Kong Chinese.
On Sat, Oct 4, 2014 at 12:27 PM,
Joshua Pettus <address@hidden>
wrote:
Even if we
cant get the code in for 4.8, I
kinda would still like to have
localization in the app bundle for
the release, if that’s ok.
Josh
On Oct 3, 2014, at 1:55 AM, Joshua
Pettus <address@hidden>
wrote:
Hi Harm,
I wanted to let you know that I
can have gettext working in the
mac app. Turns out, all we
needed was to compile xboard
with NLS and we were good.
Xboard of course checks the
LOCALEDIR which is originally
set to /usr/local/share/locale
in the makefile. I was hoping
we could hardcode it for the
Xboard.app to be
DataDir/Contents/Resources/share/locale
in a way similar to what we did
with SVGDIR.
There was an extra hurdle
regarding the gtkmacintegration
library with the Application
(Xboard) menu, which requires to
be localized separately by OSX.
Namely a bunch of
language.lproj folders with
Gtkosxapplication.strings files
in the app’s resource folder
with each string for the menu
items. On the
gtk-osx-users-list email list we
managed to squash a library bug
stoping this from working for us
properly. I also updated those
.string files that came with the
library accordingly, so we now
have a matching language folder
for every language we have with
gettext. Except for zh_HK, which
I have no idea what that is.
There is one more problem
though. “About Xboard” was
moved from the help menu to the
Xboard menu. John Ralls said
that moved menu items need to be
handled by gettext, but for some
reason this is never translated
by gettext. Anything we can do
to restore this?
Thanks!
Josh Pettus
|