Mac Chess Programming Opportunity ( not for engine )

[MikeB]

There is fee based Mac chess programming opportunity. The optimal candidate will be fluent in Mac programming with experience in game layout and design, UCI Chess Engine commuincation protocols and chess game database management.

It will be native Mac, with a simple, basic database feature set at first and obviously game play. Engine to Engine play and multiple engine capability will not be an initial requirement , but the savvy programmer will consider those 'add ons " as a potential revenue stream in the future . There will be two deliverables - first deliverable would be beta proof of concept and functionality which you will get paid for. If accepted for production, second deliverable is a release product that should be fully functional and largely 100% bug free and will receive your second payment.

For the right candidate, this will be a 4 up to a very low 5 figure deal.

I have no financial stake in this - my only role will be to act as unpaid intermediary to setup initial discussions that you will have with the buyer of your services. This product is initially positioned as value proposition for the everyday chess player - not to replace winboard/xboard ( too geeky) or chessbase (too expensive/complex) to be sold worldwide, both online and CD and through 3rd party outlets such as Amazon. If you're in a position to forgo payment for % of the sales, that possibly could be considered.

PM me if interested with programming background and contact info. They will contact you directly if they are interested in you.

[JoshPettus]

When chess player programmers are complaining your program is too geeky, you know you have problems...

For the OSX build, we attempted to have xboard's functionality through the UI, without resorting to the command-line, wherever possible.

[MikeB]

When chess player programmers are complaining your program is too geeky, you know you have problems...

For the OSX build, we attempted to have xboard's functionality through the UI, without resorting to the command-line, wherever possible.

Hey don't take me wrong I appreciate what you and others have done. Here are some of my observations.

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. My process for setting up a tournament involves doing what I can through the UI - not everything takes and then having to edit the tourn files. The best place for the trn files , pgn results and opening books is in the documents folders - there you will have the least amount of headaches dealing with repeated permissions issues - especially if you migrate to a different Mac - that should be the default. Even though you try to make it so that folks don't have to do manual edits - you will have to do manual edits at some point - and when you place them in library's and other typically hard to find spots - you will end up with permission issues. Anything that can be edited - should in the documents folder - call xbaord preference or xboard library - but put in all the editable documents and files the documents folks so it can easily edited.

Also any type of file , such as a png file for board colors etc - that should also be in the document folders so a user can quickly have it setup the way he wants it set up without repeatedly dealing with permsissions issues

Getting back ton setting up a tournament, once I'm done with the UI - I then have to go back in and manually edit the items that did take through the UI., Example, opening position fen does get updated in the trn file using the UI. Not sure why - but my guess it is a permissions issue. 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. The -noGUI option should be one that you select in the UI - if it's there, I apologize - but I have looked for it and can't find it. As far as adding engines through the UI - that seems to be working well.

But often , over times you you end up with blank rows or other items that need minor editing with engines - 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 .. due I believe primarily to the permissions issues and if they were simply in the documents folder it would be so much easier. Once I get a tournament going it runs fine and I have developed my own process to run tournaments repeatedly without too much effort - but to figure that process out was very time consuming and most people that just want to plug and play with the UI would have given up.

With that said, I believe the number of people actually using xboard for the mac must be very low. I post messages about engines that I have complied for the mac and the post might get 200 views but maybe only one person would be interested in obtaining the mac exe. It's a shame too - because Apple definitely has it over on Windows. I have compiled Senpai, Hakkapeliitta, robbolito0085g3l, Texel, Stockfish, Giraffe , Firenzina all for the Mac - let people know it was available for download - very little response.

[MikeB]

I should add - I'm very happy with it now for what I use it for, but most folks would not have the patience or the persistence to make it work the way it can work with minimal issues. Also I know there are small group of people that enjoy all the chess variants and I respect that, but it would be nice to have a compile define for -DNO_VARIANTS.

[hgm]

Hey don't take me wrong I appreciate what you and others have done. Here are some of my observations.

Feedback like you are giving is really very useful to us. Unfortunatly we receive very little of it. So thank you for the trouble of writing this elaborate report.

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?

My process for setting up a tournament involves doing what I can through the UI - not everything takes and then having to edit the tourn files.

