Distributing engines for Mac/OSX

[JoshPettus]

Yeah an .app being an installer isn't the right idea. What would be better if these engines were just folders containers called Engine.bundle or .plugin, tell the user to throw them into say /Applications/ChessEngines, then the user has some agency and is closer to OSX culture. We can even put these engines in a folder called ChessEngines on the dmg image file. With that there would be an alias to the Applications folder and an arrow in the background to strongly hint to drag the folder to Applications, but then we have to worry about overwriting the existing folder.....

I'll have to think about this some more. My gut tells me it's a fine solution to a mostly non-problem. Occasionally I see a request about someone not knowing to check the UCI box, and maybe it could fix that. I bet XBoard is going to be alone in this. Has anyone other then pychess implemented the linux plugin? (did pychess impliment it?)

[Evert]

Yeah an .app being an installer isn't the right idea. What would be better if these engines were just folders containers called Engine.bundle or .plugin, tell the user to throw them into say /Applications/ChessEngines, then the user has some agency and is closer to OSX culture. We can even put these engines in a folder called ChessEngines on the dmg image file. With that there would be an alias to the Applications folder and an arrow in the background to strongly hint to drag the folder to Applications, but then we have to worry about overwriting the existing folder.....

I don't think that's a concern: if the folder exists it should just copy the content into it. Worth checking though.

I'll have to think about this some more. My gut tells me it's a fine solution to a mostly non-problem. Occasionally I see a request about someone not knowing to check the UCI box, and maybe it could fix that. I bet XBoard is going to be alone in this. Has anyone other then pychess implemented the linux plugin? (did pychess impliment it?)

The upcoming new ChessV GUI will probably support it.

[hgm]

We can even put these engines in a folder called ChessEngines on the dmg image file. With that there would be an alias to the Applications folder and an arrow in the background to strongly hint to drag the folder to Applications, but then we have to worry about overwriting the existing folder.....

Well, if that would be the natural thing for Mac users to do, we should embrace it. But if the thing in /ChessEngines/ of the dmg image is a bundle/plugin, wouldn't that shield the engine binary from being selected in GUIs that still require the user to do it by hand?

If the .eng files stay in the folder with the engine there also is the problem that the auto-install process has to work differently on Linux and OSX. Which will not help much to get wider support for it.

I'll have to think about this some more. My gut tells me it's a fine solution to a mostly non-problem.

It is only a non-problem because you assume that there will be all kinds of dedicated code in XBoard to solve it. But the problem is very real: auto-install would not work, logos would not be displayed, help texts in the Engine Settings dialogs do not show up, XBoard should have a handler for installing a package format it gets associated with...

Occasionally I see a request about someone not knowing to check the UCI box, and maybe it could fix that. I bet XBoard is going to be alone in this. Has anyone other then pychess implemented the linux plugin? (did pychess impliment it?)

All trends have been started by someone that initially was the only one doing it...

If .pkg is the standard format for things that have to be installed on OSX, we should of course go for that. My fear is that this would be "using a cannon to shoot a mosquito", forcing the user to answer all kind of confusing questions that can only serve to make the installation fail. And finally not being able to do what we want (e.g. detect which engine binary to install based on architecture). But perhaps this is a completely imaginary fear.

[mvk]

Some more random thoughts:

I would be happy to install engines in the .pkg installer way: the clickable thingies in .dmg files with boring cardbox icons.

Maybe also interesting: there appears to be an .app type that can be used as plugins: they are called "loadable bundles". They are just like bundles except they don't need a "main". I have no experience with them as I wasn't aware of these before, but it appears you could pack engines with their resources into them.

About establishing a binding between engine and application: I feel there is nothing really wrong with selecting each engine's unzipped directory once from within each applications of interest. I'm afraid that with all contemplated automagic ways we're heading down the road of sparing all of mankind a few hundred mouse clicks, tops, while burdening it some non-standard niche mechanism in return.

But with the "loadable bundle"-based plug-ins the user can drag them into /Applications/Chess Engines/[*] for example where any interested chess application can find them. I noted I have a "/Applications/Media Players/" already, apparently for a similar purpose.

[*] With the space please... I'm fairly fussy about consistency within the target platform and cringe seeing programming conventions leaked to the user.

Initial creation of the directory needs a little thought. For example how would Xboard.app app and fairmax ship. Supposedly in the same .dmg.

From a wider perspective I would be far more concerned about supporting multiple boards in Xboard.app, as that is the main reason for me I can't use it for the same things I used xboard for in linux. E.G., I expect to be able to press Command-N in a native app and open a new project/board/game that way, but xboard clears the current one instead. That is inconsistent. Xboard has always felt a bit as if it is designed around a bunch of global variables with buttons manipulating them and not around an object model. Putting each board and support panes in its own paned window or tab is also going to be a big win. Cutechess GUI did such things well and it looked pretty. That codebase might be in a better position to evolve into the open source chess app of choice on mac (provided it can fix its ever returning Qt library binding issues, and if it resumes evolving of course. Dreaming now. I really liked that GUI, it showed a lot of promise).

