Fulvio wrote:User: I want to install this engine.
Perfect GUI: done.
User: I want to change some options.
Perfect GUI: here is the list of options, change what you want
Well, that is how it works in XBoard. Except that XBoard would not even involved. So it is more like:
User (to his software management center): I want to download this engine
XBoard (when invoked later): done
It would be nice if it would also work that way in WinBoard. IMO this discussion so far entirely misses the point, by quibbling over whether the browse button to point out an engine you want to install, (after navigating through many levels of folders to get there), or whether it can share its space with a UCI checkbox. Because it is an
abomination that that browse button needs to exist
anywhere, and that any kind of user action is required to make an engine that was already installed on the machine available for use by the GUI. So
NO, what you present here as what the "Perfect GUI"should do, is in fact a silly kludge that is light-years away from perfection. A perfect GUI would just be launched by the user, and any new engines the latter had downloaded would then have been installed automagically. Like in XBoard.
Unfortunately it only works that way in an ideal world. So now let's get our feet back onto the ground, and deal with reality. To make things work "no questions asked" requires standardization. Which is reasonable in the Linux world, (which is why XBoard can do this), but totally absent under Windows. Engine binaries can be scattered over the disk in the strangest places, the engines can use many different protocols, all protocols are poorly designed in that they don't start announcing themselves, but require the user (GUI) to
guess and then probe what they are, with often disastrous consequences (crashing or hanging) when you guess wrong (e.g. send 'uci' instead of the 'usi' they expect). All
technical problems, for sure. The real world turns out to be full of technical problems, and they won't go away by merely saying that users don't like technical problems.
So at that point there is a fundamental design choice. Will you make the GUI provide as much help to the user as it can to overcome these technical problems? Or will you abandon all hope, and accept that the user is by far too stupid to overcome these problems anyway, and just axe the functionality that would pose these problems? In other words, would you send them on a survival mission into the jungle with just a plastic spoon, with which they cannot possibly hurt themselves, or would you give them a Swiss army knife, and run the risk they starve because they do not realize that you have to flip open the proper tool first before you can use it?
Perhaps it is good to state here that I absolutely abhor how common web browsers (or the OS network-managing center) do handle their option settings, hiding anything that could be remotely useful very deeply in trees of 'Advanced' settings dialogs, as if the only choice you should ever make is to tick whether you want your (non-working) connection to be made automatically or not, and on what starting page exactly you prefer to get the 404 error. Could not be worse, IMO. Secondly, I don't agree with you that the decision whether I want an engine I used to be presented to me in the future in the listbox from which I normally select my engines, or whether I'd rather forget it as soon as I can, is a
technical problem. That also holds for the (mnemonic) name I want to assign to this engine instance. Those are just regular operation of the UI to express my preferences. As to Java/Python/Nodejs and UCI/WB/USI/UCCI you are of course correct that these are technical problems from which the user should be shielded
as much as possible.
So the question is really, "how much is possible?". Note that even the reverred Shredder GUI apparently has a combobox UCI/WB that you have to operate before you can proceed (after which things go to hell if you selected WB...). Do you actually know of any GUI (except XBoard) where you don't have to specify this and it still works (reliably) for all UCI and WB engines? (Easy enough, of course, to just axe functionality for one or the other.)
Accepting the imperfection that users will have to point out the executable of engines on Windows, rather than the GUI finding them automagically, I still fail to see how anything is gained from separating the activation of the file browser from any subsequent settings. You make it sound like:
Code: Select all
User: I want to install this engine
GUI: done
User: attempt to use it
GUI: sorry, can't do. Go to 'engine settings' first
User: I want to configure this engine
GUI: shitload of questions, some of which must be answered
has anything to do with perfection. I just call it a 'lying GUI'. Because it said 'done' while in fact the majority of the task was not done at all. You just distributed the task over different dialogs, but the user will still have to answer exactly the same questions. With the added inconvenience that he would have to switch between the various dialogs. I don't think that is a step towards perfection at all. In fact I think it utterly sucks.
So the question IMO is "which info does the user has to supply often to fully complete the task (of getting the new engine running), and which info is so optional that it would almost never need to be given?". Setting an engine's non-standard UCI options (so not 'Hash' or 'UCI_Ponder', which is taken care of by the GUI) IMO would qualify for the second group. So I like those to be concentrated in one dialog which I (or any typical user) would then never have to open. Putting them in the same dialog as settings which I almost certainly (or at least often) have to provide, seems a very bad idea, because it requires me to open that dialog, and be exposed to the shitload of stuff I am almost never interested in.
So if we assume for the sake of argument that the UCI/WB question is necessary, and that I would always like to have the option of assigning a nickname to the engine, and loading an engine without contaminating my engine listbox, the most convenient place for asking for those infos IMO is with the browse button. Because that is exactly where the user is at the time he wants to provide those infos. Forcing him to go to another dialog first would definitely a big step backwards. So I am afraid no one will ever be able to convince me that it would be better to have a UCI/WB switch, or the 'nickname' field, and an 'install/just load' switch in
another dialog than with the browse button for the executable.
OTOH, I am completely open to issues like whether some of the other fields are really necessary or could be eliminated altogether wihout loss of functionality, or whether the necessary info could perhaps better be entered in another way (e.g. as a combo box rather than a set of checkboxes). Or more clearly labelled as 'Advanced' or 'Optional'. I admit that the 'Directory' text entry hardly seems useful anymore now that the directory by default is derived from the pathname in the executable field, and this
seems to work reliably. It would be nice if it could be deleted altogether.
BUT... It would unfortunately require solving of some technical problems in a different way. What if the engine is Python or JavaScript? Currently you would have to browse to the executable of the Python interpreter or Nodejs.exe. Which would be in a different directory than the .py or .js file of the engine, and probably not the directory the engine needs to run in to access its data files. So if you cannot somehow overrule the directory name derived from the path of the interpreter, you would have to put copies of Python and Nodejs.exe in the engine directory to make it work, which is awful. This apart from the problem that the interpreter might need arguments other than just the engine source, and that in Windows these would often contain slashes, which could greatly confuse the derivation of the directory part from the pathname in the full engine command, probably making it very unreliable...
What you would like is that the user is shielded from these complications, and can simply browse to the engine .py or .js file. Like is already possible for .jar files, as 'Java' is usually installed in such a way that it is recognized as a standard command. Unfortunately that doesn't seem to be the case for Python (and Nodejs?). So it would be a necessaty to have the user also browse for the interpreter. This could of course be done by providing a separate browsable text entry for interpreters instead of the directory field, which would normally be greyed out, but would get activated as soon as a .js or a .py file appears in the text entry for the engine executable. So real life is not that easy...
