Winboard Forum

Hello, I finally got around to trying to make a new Xboard install for OSX users. This time cobble together a full blown app complete with all the necceariy deppendancies to run out of the box.

Xcode is out of the question for me, I simply don't know enough to make it work. Bit of a shame

Following the lead answer's instructions to this posting, it seemed rather simple.

http://stackoverflow.com/questions/1596 ... 74#1600074
Only i came to dynamic linking hell, and it was link after link, a good 70 or so commands i had to enter in...but came to the errors below.

But then I came across this gem
http://macdylibbundler.sourceforge.net/
Which made the whole process a piece of cake!
Also made the whole thing a lot smaller for some reason from 80+mb to only 14 or so

Now all the libraries are properly linked and installed in the bundle
But now i have some configuration issues for a few of the libraries that stop it from displaying properly

Code: Select all

(xboard_osx:68143): Gtk-CRITICAL **: GdkScreen *gtk_window_get_screen(GtkWindow *): assertion 'GTK_IS_WINDOW (window)' failed

(xboard_osx:68143): Gdk-CRITICAL **: gint gdk_screen_get_width(GdkScreen *): assertion 'GDK_IS_SCREEN (screen)' failed

(xboard_osx:68143): Gdk-CRITICAL **: gint gdk_screen_get_height(GdkScreen *): assertion 'GDK_IS_SCREEN (screen)' failed

(xboard_osx:68143): Pango-CRITICAL **: No modules found:
No builtin or dynamically loaded modules were found.
PangoFc will not work correctly.
This probably means there was an error in the creation of:
  '/opt/local/etc/pango/pango.modules'
You should create this file by running:
  pango-querymodules > '/opt/local/etc/pango/pango.modules'

(xboard_osx:68143): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderCoreText', script='latin'

(xboard_osx:68143): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderCoreText', script='common'
No default pieces installed
Select your own -pieceImageDirectory

(xboard_osx:68143): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > /opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.


Any help with this would be greatly appreciated. How does one configure these libraries properly after compilation away from the macports install and into the .app, and still make it be portable in the .app? Most stuff was done with the @executable_path to signify a directory, but i don't think that will help here.

HA! did it! To get rid of the Gdk issue i took a look at gimp which I know uses GTK2 as well, and essentially stole their setup and launching script. As for the irritating Pango issue i found out there was a version of pango on macports that has the module stuff already builtin. "+builtin_module" if anyone is interested.

Still get the GTK critical stuff, but that doesn't seem to be so critical.

So expect an xboard .app sometime soon!

Not an OSX user, but I like your persistence, glad to see your post and know that you are good.

Regards,

Hey thanks mate! Glad to see you are still around too! If only that was the end of my issues. XD Getting the ground work laid out was only half the battle, the next was trying to shoehorn xboard into the new environment. Now all i need to do is figure out a way to get YAY to run via wineskin technology or something. Wouldn't that be nice?

Darklord42 wrote:Hey thanks mate! Glad to see you are still around too! If only that was the end of my issues. XD Getting the ground work laid out was only half the battle, the next was trying to shoehorn xboard into the new environment. Now all i need to do is figure out a way to get YAY to run via wineskin technology or something. Wouldn't that be nice?

I was going to surprise you and create and executable for Mac OS X since this is one of my TARGET OS options within ActiveState Perl Dev Kit/perlApp , but when I tried it said that I need to buy a business license. Can you run a linux executable on Mac OS X? Because I can use linux(x86) or linux(x86_64) as targets for the executable.

Please let me know.

Regards,

Ooh, well linux compiled application I fear wont work. Darwin is a bit of a different animal then Linux, and software needs to be compiled specifically for it. Not that this is usually a problem but given your circumstances... Shame about the Pearl Business licenses.

Have you ever thought about a hackentosh? The OS itself is only 30 bucks..though on the other hand it's actually getting it is the problem as it's only available via apple's Appstore. So you have to own a mac to get at it... I guess you can search Ebay for a Snow Leopard CD if you are ever interested.

Well, I have been trying to change the shortcuts in Xboard.app to change from Ctrl whatever to Meta whatever (or the Command Key as apple people know it) as it would be more normal to an OSX user. (I found the option in the menus.c file) The new shortcut works but the only problem is "type in move" doesn't disable when the meta key is held down like it does with the alt or ctrl key. Anything I can do to disable it?

Of course I will add this stuff to the patch file

[EDIT] I found the relevant passage on gtk/xboard.c line 1690 onward, but not knowing anything about code, I have no idea what to put.
[EDIT2] After studying the passage a bit, I took an educated guess, (which I backed up with a google search for the function) and I turned about to be right!

Code: Select all

