OK, I see. But when you start to mess with GTK's internals, like the
place where it stores its data, I guess there would be no alternative to
recompiling it yourself with the necessary changes.
What exactly are the problem area's? Is it just the texts on OK and
Cancel button? I think we can live with that. And there is only a single
place in the entire code where they are generated, btw, which is
GenericPopUp() in xoptions.c. Rather than asking for a "stock OK"
button, we might be able to change the code there to ask for a custom
button with our own text "OK" on it, which we would subject to
translation through the XBoard .mo files.
In fact the stock OK & Cancel supplied by GTK are a pain anyway, as they
cannot be made to appear on the same row as any custom dialog buttons
now, like was possible with Xaw, and many dialogs do have enough space
for that, and now take extra valuable height. (I cannot even test the
Match dialog on my virtual machine, because the OK button is always out
of view...)
Don't want to do that for 4.8.0, though.
H.G.
Joshua Pettus schreef op 10/6/2014 10:03 PM:
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
