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?)
Distributing engines for Mac/OSX
Moderators: hgm, Rebel, chrisw
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Distributing engines for Mac/OSX
I don't think that's a concern: if the folder exists it should just copy the content into it. Worth checking though.JoshPettus wrote: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.....
The upcoming new ChessV GUI will probably support it.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?)
-
- Posts: 27793
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Distributing engines for Mac/OSX
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?JoshPettus wrote: 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.....
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.
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...I'll have to think about this some more. My gut tells me it's a fine solution to a mostly non-problem.
All trends have been started by someone that initially was the only one doing it...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?)
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.
-
- Posts: 589
- Joined: Tue Jun 04, 2013 10:15 pm
Re: Distributing engines for Mac/OSX
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).
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).
[Account deleted]
-
- Posts: 27793
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Distributing engines for Mac/OSX
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.mvk wrote: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.
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.
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.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.
-
- Posts: 27793
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Distributing engines for Mac/OSX
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.
-
- Posts: 589
- Joined: Tue Jun 04, 2013 10:15 pm
Re: Distributing engines for Mac/OSX
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.hgm wrote: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.
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.
[Account deleted]
-
- Posts: 27793
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Distributing engines for Mac/OSX
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?mvk wrote: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.
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.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.
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Distributing engines for Mac/OSX
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.hgm wrote: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.
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).
-
- Posts: 27793
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Distributing engines for Mac/OSX
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. ![Laughing :lol:](./images/smilies/icon_lol.gif)
![Laughing :lol:](./images/smilies/icon_lol.gif)