Well, this sounds like a general Win/XBoard bug. It is definitely not the intention that it should be needed to edit .trn files for normal applications.

The best place for the trn files , pgn results and opening books is in the documents folders - there you will have the least amount of headaches dealing with repeated permissions issues - especially if you migrate to a different Mac - that should be the default. Even though you try to make it so that folks don't have to do manual edits - you will have to do manual edits at some point - and when you place them in library's and other typically hard to find spots - you will end up with permission issues. Anything that can be edited - should in the documents folder - call xbaord preference or xboard library - but put in all the editable documents and files the documents folks so it can easily edited.

Although this is really Joshua's domain, I tend to agree. There should be no protection issues, and if OS X is set up in such a way that there is an obvious place where users can create and write their files, (e.g. for the persistent settings and default save game file) we should use that. If it requires creation of a sub-directory we should consider having XBoard create that at startup when it doesn't exist yet. We have an option -saveSettingsFile in the master settings file that would make XBoard create a settings file of the given name if that did not exist yet, but so far than handles only plain files in existing folders. We could enhance that to allow a not-yet-existent path name to be given there, and have XBoard create all folders appearing in there, if necessary. This would still work only at the end of the first session, though, when XBoard automatically saves settings. So it would probably be better to add an option -createDirectory of an entirely new class, which would create the mentioned folder. One or more of these could then be put in the master settings file, to create a sub-tree of the documents folder where the settings could then go, like "xboard library".

Also any type of file , such as a png file for board colors etc - that should also be in the document folders so a user can quickly have it setup the way he wants it set up without repeatedly dealing with permsissions issues

This might point to a deficiency in the UI for specifying graphics files (such as pieces or board textures). This was basically designed with the idea in mind that these files (which are always used as read-only) could be anywhere, and the user would just browse to them. In Linux (and I suppose this is the preferred structure of an OS X App bundle too) the files that come with XBoard during install typically go to a privileged place in the system, where the user does have restricted access. I think it must be that way, because you don't want any single user to delete such files, and spoil it for the others that way. XBoard without the svg files for its default pieces would not work at all.

But I see how the current design would cause annoyance with users that also want to create their own 'library' of board textures and piece designs. If they do that in a place accessible to them, it becomes a pain to navgate back to the 'system data' if you want to put the 'factory settings' for board or pieces back.

I tried to solve that by having pre-packaged 'board themes', so that the user would not actually have to supply the pgn file names for the textures (by browsing or typing) and other 'low level' details themselves, but could simply select themes 'default' or 'native' from the themes list to get settings back that involved the files shipped with the install. Ideally the browse button for such files should then start in the user's library for these kind of files.

Any input for how the design could be improved in this area is welcome.

Getting back ton setting up a tournament, once I'm done with the UI - I then have to go back in and manually edit the items that did take through the UI., Example, opening position fen does get updated in the trn file using the UI. Not sure why - but my guess it is a permissions issue.

I don't think it can be that. Unless no trn file was created at all. XBoard always creates the tournament file in one swoop, and writes all relevant settings in there. The only write access to it that it needs later is for updating the -results string. And this is absolutely essential; if that would not work the tournament would never progress, because it will repeat the first game forever, not knowing it has already been played.

The way you talk about this makes me a bit uneasy. What do you mean by "get updated in the trn file"? Apart from the -results tournament files never get 'updated' after they are created. You cannot alter tournament parameters when a tourney is in progress without wrecking the tourney. Once written the trn file is supposed to be an immutable representation of the tournament conditions, so that these will be exactly reproduced on every game of the tourney. With only two exceptions, XBoard will therefore never update anything in the tournament file: when a game starts or finishes this is marked in the -results string, and when you try to resume a tournament that is already finished, it adds another cycle of games to it.

I cannot exclude that you are somehow using the UI in a wrong way.

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.

This indeed sounds like a problem with create permissions. But where do you try to create that file? Normally the sub-tree of the App should be a 'no-go area' for normal users. In Linux files (like the -saveGameFile) are created by default in the current directory, which is assumed to be in the sub-tree of the user's home directory (from which the user would normally work). I don't know what the OS X eqivalent of that is, but we should definitely organise it such that the user would end up working from his own folders, and not in some protected system place, no matter how he started XBoard.

