Multiple RIDE windows results in "preferences have been modified" message box.

[JasonRivers]

Multiple RIDE windows results in "preferences have been modified" message box.

Preferences should be read only at startup and not all the time.

[jayfoad]

Andy said:

Am I the only one who’s seeing a lot of the “preferences have been modified” msgbox ?

I started 4 RIDE4 clients on Windows, using Version: 4.0.2616
Platform: Win32
Date: 2017-01-17 15:18:09 +0000
Git commit: 6f93ef9

In each I setup to connect to an interpreter to the same server, but with different port numbers. But didn’t connect to any of them.

When moving around these windows, without having connected to an APL in any of them, I keep seeing these msgboxes. Am I alone in this ?

The problem may be exacerbated by trying to connect ..

@JasonDyalog said:

What happens is RIDE reads the preferences file all the time.

IMHO, What should happen is:

Ride startup: Read preferences in to memory

Ride preferences change: Write preferences to memory AND to file.

Ride quit: Write preferences to file.

at no point when RIDE is running should it read from the preferences, Though there may be an argument to read the preferences when on the connect window to get an updated list of "saved connections".

@ngn said:

Then you risk overwriting without warning the prefs of the RIDE that was closed first.

@abrudz said:

Jason: Why write to file on quit? If we always write to file on change, there will be no change at quit time.

@ngn said:

I don't have ideas for solving this, but I can try to explain what's going on:

Connect configurations (a.k.a. "favs" - the list of items on the left-hand side of the Connect page) are part of RIDE's persistent state - they are written to prefs.json the moment you change them.

If you have two or more instances of RIDE and you change the prefs, RIDE is not smart enough to merge them, therefore it asks you, the user, if it should re-read or overwrite.

@mkromberg said:

That's OK.

The problem is the preferences which have to do with window configuration (special cased) but I think now also whether the ws explorer is visible (needs to be added to special cases). Anything that has to do with normal operation of the RIDE rather than actual configuration needs to be special-cased and only updated on exit or not warned about.

[flouc001]

@JasonRivers @mkromberg @ngn @abrudz : This "issue" came about when me and Nick tried to mimic the Notepad++ style of alerting change. Essentially these messages should only be shown when a RIDE window gains focus and the modified stamp on the preferences file has changed. We can split out some preferences to a seperate file but I feel like this would overcomplicate things. ANother solution is simply not to store some of the preferences such as whether the Workspace Explorer is opened or not. What are your thoughts on these suggestions?

[mkromberg]

I think the number of "special" preferences (essentially only related to window layout, or to put it another way, options that are not changed by going to the preferences dialogs) is quite small. How hard is it to just special-case this and say that if the ONLY changes are to these preferences, then do not notify the user.

[flouc001]

@mkromberg It shouldn't be diffficult, we will just rename the "winstate" file to something like "init_config" and put settings only read at startup in there.

[flouc001]

For now I have matched the ODE behaviour in terms of not persisting the WSE state. I think the addition of a "special case" file to hold preference variables and not just the window position/size, only read in at config, is an enhancement not an issue, therefore we should seperate that into a seperate 'issue' on GitHub. I will be committing code to help with the multiple RIDE windows.

[jayfoad]

I think the addition of a "special case" file to hold preference variables and not just the window position/size, only read in at config, is an enhancement not an issue, therefore we should seperate that into a seperate 'issue' on GitHub.

#73