I don't really work with XBoard. I am a Windows user, and I use WinBoard. I am not sure how copy-paste works in X-applications. It seems what is selected is automatically ready for copying to other X-applications by a middle mouse click. But it seems that modern Linux tools no longer obey this convention. (Plus, I work on a laptop, which does not even have a middle mouse button...) This gave us much trouble with XBoard before. For instance, I was not able to paste games or positions that were copied by the XBoard menu's copy commands into Gedit or FireFox. We changed that by now letting these commands by default copy to the clipboard, in stead of setting the primary selection, and added the option -pasteSelection for forcing the old behavior. Late I implemented this for the Engine-Output window as well. But this has to be programmed explicitly everywhere you want it to apply, it is not natural X-server behavior. So I can very well imagine that mere texts in dialog boxes can only be copied in obsolete X-ways, if copying of those was supported at all.BBauer wrote:Thank you.
Now I can view and analyse the linares games.
Multipv behavior has not changed.
From "about Xboard" I wanted to copy the version but that is not possible.
Cut and paste seams not to work for me.
How do you work with xboard?
This is all a consequence of XBoard being based on the outdated Athena widget set of the X-toolkit, which might have been state of the art in 1974, but have lost much of its glamour by now. It can only be expected to improve when the Linux front-end will be entirely rewritten, porting it to a modern widget set. Arun Persaud is currently working on this, porting XBoard to the gtk+ widget set. This makes it even more unattractive to invest a lot of effort in patching up the X-toolkit front-end.
About the multi-PV behavior: I don't know which XBoard version you were using before, but the multi-PV behavior of the version patched for the "super problem" will be changed compared to that of 4.4.2. It sorts the lines of a single depth in such a way that the one with the highest score it top-most in the display. As the natural display order is to insert lines at the top, this is often the reverse order as they would appear in 4.4.2, because engines often send the line with the highest score first. (E.g. look at the Polyglot output posted by Michel.)
Of course this does not solve your main problem. I already told you that was a Polyglot issue, and it will persist as long as you keep using versions older than 1.4.50b or thereabout. I am sure 1.4.56b does it the way you want. (Which, btw, I consider the correct way for WinBoard engines. But tastes differ, and some people prefer the display to be cleared between iterations. Perhaps future Polyglots will allow you to select the behvior through a Polyglot option, so it can be set from the XBoard menus.
As you can see from the console output you posted, Polyglot 1.4w18 still inserts extra lines starting with 0 to clear the display, and sends many copies of the same line (e.g. Nf3 Nf6 Nc3 at d=3 is sent 4 times). You can see it does not even limit that to new depth, but it does it even within a single depth: for any new line the engine coughts up, it first clears the display, and then resends all the lines that it just erased. That is what was causing this neurotic dsplay behavior, but it was all intentional by the designers of Polyglot. And there still seem to be people tht prefer it that way. I guess there is no accounting for tastes.