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".
