Mac Chess Programming Opportunity ( not for engine )

[JoshPettus]

Back to bloat, I toyed with the idea of including a wineskin engine (which is a complete installation of wine in a bundle) for executing windows engines in xboard, but that's a whopping 306mb for my 64bit/32bit capable engine. and the 64 bit portion doesn't always work. So mention installation instructions on the download thread.

[sje]

Aside from CMD V,C,X,A which we discussed in the previous thread?

Second, where possible, the application should be callable from the command line and run without a GUI -- even on an embedded system where there is no GUI and no window subsystem. Nearly all Apple supplied OS/X programs are capable of this.

This part I don't understand. you mean with a method other then
"open -a whatever.app"? This works with xboard too.

What other way are you referring too?

Open TextEdit. Run through all the menus. Count all the command key bindings including shifted keys.

Unless it's changed, xboard needs a GUI even if the secret -noGUI option is supplied.

You shouldn't need to have "open" in the call. See the man page for diskutil for an example of not needing "open".

[JoshPettus]

diskutil is a command line unix style executable which is in PATH. (not to be confused with Disk Utility.app) Not a OSX application! I thought you were referring to apps like Firefox..

With regards to shortcuts, minus the text edit shortcuts I mentioned, and we will be sure to fix. Anything else that is relevant to Xboard, CMD-N for new CMD O for open. We Do. Unless you have any other suggestions.

[sje]

Disk Utility uses diskutil for all the real work.

⌘, is a must for Preferences.

Also, ⌘H and option-⌘H plus the Services sub-menu.

Apple has a write-up on all of these in their Human Interface Guidelines.

The best suggestion I have is to withdraw XBoard.app from beta testing and re-release it for such after it conforms in appearance and in operation with the standards as are in use by Apple's App Store. (Not that I totally agree with their standards, but that's what app users expect.)

My guess is that the GTK->OS/X scheme is not workable. There are too many difficulties as evidenced by pages and pages of thrashing discussion -- an indicator that something is wrong with a basic premise or two.

[mvk]

There is no requirement or expectation that applications have a shell counterpart. Preferably this is the opposite, because PATH doesn't look in bundles, and making a shell counterpart available pollutes the installation which should consist solely of dragging a bundle into the Applications folder. 'open' is the right way to start an app from the shell. `diskutil' comes with the system BTW.

[JoshPettus]

Rookie is completely right, there is no such requirement.

⌘, is a must for Preferences.

Not relevant for Xboard as we don't have a Preferences menu.

Also, ⌘H and option-⌘H plus the Services sub-menu.

Already put in the Application menu by the OS, and works fine.

The best suggestion I have is to withdraw XBoard.app from beta testing and re-release it for such after it conforms in appearance and in operation with the standards as are in use by Apple's App Store. (Not that I totally agree with their standards, but that's what app users expect.)

Seeing as we are using GTK2 and not Cocoa, we will never be able to conform to Apple's App store standards, Never mind the incompatibility with GPL.
Best we can hope is to camouflage it a bit. Nor do I agree that people's expectations are that stringent. Otherwise SCIDvsMac would be despised as opposed to being among the most recommended free OSX chess software.

[MikeB]

Fully agreed. For XBoard it almost always holds: if you are editing files externally, you are doing something badly wrong.

You do have a penchant for blaming the user and not the app. Try to be less sensitive about the work you have done. You have done very good work and obviously put many many of your own personal hours into xboard as others have, and for that, I thank you and the others that have contributed as well.

[hgm]

It is not my intention to blame anyone. I just want to warn everyone.

The problem is that the user friendliness of the App doesn't matter the slightest if people keep using it in hacky ways. It could do everything the user wants with a single mouse cick like magic in the most intuitive way, this could all be extensively described in an elaborate manual... It won't help if they start looking for settings files, editing their cryptic contents, and complain it is so geeky that you 'have to do that', just because it was needed to do that 20 years ago, and they somehow remember that and never read any manuals.

It turns out it is just very difficult to break away from history. If people are not sure how to do things they won't read the manual, but will use Google. Which will gives them hits on some 10-year old posting with elaborate descriptions of how to create Polyglot ini files from scratch, rather than the remark that you just have to tick the UCI checkbox when installing the engine.

So it cannot be repeated enough, at least until every person that anything to do with Computer Chess will mumble it unconsciously in their sleep:

If you are editing settings (ini) files you are doing something badly wrong.

The unavoidable counterpart of this is Stevens remark:

If it would ever be needed to edit settings files, the design is badly broken.


If you would have known that when you installed the XBoard App, I don't think that you would have wasted 20 hours on getting it to work (and consequently complained that it was so geeky). People really have to know it in advance to not fall into the trap of trying to locate ini files inside the App and hack those with a text editor, because of 'historic prejudice'. Perhaps we should have XBoard encrypt those files, so that people can no longer read them at all, except that there are still some really geeky things (like altering the ICS Text Menu) for which editing the user settings file could still be the most efficient way.

So definitely the App should work well, and have a user-friendly and intuitive UI and pre-configured settings. And we do work at that, and do take your feedback seriously. (Which is why I still regret that you did not elaborate on what exactly the problem with the trn files was that you felt the need to edit them.) If the browse buttons for the game save file steer people to creating these files in places where they have no permission to do that this is not 'intuitive', and could possibly be improved by new configure options that would steer them to the right place automatically.

But if people are not educated into actually using these features, but keep insisting on editing the settings file, and only start to complain harder when they cannot find it, and even harder still when they first have to decrypt it, it will be all for naught...

[JoshPettus]

It may not be a bad idea to encrypt the master config file. Maybe there is a way to "compile" it like apple does with its InfoPlist.ini files (they hold all the registry information for the app bundle).

That Polyglot.ini method for installing UCI engines sure dies hard. I've been telling people for years to not do that. Sometimes I wonder If it might be better to just declare "XBoard5! Not like your grandma's Xboard!"

[MikeB]

That Polyglot.ini method for installing UCI engines sure dies hard. I've been telling people for years to not do that. Sometimes I wonder If it might be better to just declare "XBoard5! Not like your grandma's Xboard!"