Mac Chess Programming Opportunity ( not for engine )

[hgm]

Wasn't talking about the interface - just simply all the extra files and line items on file settings pertaining to the variants when you start digging into the application , obviously for somebody such as myself, it would be cleaner if those items were simply not there in the first place.

This is not something that would be controlled by compiling. I am still not completely sure which files you are talking about and what "line items on file settings" are (but having no Apple hardware I have never seen Joshua's App, so I only have a vague notion of what is in there). In the folder with piece images there should be a few images of unorthodox pieces. So what? The files are tiny. Noob users have no business opening that folder in the first place; they can only wreck things there (by deleting or renaming svg files). There might be a xiangqi-board image amongst the textures.

Of course it should be possible to create a separate App bundle for orthodox Chess only. And one for ICS-use only, without any engines and opening books (which would actually save a lot more space). If I am not mistaken Joshua already prepairs separate Apps for Shogi-only and Xiangqi-only. All pack exactly the same XBoard binary, just different settings files. But one has to strike a balance between having very many Apps for very narrow applications, which makes it difficult for a novice user to figure out which App exactly he needs, and excessively bloating one-fits-all bundle. I honestly don't see what problem leaving out a few image files would solve that it would warrant diversifying the packages.

For WinBoard I use a bundling strategy where the bundle contains everything, but during install the user can select which components he wants to leave out (as entire groups, e.g. all Xiangqi stuff, but also individual engines or space-consuming graphics within the groups).

[MikeB]

For WinBoard I use a bundling strategy where the bundle contains everything, but during install the user can select which components he wants to leave out (as entire groups, e.g. all Xiangqi stuff, but also individual engines or space-consuming graphics within the groups).

Perfect - choose your options when you do the installation. I like that.

FYI, not exactly a Noob - I can remember setting up winboard back in the 90's and it took less than an hour it was pretty straightforward. I wish I can say I only spent an hour or two with xboard , but I'm afraid it was much more than that. Part of the issue and this is not your fault - is that I was away from Computer Chess and computer for a bit - I had not owned an Apple in over 20 years - decided I was sick of MS windows and went back to Apple. Was not expecting all these issues with permissions and had to get up to speed with chmod 755 etc. Another items that came up and again it's not anyone's fault - but I acquired a second apple computer and I migrated all my apps from the first computer. That process worked pretty well except for xboard. It was non functional primarily due to permission issues and where certain files were stored in the various folders on the initial stall on the first computer. So for anyone out there - do NOT migrate your xboard app to a different Mac - do a clean install and then move any of the settings files to your documents folder if possible. I have separate folders for results , openings and tourney settings.

All this is water under the bridge - it's now working pretty well - Joshua has given me some tips that I'm am going to look into . If I have time, I will write up a precise installation process that will help Mac users avoid any issues that I had and some tip and tricks - especially for those that want to run engine tournaments like I do. It is a pretty nice chess app once it gets set up properly. I spent over 20 hours just to get xboard to work. I know it is supposed to be just a drag and drop from the dmg file - but that simply didn't work for me (and the precise details are getting vague - that was over 5 months ago now.)

[MikeB]

First just copying from the DMG file created too many issues - it was unworkable. Cant tell how many hours I put in just to figure how the thing works and where all the files were. After going through an installation several times I can tell you the easiest and best way to install it is through MacPorts - there are no issues with that process. I don't even use it for internet play, but I know you have seen SJE comments.

Just for my understanding: I suppose 'DMG file' is the OS X App compiled by Joshua? I guess the idea of the App was that people would not have to know where the files were, because they never have to touch them (other than through XBoard). So if they seem hidden, that is partly intentional; we don't want inexperienced users to wreck things by messing with the files. What files did you need access to?

Just for clarification the dmg is just a compressed disk image for distribution. It's like zip folder, but sets up permissions correctly. I don't understand how copying from the dmg is an issue if you could please clarify. Copy to your Applications folder or any other directory where you have write access too. It should just work when you try to execute and find any resource it needs.
Just like any other OSX app. I really didn't have to do anything fancy with permissions. I take it no other application has been giving you trouble?
If that were the case I recommend going to /Applications/Utilities/DiskUtility and doing a permissions check on the drive.

The best place for the trn files , pgn results and opening books is in the documents folders

I don't understand, and if so I apologize. Yes documents is the best place to save such files. What's wrong with using the UI to save your files there? GTK2 even has that sidebar where you can save commonly used folders for quick access. And the home folder is already there. When you want to open those files with xboard, just click on them (Or you can use the UI's open menus). As long as xboard is set as the default app to open the file it will open correctly.

Obviously the Mac OS is now being construed for the enterprise environment and it is really strict with permissions - but for personal user that is using UI that thinks everything can be set up through the UI - it becomes one royal pain in the a$$. I'm sure there are users out there that thinking "whoa - this not quite ready for primetime - it must still be in beta" and get something else. I also have to make sure I set up a blank pgn file so that the games can be saved.

I never ever had to do that. That really sounds like a permission issue in the folder you are saving too. Permissions in a folder can be edited. right click a folder, get info, on the bottom there. If it's your document folder that is causing this much trouble, again I really recommend you run disk utility and do a permission check.

- so again xBoardapp.conf should be in the documents folders where users can get to it easily and have the permissions to edit it. It is too geeky not that you have perhaps do some minor editing on setting files it is too geeky because just finding those files can be time-consuming (default appears to to various locations ) and editing them easily , deleting them or replacing them with another version becomes one royal pain in the ..

Quite true though you always have permission to edit preference files, otherwise apps wouldn't be able to write to them in the first place. Apple has that keyboard shortcut to get at the user library folder, hold alt, go to the Go menu and your user library folder is suddenly there. But they really made it difficult to get at, and that is entirely apple's fault. They try hard to hide the inner workings of the OS...

The thing is all OSX apps save their settings files there. User/Docs is strictly for user document files. We can of course change it, but it would be against the norm. Not to mention editing preference files is the definition of geeky. Therefore I agree with harm that more control in the UI is the better solution.

P.S. Sorry for hijacking the thread, but I guess everything that can be said about the job opportunity has already been said in the first posting anyway.

Me too, sorry about that. It really wasn't my intention either, but thank-you for your feed back!

Appreciate all your tips and feedback - will look into some go your suggestions. It is now apparent to me that some of my issues were caused by using the apple migration tool with xboard. For most apps , that worked pretty well. For xboard, it just compounded the permission issues.

Anyway - it is working pretty well now and maybe even better after I look into your tips.

[MikeB]

know it is supposed to be just a drag and drop from the dmg file - but that simply didn't work for me (and the precise details are getting vague - that was over 5 months ago now.)

Some of the details - just came back to me. I remember the first issue was adding an engine through the UI. Being familiar with the old winboard ini files and remembering that was a pretty straightforward process , went off on my own to fix my issues. Classic case of having a little bit of knowledge is dangerous.

[JoshPettus]

Perfect - choose your options when you do the installation. I like that.

I fear such an installation is against apple philosophies. If we must, we can create a package installer for such things. In principle, I hate those. There is no telling what the heck it's installing on your system and where. But everyone in Windows likes such things, and linux has them too, so I must be in the minority.

I spent over 20 hours just to get xboard to work. I know it is supposed to be just a drag and drop from the dmg file - but that simply didn't work for me (and the precise details are getting vague - that was over 5 months ago now.)

I understand completely. If you run into trouble again feel free to email/pm me. I might be completely wrong, but right now it sounds to me like trouble you would be running into with any application. Permissions are a system problem. In the future I can probably include a shortcut to the application folder so people know where to put it. (a lot of dmg's do this) Only I have those ics launch scripts as well and I have no idea how people would want do deal with those.

Oh for the record to launch Xboard.app with external command lines you have two options.
a)Command-line, since xboard app's executable is not in path you have to use apple's "open" command e.g.:
open -a xboard.app --args -whateverArg1 -whateverArg2 ...

or

b) put all those launch args in a text file and use the .xop extension. Then you can click on that file and (xboard being the default app to open .xop files) the OS will open xboard with those settings. It's a great way to create special shortcuts to launch with xboard.app, in liu of window's style shortcuts which aren't available. As I keep badgering harm, I would one day really like to do this with the ICS scripts so they can be opened anywhere on the system, but ICS depends on xboard opening in the terminal.

[JoshPettus]

Appreciate all your tips and feedback - will look into some go your suggestions. It is now apparent to me that some of my issues were caused by using the apple migration tool with xboard. For most apps , that worked pretty well. For xboard, it just compounded the permission issues.

Anyway - it is working pretty well now and maybe even better after I look into your tips.

Ah, I never did an apple migration, although the new time machine method seems to work fine. Lord knows what kind of permission issues you would run into, as it's permissions from another system... But you would think apple would have thought it through...

[sje]

I have a lot of things to say here, but at present have time only for a few of them.

First, any part of an application which CAN be written in a platform independent manner SHOULD be written in a platform independent manner. For what you're doing. nearly all of the code can be implemented to run on any Unix/like system without platform dependencies.

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.

Third, to ensure platform independence, an application should be developed and tested on at least TWO different platforms at the same time. This is the only reliable way to avoid costly, error-prone backtracking.

As to OS/X issues concerning where to put stuff:

1) For user preferences, it's always ~/Library/Preferences/<AppName>

