Dock/Glue "Move History" window main board window?

[pstein]

Currently when I start Winboard then two windows are opened individually:

- Board window
- Move History

Can I somehow dock/glue the "Move History" window to the board window so that if I move the board window then the move history windows moves accordingly (Similarly I want to dock/glue Engine output sub window)?

Even if I set

/stickyWindows=true

in winboard.ini I can move the windows individually (under 64bit Win7)

Peter

[H.G.Muller]

With -stickyWindows=true (which is the default configuration of the install) the Move History window should move along with the board window when you move the latter, and they touch. If not, this is a bug. Which version exactly are you using?

[pstein]

v4.7.3 under 64bit Win7

Maybe Winboard does not recognize the *.ini file in its installation directory.

Can I somehow manually re-load the winboard.ini file from started WinBoard?

Or can I explicitely pass the location of the settings winboard.ini file on the command line to Winboard?

Peter

[H.G.Muller]

Well, there are several independent issues here. One is how to change things in the settings file, and the other is why the Move History window does not seem to move with the main window. Because /stickyWindows=true is the setting we use in the install, and it should never change spontaneously.

Note that the winboard.ini file in the WinBoard installation folder of the distributed binary install is NOT the one that contains your settings,and that changing anything there should in general not have any effect. It is just a file that tells WinBoard where the actual settings file is / should be created, plus that it does alter some of the default settings in case no settings file exists there yet (so only on a first-time run of a first-time install). In the distributed configuration it refers to an ini file in the user's AppData folder (the exact path name being dependent on your Windows version).

And you are right: command-line options (or 'Additional options' specified in the Startup Dialog) prevail over any stored settings, and can also be used to specify other locations for the settings file. With the option -ini mysettings.ini the file mysettings.ini in the WinBoard folder would become the place from which persistent settings are read and written. With @mysettings.ini they would only be read from there, and written on the usual settings file.

But there is no need to offer any option settings you want in a settings file. You could just specify the option you want changed, like /stickyWindows=true, and it should be obeyed (overruling whatever the setting read from the persistence file was), and saved back into the persistence file afterwards.

But I expect none of this to solve your problem, because, as I said, the binary install we distribute is already configured with /stickyWindows=true. Note that this feature always allows you to move and size the Move History window independently. This to allow you to layout the windows in the way you want. Only when you move or size the board the Move History should move with it in such a way that it preserves any touching relationship.

[pstein]

Hi H.G. Müller,

thank you for answering.

my comments see inline:

Note that the winboard.ini file in the WinBoard installation folder of the distributed binary install is NOT the one that contains your settings,and that changing anything there should in general not have any effect.

Hmm, introducing an *.ini file which has no effect?
Very curious. I have never seen such a "logic" in another software.

And you are right: command-line options (or 'Additional options' specified in the Startup Dialog) prevail over any stored settings, and can also be used to specify other locations for the settings file. With the option -ini mysettings.ini the file mysettings.ini in the WinBoard folder would become the place from which persistent settings are read and written. With @mysettings.ini they would only be read from there, and written on the usual settings file.

But there is no need to offer any option settings you want in a settings file. You could just specify the option you want changed, like /stickyWindows=true, and it should be obeyed (overruling whatever the setting read from the persistence file was), and saved back into the persistence file afterwards..

So I called the program with the cmdline parameter:

winboard.exe /stickyWindows=true

...but windows are still independent

But I expect none of this to solve your problem, because, as I said, the binary install we distribute is already configured with /stickyWindows=true. Note that this feature always allows you to move and size the Move History window independently. This to allow you to layout the windows in the way you want. Only when you move or size the board the Move History should move with it in such a way that it preserves any touching relationship.

Hmm, there is a secret option which users cannot change from ini file and not by cmdline parameter?
Thats really strange.

Could the autors make WinBoard a really piece of software according to worldwide common programming guidelines.

Peter

[H.G.Muller]

I am not sure what you mean. Are you saying that it is just that things work differently from what you expect them to, but that they actually do work as designed and documented?

[Josh Pettus]

I guess he doesn't understand the relationship between the master which only sets the defaults for the main.ini which is located in the user home folder so users can have different settings. This IS the standard.