The -noGUI option should be one that you select in the UI - if it's there, I apologize - but I have looked for it and can't find it. As far as adding engines through the UI - that seems to be working well.

Well, -noGUI is really an experimental option that was more a quick hack than a serious option. It was intended for engine developers, which I count as expert users. I cannot imagine that an average user that works from the UI would ever have any need for that option, and making it possible to accidentally tick it would just make him panic that his XBoard doesn't seem to work anymore.

What are the conditions under which you feel the need to switch to -noGUI mode during a session? I can imagine one inconvenience with the use of -noGUI, which is that to make all XBoard agents working on a tourney automatically use -noGUI mode requires you to edit the .trn file, to add the -noGUI there. This could be solved by adding an extra text entry 'Special tourney options' in the Tournament dialog. The text in this field could then be integrally copied into the tourney file, when the latter is created. So that an expert user could write '-noGUI' there. (And basically every other geeky thing he wants, like configuring XBoard for non-standard variants by specifying a -pieceToCharTable or whatever.)

But often , over times you you end up with blank rows or other items that need minor editing with engines

Not sure what you mean by 'blank rows'. You are talking here about editing the enginelist, right? Not about a need to edit other settings.

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

Yes, I agree. The intention is that files should never have to be edited through an external editor (which would require you to find them). This is why there is a menu item "Edit Engine List". This is already a bit geeky, but really only intended for expert users that want to add some work-around options for non-compliant engines to an engine line. Installing compliant engines should fully work through the Load Engine dialogs. Even non-expert users usually manage to delete lines for engines they no longer want, or sort them in a different order.

I guess the sorting or deletion problem could have been solved by adding button controls in the Load Engine dialogs to delete the selected engine, or move it up or down the list. It seemed a lot of a hassle to do something that simple editing does by default. But perhaps in a future version I will add that. How important do you think this is? Would it solve a real problem?

due I believe primarily to the permissions issues and if they were simply in the documents folder it would be so much easier.

If there is a permission issue I gues the Edit Engine List menu item also would not work. But this is hard to imagine, because it would imply that saving settings does not work. Edit Engine List really does not access any files at all: it just changes XBoard's internal setting for that list. This changed list would then be used for the remainder of the session, and automatically saved in the settings file only when you quit XBoard (or press "Save Settings Now").

Once I get a tournament going it runs fine and I have developed my own process to run tournaments repeatedly without too much effort - but to figure that process out was very time consuming and most people that just want to plug and play with the UI would have given up.

The intended way to run a tournament repeatedly is:
1) Open the Tournament dialog
2) Browse to the trn file of the tournament you want to repeat
3) Press "Clone Tourney"
4) Optionally change whatever you want the Tournament dialog (or excaping to TC etc.)
5) Press "OK"
That doesn't sound very geeky to me...

With that said, I believe the number of people actually using xboard for the mac must be very low. I post messages about engines that I have complied for the mac and the post might get 200 views but maybe only one person would be interested in obtaining the mac exe. It's a shame too - because Apple definitely has it over on Windows. I have compiled Senpai, Hakkapeliitta, robbolito0085g3l, Texel, Stockfish, Giraffe , Firenzina all for the Mac - let people know it was available for download - very little response.

Well, in general people would not be interested in engines that are not within 10 Elo of bleeding-edge Stockfish. And that XBoard isn't used much on Mac can always change. IMO it is just a combination of having a good product and good marketing. Obviously we still have to work on the first, and marketing a poor product is a waste of time.

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.

[hgm]

Also I know there are small group of people that enjoy all the chess variants and I respect that, but it would be nice to have a compile define for -DNO_VARIANTS.

What would you expect that to do? Just remove the "New Variant" item from the "File" menu?

Isn't that exaggerating a bit? What harm does the presence of a single meu item do? I am sure there are many other menu items that almost no one uses either. You might have compile switches -DNO_ICS to prevent there is an "ICS ..." item in the options menu, for people that are not interested to use it as a FICS client, and a switch -DNO_ENGINEPLAY to remove the Machine White/Black mode for people that never play against an engine, but only use it to analyse, or -DNO_TOURNEYS for people that are not interested in comp-comp play, etc.

I don't see the point.

[hgm]