2) For site specific preferences, it's always /Library/Preferences/<AppName> and this is done usually by the OS/X Install program following an installation script.

3) For application specific data (always read-only other than during an upgrade process), then it's in the resource directory in the application directory bundle.

4) It should be NEVER in a configuration file in the user's home directory; that's Unix general style but it's not OS/X style.

5) If stuff is in the wrong place, then the OS/X Migration utility (among other utilities) will fail.

6) If the user ever has to edit or even look at configuration files directly, then the design is broken.

And naturally, every OS/X application should have an installer script run-able by the OS/X Installer, and this script should also have an uninstall button. If the user is ever forced to use the terminal emulator or the text editor, then the design is broken.

Further, every decent OS/X application with a GUI has about two dozen command key bindings which have the same semantics across all other decent applications. Users expect consistency here and elsewhere, and if the application is not consistent, then it's broken.

[JoshPettus]

Regarding Xboard.app bloat with non Chess images and engines, Xboard is advertised as a UI for chess and chess variants. So I try to strike a balance without being too obtrusive for people only interested only in chess, and still have demos so people can explore xboard's functionality. The app size is only 25mb (mostly libraries, variant stuff barley takes up 1mb). And in xboard, I think i do a pretty good job with not being obtrusive. In the builtin engine list, variant engines are listed under the Variant Engine sub group. Just as with variant board themes are in a sub group of their own. So both only take one line on their respective list. And the variants selector is just one menu item in the File menu. Personally I don't find this too much.

If you are advanced enough to be bothered by the variant subgroup of engines, it can be edited out. I think a delete option for the select menu would be a good idea though.

[hgm]

Well, XBoard actually conforms prett wellto your ideals"

First, any part of an application which CAN be written in a platform independent manner SHOULD be written in a platform independent manner. For what you're doing. nearly all of the code can be implemented to run on any Unix/like system without platform dependencies.

There is only very little code in XBoard that is enclosed in #ifdef __Apple__ . Most of it is necessary by the different way OS X handles command-line arguments (sending them through a signal).

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.

So far I did not manage to do that for XBoard. It is essentially dependent on the widget set's event loop for generating the input and timer events. I would have to program alteratives for that using input threads. This makes it basically a different front end, with very little benefit in making the same binary capable of both. I would prefer a separate 'NoBoard' build of XBoard.

6) If the user ever has to edit or even look at configuration files directly, then the design is broken.

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

Further, every decent OS/X application with a GUI has about two dozen command key bindings which have the same semantics across all other decent applications. Users expect consistency here and elsewhere, and if the application is not consistent, then it's broken.

Can you tell me which key bindings these are?

[JoshPettus]

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?