Share configuration among instances / Instant save

[ceravis]

This will probably be unpopular, but I'd like to (humbly ) request:

(A) an option to share common configuration data among several windows/instances, so that any changes made in one window's configuration are quickly caught and parsed in any other running instances (most likely to the registry for speed reasons),

or at least

(B) an option to automagically commit any setting when it is changed, rather than having to manually save the configuration in the File menu or having the option checked to save all settings upon exit (the current alternatives as I understand).

I understand that the tabbed interface is integral to XYplorer, and many users may stick to just a single window/instance; but I tend to work with quite a few open windows, each with multiple tabs, as a way of grouping my in-progress tasks by subject - and I work in much the same way with multiple tabbed windows in Firefox, Chrome, IE, and other tabbed apps, which is a huge aid to my productivity.

The problem is this: when I make changes in any one XY window's configuration, say something inconspicuous that isn't immediately apparent, then later I finish my session and close my several open XY windows, I have to make sure that the last window I close is the one in which I made the config changes, otherwise they will be overwritten by the older, unchanged config from one of the other windows. I understand that I could disable auto-saving the config at exit and just save the changes manually whenever I make them, but even if I assign a custom keyboard shortcut (such as Ctrl-Shift-S) to the "Save all settings" command, it's arduous and redundant to have to hit Ctrl-Shift-S everytime I change any settings, after I've already hit OK in whatever dialog box I was in. Plus, these changes won't take effect in any other open windows until I close and reopen them.