{
    char buf[10];

    // ingnore if ctrl, alt, or meta is pressed
    if (eventkey->state & (GDK_CONTROL_MASK | GDK_MOD1_MASK | GDK_META_MASK)) {
        return;
    }

I can code!

Congratulations! Welcome to the club!

This problem is a little complicated, so I will try to give as much detail I can

In my app bundle xboard is launched with a wrapper script called xboard to set the environment for the bundled GTK as being an app package, it can be anywhere on the hard drive. Part of it sets the path with these settings:

Code: Select all

name=$(basename "$0")
echo $name

dirn=$(dirname "$0")
echo $dirn

bundle=$(cd "$dirn/../../" && pwd)
bundle_contents="$bundle"/Contents
bundle_res="$bundle_contents"/Resources
bundle_lib="$bundle_res"/lib
bundle_bin="$bundle_res"/bin
bundle_data="$bundle_res"/share
bundle_etc="$bundle_res"/etc

export PATH="$bundle_bin:$PATH"

export PATH="$bundle_contents/MacOS/:$PATH"


and launches the xboard bin called xboard-bin
$EXEC "$bundle_contents/MacOS/$name-bin" "$@"

And it will still pass any arguments to xboard-bin

One problem is once xboard is launched, it doesn't know of these directories defined above. So for it to know where its resources (textures, pieces,polyglot,fairymax, ect) are, i have
to set a working directory from which i can use relative paths to the various files. so right before the launch command I put

cd "$bundle_bin"
(chosen as that is where polyglot, fairymax timeseal are and saves me some typing)

And this works as a solution

--------
Now I'm trying to incorporate cmail and as far as i can tell it will only launch xboard from path which is fine. My launching shell script is thus:

Code: Select all

#!/bin/sh
echo "Starting Cmail"
export PATH="${0%/*}"/Xboard.app/Contents/MacOS:$PATH
export PATH="${0%/*}"/Xboard.app/Contents/Resources/bin:$PATH
cmail
$SHELL

now the xboard labeled wrapper is in path on that shell and works fine when i type: xboard.

but when cmail opens xboard it does something with the wrapper definitions and piece images and textures relative directories no longer work.
even if I set:
cd ${0%/*}/Xboard.app/Contents/Resources/bin
as the working directory in the shell. It's really weird. Absolute directories for these files in xboard will work fine, but I can't do that with the app situation as people can place the app anywhere. Is there any way I can get xboard to recognize those directory definitions in the wrapper script? Or I have no idea what cmail is doing with it's arguments to mess everything up.

Well, I must admit I am not sure what cmail is supposed to do exactly, and whether it even works on Linux. It seems to have something to do with playing correspondence Chess by e-mail. And I don't think people do that anymore, nowadays. I am not sure if it could work in cooperation with the e-mail system of OSX.

Probably best forget about it. There is no cmail equivalent in the WinBoard install either.

You're probably right, it's very 1993, but it points to a program that does in fact exist on OSX, called
/usr/bin/sendmail. So I was curious to give it a try; I thought a peer to peer method might be useful. Probably get caught in various spam filters anyway

I took a look at the fairly new SCID for mac and noticed that it had quite the setup for correspondence chess supporting the use of the unix mail system (mail mailx, sendmail), thunderbird, and others. So I thought I'd give cmail another go. Turns out the reason for my issues above was that cmail sets to working directory to wherever it needs to write its game logs/files. (normally ~/chess) I'll have to give it a little thought as to what to do regrading this. Anyway, it looks like it does what it's suppose to do, and sends to the Unix mail system. My only problem is my unix mail system uses port 25 by default, which Comcast, my isp, blocks. It's probably not worth the trouble getting it working, much less get others to get it working.

Hi Harm,

We have a solution that is not ideal, and I wonder if there is a better way.

If you recall, gtkmacintegration library automatically appends the application name before the about menu item in the application menu. I asked why this was, and apparently it was to accommodate the gtk stock about menu item that we don't use.

In gtk/xoptions.c, our solution was:

Code: Select all

if(!strcmp(msg, "About XBoard")) msg = "About";

The problem with this is it changes the string and breaks localization. Is there a way to have our cake and eat it too?

As a temporary measure in the current OSX app, I made a local fork of the gtkmacintegration library on my computer and commented out the section that appends the name and comment out our fix. But this isn't ideal.

----------------------------

Completely unrelated note, but since you will see this I might as well mention it. I compiled your master branch and was testing out some of the fixes. I noticed with the new dual board horizontal fix, it doesn't take into account boards with holdings (e.g. bughouse). The viewable space is limited to a square.

Is there no solution for this?

I don't clearly remember what exactly the problem is. Is it that any menu item containing the word "About" will be suffixed by the application name? How does this behave in internationalized versions?

A possible way to do things differently would be to compare msg with the translated _("About XBoard") instead of the untranslated one. Then in non-English versions this comparison would fail, nothing would be done, and a few lines later msg would be replaced by the translated _(msg). Which could be something like "Over XBoard" in a Dutch translation.

But the question of course is how "Over XBoard" would be treated by the Gtkosx library. If the Dutch version of that would append "XBoard" to any item containing or starting with "Over", we would be back to square 1. In that case it would just be a matter of using the translated version of "About" as the replacement string (i.e. write _("About") ), and make sure the translation of a bare "About" would be the word that triggers the appendig of the application name in Gtkosx.

What gtkosx lib does is it tacks on the app name at the end. So we have our string "About Xboard" and then it tacks on Xboard at the end. If gettext translates the string as "Over Xboard" then gtkosx lib would still tack on Xboard at the end so we get Over Xboard Xboard.

[EDIT]
Yeah, it avoids translation altogether by searching for the 0th item in the menu.
https://github.com/jralls/gtk-mac-integ ... rtz.c#L850

If it does not react to the actual text, writing _("About") and providing a translation for that should solve it.

We would have to change our gettext file, and have everyone re translate it. Not to mention, "About" isn't the whole phrase. Some languages might treat it differently in context.

Well, that is how internationalization is supposed to work. I don't think it is common practice, or even recommended, to try saving the translators work by having the application transforming translated strings so that they could be used as translation of other strings. Of course we could try to get the translation of "About" by deleting " XBoard" from the translation of "About XBoard". But what if the translation would be something like "XBoard info", or in a kanji language that uses no spaces, or in a language where reading is right to left, or where perhaps XBoard is spelled differently? We would just be opening a can of worms...

I agree, I just wish there were a way we didn't have to change our current string and stop the library from appending its nonsense. I still don't understand why they feel the need to append the application name to the stock about item, and just let people name the menu string what they like...