Possibly odd XBoard quirk: Engine Directory default is dot

[elliechess]

Playing around with engine logos I realized at some point if I just open up "Load New 1st/2nd Engine" and slap in a path to a new binary, the logos usually won't show up in XBoard. I looked at the dialog a bit closer, what I usually did was to specify the "Engine Command" and nothing else, and with the note "(Directory will be derived from engine path when empty)" it does also superficially seem like that should pick up the binary's folder automatically where the logo is.

However, then I noticed: Engine Directory appears to default to ".", not to empty. I didn't even see it at first, because the dot is so easy to miss:


And indeed, when I go and remove that dot in addition to specifying the binary it works and the logo is picked up.

Now I'm wondering though, isn't an engine added through this dialog most likely to require the binary's directory as engine dir for its logo, opening book files, and others? Wouldn't that make an empty value for Engine Directory, to default to binary location, a more intuitive default than "."?

Edit: if "." turns out to be an important unchangeable default for some reason, what if WinBoard/XBoard could also check the binary's directory (in cases where that is known) for the logo.bmp/logo.png? That would help with the logo not being unexpectedly missing when a user misses the importance of that small dot

[H.G.Muller]

Engine binaries on Linux typically reside in /usr/games/ or /usr/local/bin/ (depending on whether you installed from the distro's repositories, or installed from source). There would be nothing else in those folders that relates to the engine: if an engine needs data files (like an opening book) it would be in /usr/(local/)share/games/<engine name>/, and their logo would be /usr/(local/)share/games/plugins/logos/<engine name>.png , and their binaries would know that without being dependent on the notion of 'current directory'. Also, the user would normally not have permission to write / create files in any of the mentioned directories, so that when the engine would want to create a log file (as some engines do), or support a 'persistent hash table', they would have to do it in the user's home directory, or a sub-directory thereof. Using the current directory for this seems to provide more flexibility for the user than to use a fixed location in his personal file tree.

Note that the -autoLogo option in XBoard does not work the same way as it does on WinBoard: XBoard would first look in the folder specified by the -logoDir option for <engine name>.pgn, then in the engine directory for logo.png, then in /usr/local/share/games/plugins/logos, and finally in /usr/share/games/plugins/logos, again for <engine name>.png . And use what it finds first.

[elliechess]

Thanks for the response! And that makes sense, I get the writing to directory thing so that makes sense for engine directory (and after all an engine could work around this and locate itself on disk and check for files there if it really wanted).

But might it be feasible to automatically check in the binary folder in addition if no logo was found in the engine directory? Because smaller engines on Linux often come as direct download rather the way you describe, so this would make the logos work for these cases too - this is also the scenario where the logos didn't work for me. It would just be cool if it worked in such a case without manually specifying an additional directory which I suppose almost no user will think of. (it took me a while to find out that was the culprit even) And since /usr/local/bin and similar wouldn't usually ever contain image files i think the false positive risk of something wrong loaded up as logo would be pretty low.

[H.G.Muller]

It would of course be possible. But it would serve no other purpose than facilitating non-compliant install of engines, and thus aiding and abetting those who create chaos. I consider such things immoral.

Note that compliantly installed engines would never need the -fd or -sd engine-directory specifications. That it would be needed to derive a directory from the path to the executable is already a sure sign that non-compliancy is being committed. So automating this derivation in case of an empty engine-directory text entry is already a concession to evil that I should perhaps not have made. But as it is the only penalty for the non-compliant installation of the engine is that one has to delete the dot, which doesn't seem too harsh. One could actually argue that it is not nearly harsh enough!

The recommended solution would be to place the logo file where it belongs: /usr/local/share/plugins/logos/ENGINENAME.png . If it doesn't automatically go there on unzipping the engine, you should complain to the engine packager.

[elliechess]

Oh, interesting! Your response seems very true for the "big" engines, but what about the more obscure ones? Less common or close-source engines usually can't provide a universal deb+rpm+AUR+... for all distros, so these often can't be nicely installed other than with manual messing with /usr/share so it's often best to just run these engines directly from the download folder and just not to install them. And that's the usage scenario where I think this would be useful, since with the current situation people might be encouraged to manually butcher /usr/share just to enable the logo for these engines.

[H.G.Muller]

Not sure where the 'butchering' comes in. Manually placing a file in /usr/local/share/games/plugins/logos seems perfectly fine. And you would not really need an official package for the distro to get things right for something as simple as a chess engine. You can use a simple (compressed) archive; for Linux .tar.gz is the most commonly used format. As long as you put the various files that should be included in their proper place before putting them in the archive. E.g. the packager could use the command

tar -cvvf ENGINE.tar /usr/local/bin/ENGINE /usr/local/share/games/plugins/logos/ENGINE.png /usr/local/share/games/ENGINE/book.dat

to package the binary, logo and book, and distribute that. Unpacking the archive then would automatically put the files in the required location. If the engine author doesn't do that, you should complain about it. To him, not to the GUI developer! Or put up with it, and move the stuff by hand. Or you can just delete the dot from the engine directory field in the Load Engine dialog, and hope that the logo was in a file called logo.png.

It is of course already miserable that you have to type anything at all in the Load Engine dialog. If the engine was packaged in a truly compliant way it would also have included a file /usr/local/share/games/plugins/xboard/ENGINE.eng, which XBoard would have detected automatically as soon as it was started, and would have led to incusion of the engine in the engine list, so that you could have simply double-clicked it from the listbox in the Load Engine dialog without providing any info.

[elliechess]

I honestly would never extract a tar that changed /usr/share/ or any other root-owned paths even if it came like that. Distro paths differ too much, who knows if my xboard isn't packaged differently? And if it's not done with the repo package manager, who will clean it up? Not me, I won't remember in months what is safe to delete because I may have put it there. I just personally see it as an idea with lots of downsides, and I would neither recommend anyone to make such an archive nor ever apply it myself, and instead just extract it in my download folder. So I suppose we just see this very differently then, and I still wish xboard was more flexible here for multiple approaches. However, I do somewhat understand you prefer to stick to principles even when a random user like me disagrees.

It is of course already miserable that you have to type anything at all in the Load Engine dialog. If the engine was packaged in a truly compliant way it would also have included a file /usr/local/share/games/plugins/xboard/ENGINE.eng, which XBoard would have detected automatically

I agree, that does seem ideal combined with it arriving in .deb/.rpm form so it properly installs AND uninstalls later. But with my engine I likely won't do that since distros are just too diverse and sadly there is no way to do it that guarantees it will work even on just most of them. (And what if the user uses Arena for Linux, or one of the many other chess GUIs anyway? Such specific changes just don't scale very well.) But it's great that it works for the big, officially packaged engines like that, it's certainly a neat approach for these cases!