I understand that option (A) likely breaks some basic assumptions hard-coded in XYplorer, and would probably require a fair amount of coding, since I can only imagine it would be feasible (performance-wise) if the configuration were stored in the registry rather than an INI file, and would require some sort of inter-process communication among instances and/or monitoring registry keys for changes. Or possibly the multiple windows could be spawned by the same parent process, much the same way that multiple tabs are currently managed within the same process...? This alternative might even help to minimize resource usage with multiple windows (although it's already quite good), the only downside being that if one window hangs/crashes, they all go down with the ship.

I'm open to suggestions if anyone knows of a better way currently to "set it and forget it" when changing settings in XY with multiple windows active, without having to worry about which window the changes were made in or which should be exited last. I would think some sort of clever script might even solve the problem, but something as simple as a timed "save all settings every N minutes" script wouldn't avoid conflicts between multiple windows, as one window's older configuration could potentially overwrite another window's newer/different settings.

Thanks much if you've taken the time to read all this - I appreciate any feedback!

[SkyFrontier]

I see much sense asking this as we currently have to open a second instance to workaround freezing during copy on Vista 32-bit, not having a second tree to securely deal with heavy file operations despite losing the "copy/move/backup to other pane" functions and temporary non-responsive freezes on network drives.

I'm an eager fan of elegant, simple and global solutions that solves several problems in a row and it seems to me that this is one of them, so my vote is YES.

(You voted NO, Ceravis? lol)

[admin]

This will probably be unpopular, but I'd like to (humbly ) request:

(A) an option to share common configuration data among several windows/instances, so that any changes made in one window's configuration are quickly caught and parsed in any other running instances (most likely to the registry for speed reasons),

or at least

(B) an option to automagically commit any setting when it is changed, rather than having to manually save the configuration in the File menu or having the option checked to save all settings upon exit (the current alternatives as I understand).

I understand that the tabbed interface is integral to XYplorer, and many users may stick to just a single window/instance; but I tend to work with quite a few open windows, each with multiple tabs, as a way of grouping my in-progress tasks by subject - and I work in much the same way with multiple tabbed windows in Firefox, Chrome, IE, and other tabbed apps, which is a huge aid to my productivity.

The problem is this: when I make changes in any one XY window's configuration, say something inconspicuous that isn't immediately apparent, then later I finish my session and close my several open XY windows, I have to make sure that the last window I close is the one in which I made the config changes, otherwise they will be overwritten by the older, unchanged config from one of the other windows. I understand that I could disable auto-saving the config at exit and just save the changes manually whenever I make them, but even if I assign a custom keyboard shortcut (such as Ctrl-Shift-S) to the "Save all settings" command, it's arduous and redundant to have to hit Ctrl-Shift-S everytime I change any settings, after I've already hit OK in whatever dialog box I was in. Plus, these changes won't take effect in any other open windows until I close and reopen them.

I understand that option (A) likely breaks some basic assumptions hard-coded in XYplorer, and would probably require a fair amount of coding, since I can only imagine it would be feasible (performance-wise) if the configuration were stored in the registry rather than an INI file, and would require some sort of inter-process communication among instances and/or monitoring registry keys for changes. Or possibly the multiple windows could be spawned by the same parent process, much the same way that multiple tabs are currently managed within the same process...? This alternative might even help to minimize resource usage with multiple windows (although it's already quite good), the only downside being that if one window hangs/crashes, they all go down with the ship.

I'm open to suggestions if anyone knows of a better way currently to "set it and forget it" when changing settings in XY with multiple windows active, without having to worry about which window the changes were made in or which should be exited last. I would think some sort of clever script might even solve the problem, but something as simple as a timed "save all settings every N minutes" script wouldn't avoid conflicts between multiple windows, as one window's older configuration could potentially overwrite another window's newer/different settings.

Thanks much if you've taken the time to read all this - I appreciate any feedback!

Well, this is so IMPOSSIBLE...

But what I maybe could do is simply, right before committing a config save, check the modified date of the config files and compare it to the date when this instance last saved to that files. If the former is later than the latter then some other instance has saved, and I could pop a prompt...

[j_c_hallgren]

ceravis, I'm just curious if all but one XY were locked from saving config, would/could that work as one concept or solution? So that you'd only make any config chgs in that one session...I'm thinking more of a startup switch or similar that would say "this setup can't save config"...this would be in addition to Don's idea but his would allow you other flexability.

Another idea i had would be a set of sub-configs whereby each would get a partial set with the instance nbr as part of the scheme...things that might be more closely related to the other sessions, like tab data and such...would need a tiny control file with the active sessions plus curr max count with the first instance being #0,,,when you start a 2nd XY, it would get set #1 and so on...if you had 4 XY's (#0-3) and closed 2nd, you might have a setting like "Active=YNYY" and "Max=3"...you'd only keep this file open while updating it so it could be updated by other sessions as needed.

Using this, then you could have ability to lock some settings to only being saveable by the master session #0 but still be able to save data for each...so in addition to pane.ini and tab_x.ini, you would have 1pane.ini & 1tab_x.ini and such.

Just some ideas to ponder...

[ceravis]

Thanks for the quick replies!

SkyFrontier: those are certainly among my reasons for using multiple instances - XY isn't alone among programs which can get hung up waiting for outside processes/resources to continue working, and it can be a huge productivity boon to multitask. Also, I wasn't aware I had voted at all, but I just voted "Yes" to add my 2 cents .

admin: It's been years since I've done any Windows programming, but I was mentally toying with the mechanics of implementing this and I can imagine there would need to be a number of fundamental changes/additions, judging by how XY seems to work at the moment. But I've never been mistaken for a C++ guru, so I guess I was wishing that there was a clever way (beyond my level of understanding) to hack this in somewhat easily. But make no mistake, I can appreciate the amount of work you've put into (and continue to put into) making XY as good as it is, and I don't expect a herculean effort for one user's wish...

j_c_hallegren: Good ideas - locking down all but one instance would at least prevent the user from accidentally saving over newer changes. But (at least as I picture it) multiple "sub-configs" wouldn't necessarily solve the biggest problem I'm facing: namely, sharing configuration changes among instances. For example, as the need arises, I'd like to be able to make changes in whatever instance I happen to be working in (say, for example, highlighting a specific folder, or changing the font size), and have that same change immediately take effect in any other running instance. Sometimes these are superficial changes I can live without until the next time I close and reopen XY, but sometimes they're subtle functionality changes (such as those in the General and Advanced pages of the configuration window) that frustrate and confuse when switching from one instance to another only to find the option enabled in one instance and disabled in the other.


How about this as a (relatively speaking) simpler fix:

An option for "Single-config mode" (or "Prevent config conflicts" or something more self-explanatory) under Allow Multiple Instances in the Startup/Exit settings: This might (for example) cause all open XY instances to watch the current INI file for changes (maybe just something simple like the timestamp), and if/when it changes, automatically reload the configuration file (or optionally popup a prompt) such as some text editors can do when an open file is changed in another program. Even have this check only occur when an XY instance receives focus to prevent unnecessary checking/overhead.

Maybe even just before relaunching the instance, save a quick little temp file in the config folder with a unique name (e.g. "<ProcessID>.instance") listing any open locations/tabs/searches/etc, that can be called by the newly spawned process as you're reloading the config, so that it will reload the previous "state" so you can pretty much pick up where you left off. This temp file can then be immediately deleted.

Of course this will discard any unsaved settings in the previous instance, but if this sequence of events takes place each time you save the settings in any given instance, all changes will be saved, and conflicts should be avoided completely (at least as I imagine it). Then just combine this with an option to automatically commit any changes to the INI file in real time, and I'd be a happy camper .