Distributing engines for Mac/OSX

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
Evert
Posts: 2923
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: Distributing engines for Mac/OSX

Post by Evert » Fri Mar 18, 2016 9:53 pm

hgm wrote:
JoshPettus wrote:Well bundles that behave like executables is what Xboard.app is. But apple treats these different then console executables. Specifically, it doesn't open it up with a console. So that's probably not what you want.
I don't want a console. I just want it to move itself to the place where we think it belongs (as opposed to where the user put it).
Personally, I would not appreciate programs moving themselves away from where I put them.
What is still missing in my understanding is how such a bundle looks from the command-line interface (or file-system API). If the bundle root folder would be /Applications/XXX, can other programs then simply access files within it through a pathname like /Applications/XXX/bin/xxx.exe? Or is everything inside the bundel shielded when you look at the outside, like it would be if XXX was a zip file?
You can browse files in the bundle. From the command-line this is easy (the bundle is just directory, after all), from the Finder you first need to right-click and choose "show contents", but it can still be done easily.

From the Finder (or the Dock) you can only start programs that are wrapped in a bundle. From the command line, you can start the binaries that lives in the bundle directly, but you cannot invoke the bundle (there's a difference in the run-time environment for programs that are started directly versus those that are started by opening the App bundle, but don't ask me about the details), you need to use the "open" command to launch the bundle through the Finder.

JoshPettus
Posts: 730
Joined: Fri Oct 19, 2012 12:23 am

Re: Distributing engines for Mac/OSX

Post by JoshPettus » Fri Mar 18, 2016 10:00 pm

hgm wrote: I don't want a console. I just want it to move itself to the place where we think it belongs (as opposed to where the user put it).
Only way to do that is with a package installer like the winboard installer for OSX. In which case if installation is going to be automated, we can install anything anywhere. The user doesn't have to access it. We might as well install linux plugins in the expected linux location.
I am not sure what exactly you mean by "point XBoard to the app bundle's folder". You add it to XBoard's engine list? Or you move a launch script for the GPS App to a place where XBoard was already configured to expect it?
I mean add it to Xboard's engine list. There is no launch script (most apps don't have one, that's just for GTK)
This does sound pretty much like what I want. Except that I would not want the pointer to it within the XBoard App, but in a generally accessible place outside it. So that all GUIs are pointed to it.
Apps don't behave that way, they don't share resources. They are self-contained bundles with all resources the executable needs included. This includes engines and even libraries. (defeats the purpose of the dynamic library, I know, but there you have it) Portability was deemed more important.

What you propose is utterly unique