This could be solved by adding an extra text entry 'Special tourney options' in the Tournament dialog. The text in this field could then be integrally copied into the tourney file, when the latter is created. So that an expert user could write '-noGUI' there.

This reminds me that there already exists an option -tourneyOptions, which serves a slightly different purpose: it is added to the command line at startup of an XBoard that is invoked with the 'option-less' command

xboard filename.trn

which is what the OS would generate when you double-click a file with .trn extension. With the default setting of the -tourneyOptions option this would then be interpreted by xboard as

xboard -tf filename.trn -ncp -mm -saveSettingsOnExit false

where the italicised part is supplied by -tourneyOptions. There is a similar persistent setting -viewerOptions, which is invoked on clicking a .pgn or .fen file; this one can actually be set through the UI (in the Load Options dialog). This because I could imagine that it would be a common wish to replace the -ncp mode in there by starting a favorite engine in analysis mode. For -tourneyOptions there seemed to be too few legitimate uses to make it settable through the UI; it would just offer an opportunity for noob users to permanently wreck proper operation. The -viewer options are not that critical, but if the -tourneyOptions would not set XBoard to match mode, it would really wreck things.

If by default you would want to run tourneys in -noGUI mode, you could just add this to the -tourneyOptions, i.e. run XBoard once as

xboard -tourneyOptions "-ncp -mm -saveSettingsOnExit false -noGUI"

Any XBoard launched by clicking a .trn file would then automatically run in -noGUI mode, while XBoards launched in another way (e.g. by an explicit command, clicking the XBoard icon or clicking another file type) would not use it.

This might be considered geeky, but remember that the -noGUI option was strictly intended for use by geeks only. Normal users would not be interested in doing sub-10-second games, and would not need it.

[JoshPettus]

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!

[MikeB]

Also I know there are small group of people that enjoy all the chess variants and I respect that, but it would be nice to have a compile define for -DNO_VARIANTS.

What would you expect that to do? Just remove the "New Variant" item from the "File" menu?

Isn't that exaggerating a bit? What harm does the presence of a single meu item do? I am sure there are many other menu items that almost no one uses either. You might have compile switches -DNO_ICS to prevent there is an "ICS ..." item in the options menu, for people that are not interested to use it as a FICS client, and a switch -DNO_ENGINEPLAY to remove the Machine White/Black mode for people that never play against an engine, but only use it to analyse, or -DNO_TOURNEYS for people that are not interested in comp-comp play, etc.

I don't see the point.

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. GUI is fine and I could less about the menu item to your point - did't even notice to be honest with you. The facetious defines you are pointing out in your attempt to belittle me have almost no bearing on adding additional files , piece types etc to the application. It was just a thought - don't take it personally.

[hgm]

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.

As a non-Apple user I don't know what the norm is, but I agree with Joshua that if there is a norm,it is better to stick to it.

There should be no need to edit the settings file. It is in fact a pity that the user can have access to it at all, but what can you do, things that have to persist while power is down have to be written on the disk. The settings file is intended to be a private, secret permanent storage for the program. Accessing it is tantamount to an attempt at hacking.

Given the current extent of the UI it is hard for me to imagine any legitimate reason for editing the settings file. In the comparatively rare cases that you want to change a persistent setting for which there is no control in the menu dialogs, (such as -tourneyOptions), you can just run XBoard from the command line with that option and the desired new setting, and it will automatically find its way into the settings file. For volatile options you would have to give the option each time you run anyway.

The only case where this is a bit problematic would be when you want to change a multi-line option. But there are very few of those: -firstChessProgramNames (for which the Edit Engine List menu exists, so no problems there), -themeNames, -icsTextMenu and -icsNames. The latter should come with all existing ICS names pre-configured, so there would be not much reason to ever change it. The -themeNames is such a mess that it is ill-advised to use it in any other way than through the View->Board dialog; (i.e. creating a menu item Edit Theme List would hardly make it less geeky). Perhaps I could add a button there to make it possible to delete a theme. That leaves the -icsTextMenu; reconfiguring that is also very geeky, but could be a somewhat legitimate desire for ICS users. To support it in an acceptable way would require extension of the UI; for the time being this option is there just for the benefit of the maintainer, who should pre-configure it in a way that would satisfy almost all ICS users.