[hgm]

From a wider perspective I would be far more concerned about supporting multiple boards in Xboard.app, as that is the main reason for me I can't use it for the same things I used xboard for in linux. E.G., I expect to be able to press Command-N in a native app and open a new project/board/game that way, but xboard clears the current one instead.

Well, Ctrl-N in XBoard is the accelerator keystroke for the menu item 'New Game', which formerly was called 'Reset'. I thought this was a more clear description. It seems, however, that this renaming throws off your expectancy of what the item is supposed to do.

XBoard's design is based on different kind of infos being shown in different windows. That makes tabbing in one window to navigate between different games a bit unnatural. The way XBoard handles this problem is by opening several instances of it. Selecting one from the task bar then automatically raises all auxiliary windows with it. This should work the same way on OSX as on Linux. On neither there is a menu item or keystroke that launchess a new XBoard instance, however. If you think it would be useful to have such a menu item, we could make one, of course.

That is inconsistent. Xboard has always felt a bit as if it is designed around a bunch of global variables with buttons manipulating them and not around an object model. Putting each board and support panes in its own paned window or tab is also going to be a big win.

I think that would be awful. The main reason that I consider XBoard so much better than anything else I have ever seen is that I can close all stuff I don't want to see, and layout the rest exactly as I like it, without being restricted by some outer window.

[hgm]

To get back on topic, I still don't understand why there is so much resistance to distribute installers as App bundles. An installer is an application. A .pkg file doesn't seem to be an installer; it is a document associated with a standard installer, like .7z files on Windows are associated with 7Zip, or .tar.gz with the archive manager on Linux. On Windows 'self-extracting archives', which were normal .exe files, at some point were quite popular. If you want to supply your own installer, rather than rely on a system service that might not be adequate for your purpose, distributing it as an application seems the natural thing to do.

[mvk]

The main reason that I consider XBoard so much better than anything else I have ever seen is that I can close all stuff I don't want to see, and layout the rest exactly as I like it, without being restricted by some outer window.

There is no conflict there. In the cutechess gui you can still configure panes at will, or put them in a separate window, or drag them back into the main window at ease. At least that is how I remebered it. Now my version is broken because of the Qt binding are broken.

I suggest to use osx for a couple of months to get familiar with the aspects of the user experience. There is only a limited amount of it we can convey by putting it in words. Direct interaction has a lot more bandwidth.

[hgm]

There is no conflict there. In the cutechess gui you can still configure panes at will, or put them in a separate window, or drag them back into the main window at ease. At least that is how I remebered it. Now my version is broken because of the Qt binding are broken.

Well, in XBoard the sticky-windows option also allows you to assemble the various windows into a larger conglomerate, that drags and opens as a single unit. So there desn't seem to be much difference. Running different games in different processes seems a much cleaner way to do things. Doing it in tabs of the same instance would just raise problems. E.g. would each tab has its independent settings, e.g. of the GUI book or hash size, or would they share such settings? Would each tab have its own Game List for a loaded PGN file? Would they save the game on the same file when it finishes? What if one tab uses a 9x10 board and the other a 12x8 board?

I suggest to use osx for a couple of months to get familiar with the aspects of the user experience. There is only a limited amount of it we can convey by putting it in words. Direct interaction has a lot more bandwidth.

A bit hard to achieve, however. Even if only because I don't want to postpone the release of XBoard 4.9.0 that long, and I have to know where it would have to look for the various engine-related files (man page, auto-install info, logos) to make the new features work on OSX as well.

[Evert]

To get back on topic, I still don't understand why there is so much resistance to distribute installers as App bundles. An installer is an application. A .pkg file doesn't seem to be an installer; it is a document associated with a standard installer, like .7z files on Windows are associated with 7Zip, or .tar.gz with the archive manager on Linux. On Windows 'self-extracting archives', which were normal .exe files, at some point were quite popular. If you want to supply your own installer, rather than rely on a system service that might not be adequate for your purpose, distributing it as an application seems the natural thing to do.

You can certainly customise a .pkg installer (it's not a file though, it's a directory, or bundle if you will), but I've never done it so I'm not familiar with the details.
The reason there is resistance to having an App bundle perform the actions of an installer is that it's not the normal way things work: sure, you can do that, but it feels very much like someone did a port from a Windows program and couldn't be arsed to figure out the normal installation process on OS X and so imposed the way they are familiar with. It's just not the expected behaviour.

I've encountered programs that make you go through a .pkg installer to install an App bundle in /Applications, which is just obnoxious (and needlessly complicated).

[hgm]

If I have to choose between unexpected behavior that does the job cleanly, and formally correct behavior that is combersome and raises problems, I know what I would prefer... After all, the behavior only starts to be unexpected only after it is too late for the user to repent. You can always pop up a dialog to apologize for startling him.