[H.G.Muller]

do you actually know any Linux distros that do not have a /usr/bin or a usr/share? Currently the paths where XBoard would look for logos or .eng are hard-coded (as /usr(/local)/share/games/plugins/...), rather than configurable, because I never encountered a case where those paths would cause trouble.

Note that on most distros /usr/local/* would never be used by the distro package manager, and exists solely for stuf the user wants to install from other sources. Packages from the distro repository go in /usr/* (without the 'local'), and they are the only things that go there. It seems a bit strange that you would not want to use a feature for exactly the purpose for which it was designed.

BTW, the most common and universal way to install non-distro software on Linux is to do it from source, through the "./configure; make; sudo make install" mantra. If you include a Makefile (or set it up so that ./configure can create one, although for simple text-based programs like engines that usually is not necessary), you can also include an 'uninstall' target for cleaning up. This is what I do e.g. for Fairy-Max. Even if you want the engine to be closed source you could pack its binary with a Makefile for install / uninstall, and builing of auxiliary files such as man pages. In most cases distro packages are just automated ways of performing the make-(un)install of the Makefile of the software they package, where the distro maintainers did the ./configure and the make.

Arena and other GUIs should be able to automatically register installed UCI and CECP engines based on the .eng files they post to announce their presence. If it doesn't, that just means it sucks. Complain against the Arena developers...

[elliechess]

BTW, the most common and universal way to install non-distro software on Linux is to do it from source, through the "./configure; make; sudo make install" mantra

I'm aware, but yet another way I almost never use and almost never recommend personally because some packages don't have a working uninstall target, or break with distro-specific path changes. It's a bit like installer vs portable version on Windows: I sometimes prefer the portable version as well because installers don't necessarily work right, although on Windows that's more rare since it's more uniform. (and I would always get the portable version of a chess engine vs an installable one on Windows too since they tend to be small and have few dependencies anyway.) But it's ok, I guess to each their own.

And if you don't want to adjust XBoard just for my personal antics, I do totally understand but I hope I at least made a convincing case that some users might have a use for such a logo detection change, even if you would probably not and might disapprove. It was certainly interesting to hear your side of things, if anything!

do you actually know any Linux distros that do not have a /usr/bin or a usr/share? Currently the paths where XBoard would look for logos or .eng are hard-coded (as /usr(/local)/share/games/plugins/...), rather than configurable, because I never encountered a case where those paths would cause trouble.

The thing is, I believe you since you work on XBoard and would have had user complaints if they didn't work. But I wouldn't have known without asking you, which is why I usually stay away from such possibly distro-specific system-wide paths. Almost all of them have /usr/share of course, but maybe some would use different subfolders in there for some software, who knows? I've seen weird differences with this and tend to avoid doing things as root that aren't really necessary, so cautiousness just makes more sense to me personally.

In my opinion installing anything system-wide that wasn't provided by the distro just isn't particularly well-designed, after all some write .deb/.rpm and more packages in like 4+ different variants (I have seen that for pychess for example) just to get it to work and it still might not. So that is why I tend to stay away from it, most things are just packaged by my distribution after all or don't need an install to work.

[H.G.Muller]

The Windows philosophy is very different from the Linux philosophy, as far as file-system organization is concerned. There it is indeed common to put all files belonging to a certain piece of software in the same folder.

But I think the Windows / portable way of engine install is sufficiently supported by XBoard through looking for a logo.png in the engine directory, and that it is already very easy to make XBoard aware of the path of the latter: just delete the dot after browsing for the engine binary. (Or explicitly browse for the directory.) I don't think it is very useful to try to also require XBoard to be able to find the logo when the user specifies a wrong engine directory; a 'portably installed' engine will likely also need other files from its directory (book or config file), so it will not work as intended if a wrong directory is specified. Making the logo display in that case would just confuse the user into thinking he registered the engine properly. It would do more harm than good.

I still recommend to place engines distributed as lone binaries in /usr/local/bin; the 'messing up' or 'uninstall problem' seem rather non-sensical in that case; just remove the binary that you put there yourself and you are done. I would also recommend to put logos in /usr/local/share/games/plugins/logos/ENGINE.png, but if you don't want that, there always is the alternative of configuring XBoard by running with a -logoDir option once, to specify say ~/.plugins/logos as directory in your own home tree where it must look for logos, and put the logo there.

[elliechess]

I don't think it is very useful to try to also require XBoard to be able to find the logo when the user specifies a wrong engine directory

I would agree if it weren't for the unusual, not really portable friendly engine directory default. This is why I still think this change would be an improvement for the cases for sure. It's just this unfortunate combination of the unusual default, easy to miss visual indication of that, and the engine usually working fine but the logo being mysteriously missing as a result.

I find this point interesting however: `Making the logo display in that case would just confuse the user into thinking he registered the engine properly. It would do more harm than good.` I reluctantly agree, but I guess that might indicate the default itself might be a bit problematic after all...? Hm.

Just a weird idea: what if XBoard detected if the specified engine path is inside either a $PATH directory or any directory not a sub path of $HOME, and then defaults the default engine directory to "." in that case only, but otherwise picks where the binary is at? The visual name for that could simply be called/specified as "automatic" in the field where to enter the directory. I realize this is brittle and complex enough to confuse people for further reasons, but then again "automatic" would IMHO also make it pretty obvious the guess can be wrong and anyone who cares about that would need to specify it manually anyway. And it would probably work for >99% of cases just fine, more so than the current default.

I still recommend to place engines distributed as lone binaries in /usr/local/bin;

That really is fair enough, and I also get the /usr/share recommendation! I wouldn't necessarily recommend it myself, but I can definitely see where you are coming from.

[H.G.Muller]

The real problem seems to be that you did not notice the directory field was not empty by default. Otherwise you would probably have just erased it, never giving the matter a second thought. It is a somewhat unfortunate coincidence that 'current directory' is indicated by the least-conspicuous non-empty string that exists.

This could be cured by making the default for the directory field "<current directory>", and modify a name that exactly matches that on processing the input into ".".

[elliechess]

The real problem seems to be that you did not notice the directory field was not empty by default. Otherwise you would probably have just erased it, never giving the matter a second thought. It is a somewhat unfortunate coincidence that 'current directory' is indicated by the least-conspicuous non-empty string that exists.

Yup, half of it at least! But I only noticed this was relevant after reading the small text which says it defaults to the binary directory when empty / when I started investigating why the logo didn't show up. So it'd still not have been the IMHO ideal experience of just picking the engine binary and it works(TM), but it would have saved me a lot of troubleshooting time once I realized something was wrong for sure.

[H.G.Muller]

I consider that good: you must not have an ideal experience when you try to do things the wrong way. Non-compliant behavior should be met with some form of discouragement, or people would never mend their evil ways. That you happen to be a hard-core offender doesn't mean everyone is; there will be plenty of people that do things wrong out of ignorance.

[elliechess]

I honestly really disagree with seeing this as the "wrong" approach, for all the reasons stated above. I don't think /usr/share is wrong either, I think both have their merits and I think it's a bit sad they aren't regarded as legit choices by you. This is obviously just my opinion but I don't think I'm fully alone with this either: portable binary usage on Linux is less common than on Windows as you already stated, but it's not unheard of.

[H.G.Muller]

I think I have a good reason for considering it a wrong approach: non-compliant engine installs wreck the auto-registration process of engines with GUIs. It should not be necessary to enter anything at all in XBoard's Load Engine dialog; one should be able to select the engine from the listbox (or similar controls in other GUIs) as soon as it is installed. The portable install fails to do that.

You complain that you have to clear the engine-directory entry. But the thing really worth complaining about is that you had to use the browse button and locate the engine binary with the file-selector dialog. That is at least 10 times as much work. And then, when you want to use the engine in another GUI, you would have to do it again there!

[elliechess]

Isn't it a common expectation that a portable install doesn't affect other software with its presence unless the user somehow manually puts things together? (To allow both moving it around without side effects, and multiple independent portable installs in parallel without side effects. I'm aware moving doesn't work with chess engines once added to XBoard, but since adding is a manual user action that isn't unexpected then.) So I don't fully follow the reasoning.

But the thing really worth complaining about is that you had to use the browse button and locate the engine binary with the file-selector dialog. That is at least 10 times as much work.

Yes, but IMHO it's inherent to a portable install due to expected no side effects, with all the advantages and disadvantages. However, that logo and possibly more don't work after manual adding if I don't change a less obvious extra field really isn't so expected, IMHO, and changing it wouldn't break any of the basic expectations of a portable install.

[H.G.Muller]

That seems just a way of explaining why portable install is not really suitable for an engine. It can be nice for an independent software package, that doesn't interact with anything. If you have a memory stick that contains XBoard, some engines, its settings file with en engine list referring to those engines... That would be a nice thing to have on a memory stick, so that you could just plug it in anywhere, and play.

An lone engine, however, must heavily interact with the GUIs on the machine. All that interaction is broken by the portability. And the consequence is that you have to repair it by hand, doing the registration and pointing each GUI to logos through the menu dialog. That should be the common expectation for a portably installed engine.

[elliechess]

All that interaction is broken by the portability. And the consequence is that you have to repair it by hand, doing the registration and pointing each GUI to logos through the menu dialog. That should be the common expectation for a portably installed engine.

Yes, it is common expectation manually adding it in is required. But to me it seems a little like you conclude that is why specifying the engine can not be improved, even if the dialog were to be more confusing right now than it would need to be (which I think it is). That seems like a weird argument to me.

IMHO it is not completely obvious the engine directory is tied to logos not working apart from it being clumsy to need to correct it separately, and it's IMHO not super obvious either Current Directory (or a dot) isn't the engine's binary location: a normal user might not know current directory is a programmer term rather than e.g. the "current directory where the engine is in." As a result, for the case of portable engines the dialog is just a bit confusing and clumsy. I think a decent improvement would be to change it such that Engine Directory defaults to something that works for more cases, and that could be possibly done with an (automatic) default that behaves differently for likely portable paths the way I suggested above.

We're going in circles though and I feel like I said all this already, so I'll bow out here. Thanks for the responses, it was an interesting exchange for sure.