I can think of apps competing to use types of documents. (eg a wav file) in which case you have to choose the default app, but that's different. We might as well stick with the linux locations. It's about as good as any other (since it's automated), instead of installation scripts we use installation package manager to install precompiled binaries.

But as I said, No other GUI on OSX will use it. The truth is there aren't many. You might as well do whatever the heck you want. So lets use the linux system.
What is still missing in my understanding is how such a bundle looks from the command-line interface (or file-system API). If the bundle root folder would be /Applications/XXX, can other programs then simply access files within it through a pathname like /Applications/XXX/bin/xxx.exe? Or is everything inside the bundel shielded when you look at the outside, like it would be if XXX was a zip file?
From the command-line, bundles are just directories . To get at the executable for xboard in console I could type:

/Applications/Xboard.app/Contents/MacOS/xboard

of course I would normally just do

open -a XBoard.app
Last edited by JoshPettus on Fri Mar 18, 2016 10:05 pm, edited 1 time in total.

User avatar
hgm
Posts: 23364
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Distributing engines for Mac/OSX

Post by hgm » Fri Mar 18, 2016 10:04 pm

Evert wrote:Personally, I would not appreciate programs moving themselves away from where I put them.
Well, that happens to be what installers do. Move things from where you put them to where they belong.

If you don't want that, you should just not run the installer. And that is the beuty of it, you don't need to. Just don't double-click the bundle. You can just enter the path name to the engine executable in your GUI like you could have done for any unzipped engine archive. People that don't know how to do that have the options to double-click the bundle, and will find the engine in their GUI's engine-selection box forever after.
You can browse files in the bundle. From the command-line this is easy (the bundle is just directory, after all), from the Finder you first need to right-click and choose "show contents", but it can still be done easily.
What about the file-selector dialog? Does that allow you to browse inside the bundle, or would it also shield the inside, like the Finder?

JoshPettus
Posts: 730
Joined: Fri Oct 19, 2012 12:23 am

Re: Distributing engines for Mac/OSX

Post by JoshPettus » Fri Mar 18, 2016 10:23 pm

hgm wrote:
Evert wrote:Personally, I would not appreciate programs moving themselves away from where I put them.
Well, that happens to be what installers do. Move things from where you put them to where they belong.
Didn't sound like you wanted an installer, at first. It sounded like you wanted a chess engine app. Where I would agree with Evert, that's not how apps work.

User avatar
Evert
Posts: 2923
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: Distributing engines for Mac/OSX

Post by Evert » Fri Mar 18, 2016 10:26 pm

hgm wrote:
Evert wrote:Personally, I would not appreciate programs moving themselves away from where I put them.
Well, that happens to be what installers do. Move things from where you put them to where they belong.

If you don't want that, you should just not run the installer. And that is the beuty of it, you don't need to. Just don't double-click the bundle. You can just enter the path name to the engine executable in your GUI like you could have done for any unzipped engine archive. People that don't know how to do that have the options to double-click the bundle, and will find the engine in their GUI's engine-selection box forever after.
If I know it's an installer, that's different. What I don't want is for a program to decide that I put it in the wrong place and move itself. Such things tend to be fragile anyway.
What about the file-selector dialog? Does that allow you to browse inside the bundle, or would it also shield the inside, like the Finder?
Apparently not: the bundles are greyed-out and you cannot browse into them.

JoshPettus
Posts: 730
Joined: Fri Oct 19, 2012 12:23 am

Re: Distributing engines for Mac/OSX

Post by JoshPettus » Fri Mar 18, 2016 10:34 pm

I'm sorry, what file selector dialog? The GTK one in XBoard? Cause that thinks XBoard.app is just a folder.

User avatar
hgm
Posts: 23364
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Distributing engines for Mac/OSX

Post by hgm » Fri Mar 18, 2016 10:41 pm

JoshPettus wrote:Only way to do that is with a package installer like the winboard installer for OSX. In which case if installation is going to be automated, we can install anything anywhere. The user doesn't have to access it. We might as well install linux plugins in the expected linux location.
Well, this isn't much of an install. So this 'packet installer' could be the following program in the MacOS folder of the bundle, designated as the primary entry point of the bundle, written and compiled by ourselves:

Code: Select all

main ()
{
    system("mkdir . /Applications/ChessEngine");
    system("mv . /Applications/ChessEngines");
}
If we want to be slightly more clever we could have this 'installer' test the architecture (32/64 bits, which SSE version), and rename the corresponding engine binary within the bundle to become the active one.

Of course we could move every individual component of the package to its Linux-compliant location too. But (apart from permission issues) I think it would be a good idea to conform as much as possible to the way Mac owners are doing things now.
I mean add it to Xboard's engine list. There is no launch script (most apps don't have one, that's just for GTK)
OK. But that is a very XBoard-specific thing. It would be much cleaner to let the GPS App on running just place .eng files in the location where XBoard expects them, and then let XBoard do its auto-install thing. Then it would work for any GUI that supports the plugin standard.
Apps don't behave that way, they don't share resources. They are self-contained bundles with all resources the executable needs included. This includes engines and even libraries. (defeats the purpose of the dynamic library, I know, but there you have it) Portability was deemed more important.

What you propose is utterly unique
Well, what you did with the GPS Shogi App already seems to violate that design. You let the XBoard App use an executable that was not in its own App bundle, but in another one.

I don't mind doing things in a unique way, as developer. As long as it works, and the user cannot see it, and would have to do anything unique himself, I would do whatever it takes.
I can think of apps competing to use types of documents. (eg a wav file) in which case you have to choose the default app, but that's different. We might as well stick with the linux locations. It's about as good as any other (since it's automated), instead of installation scripts we use installation package manager to install precompiled binaries.
The Linux locations could indeed be as good as any. Most other GUIs would only want to use the engine binary anyway, so they should not care much where the engine is. OTOH, when a 'casual users' want to register engines with GUIs that do not support the plugin standard, and have to browse through the executable, they might be disgusted by the fact that they have too browse to /usr/local/share/bin (even if they had been warned with a popup that this is where the engine installed itself), and might have more tolerance for this being /Applications/ChessEngines instead.
But as I said, No other GUI on OSX will use it.
That remains to be seen. Even if the chances for it seem dismal, I would not see that as a reason to discourage it. The point is that even if GUIs don't use the auto-install system, (i.e. ignore the ,eng files), they still should be able to easily use the same engine packages. Albeit in their own, cumbersome way. It is the users that should be coaxed into using our engine packages, by making them say: "Well, I prefer to fetch my engines from xxx.net, because then I can always easily find them when I want to register them in my favorite GUI, while otherwise I never know where they end up amongst my files".

User avatar
hgm
Posts: 23364
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Distributing engines for Mac/OSX

Post by hgm » Fri Mar 18, 2016 10:47 pm

JoshPettus wrote:I'm sorry, what file selector dialog? The GTK one in XBoard? Cause that thinks XBoard.app is just a folder.
Well, file-selector dialogs of other GUIs, like HIARCS Explorer or ChessBase. I assume these need the user to browse to the executable, so it would be bad if he could not reach it. In that case the installer should really destroy the bundle as a bundle. That still doesn't mean it has to scatter the files, however. It could still copy the files in it (or a selection of those based on the architecture) to /Applications/ChessEngines/<enginename>/ .

In fact this could provide another argument for casual users to prefer out bundles: "If I download from another website I always get multiple versions of the engine with strange names, and most of them won't work..."

User avatar
hgm
Posts: 23364
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Distributing engines for Mac/OSX

Post by hgm » Fri Mar 18, 2016 10:52 pm

Evert wrote:If I know it's an installer, that's different. What I don't want is for a program to decide that I put it in the wrong place and move itself. Such things tend to be fragile anyway.
So we call it "fruit-setup.app" instead of "fruit.app". On Windows there also isn't any way to see whether a .exe is an installer or the thing itself, other than when the name reveals it. I don't think this is where the real problems ly.

User avatar
Evert
Posts: 2923
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: Distributing engines for Mac/OSX

Post by Evert » Fri Mar 18, 2016 11:25 pm

hgm wrote:
Evert wrote:If I know it's an installer, that's different. What I don't want is for a program to decide that I put it in the wrong place and move itself. Such things tend to be fragile anyway.
So we call it "fruit-setup.app" instead of "fruit.app". On Windows there also isn't any way to see whether a .exe is an installer or the thing itself, other than when the name reveals it. I don't think this is where the real problems ly.
Ah, but a .app should not be an installer! It should be an application. If it's an installer, it should be a .pkg (otherwise it just ends up looking like a half-arsed Windows port).

No idea what those look like under the hood other than that they're also dressed-up directories.

Post Reply