Save settings to folder (instead of registry)?

[nyanpasu64]

Is it possible to save Start Menu and Explorer settings to a folder, which I can symlink to a cloud drive to sync between computers?

Right now XML export/import is supported, but it must be manually triggered.

[coddec]

Probably combine This http://www.classicshell.net/forum/viewtopic.php?f=7&t=4457 And task scheduler？

[ahtotaat]

It would be nice if all settings could be in either some folder or SQLite file database, instead of registry. It would allow putting Classic Shell into .WIM files more easily. It would allow us "hand craft" Windows installation images with Classic Shell already pre-installed.

.CAB file package for DISM utility would be even more awesome..

[coddec]

The idea is great, though I think we might need more contributors either to help or join the team. Currently we are more on maintenance side (refer to > If it ain't broke, don't fix it)

Anyway, feature requests are free to open, it might help to lead the roadmap for future development. 😃

[twocows]

Handling settings in the registry is the correct and most reliable way of doing things, so I think the registry should continue to be where settings are read from and written to. That said, the requested functionality can probably be implemented while still properly making use of the registry.

I recommend having an off-by-default option to automatically load settings from an external file into the registry on application launch. This setting would also automatically dump any settings changes made by the user to that same file after making them in the registry. Here's the flow I would recommend:

• on launch, check registry to see if this setting is enabled
• if it is, check that the external settings file exists
• if it does, determine whether we have read from the same unchanged file before
• if we have not, validate the file
• if it's valid, commit the changes to the registry
• when the user changes application settings, rename the old file to -backup or something, dump the settings to a new file with the original name, then when finished write a value to the file that states that the file was fully written to (e.g., the application or system didn't crash in the middle of writing to it)
• since users tend to make a lot of changes at once, maybe it might be best to keep the original -backup around for a while so it doesn't get overwritten immediately by the user making several different changes at once. possibly leave it around until next application launch or for an hour or two of realtime or something.

That seems like a pretty safe way of doing it, and at any given time the application is still getting its settings from the registry, which is a more reliable way of getting settings than reading directly from a file.

On a related note, I can't see a reason not to have an on-by-default option to, on first run or any time settings change, automatically dump new settings to a menu-settings-backup.xml file and back up previous settings by way of renaming any existing menu-settings-backup.xml to menu-settings-backup.old (overwrite existing menu-settings-backup.old, though there'd need to be a latency period as described earlier because users tend to make multiple changes at once). That gives the user a backup of their current settings in case the operating system becomes unusable and a backup of their old settings in case they screw up their configuration really bad, and it takes up almost no room. The code is already in place to allow exporting to or importing from such a file on request, someone would just need to implement the logic to do it automatically in a sensible way. The naming for these files needs to be done in a way where it's obvious to the user that changes made in these files will not change anything in the application; they're just backups.

Also, for both security and usability reasons, some relatively strict sanity checking should happen any time settings are imported from a file of any kind, even from automatic settings backups produced by the application. These kinds of files can get corrupted pretty easily, unlike the registry. Moreover, failing to validate external input opens up the application to being a vector of attack for someone trying to compromise the system. Probably unlikely, but still best practice to make sure what we're reading in isn't garbage.

[Nodens-]

@twocows

Sorry but that is convoluted and just bad design. You either R/W configuration to the registry or to a file.

If you want to support cloud style configuration syncing and/or network mapped you have to effectively switch configuration to file. This is how it is done everywhere in the industry for many reasons: a) Configuration changes have to be written and read in real-time. Reading once on start doesn't work. Some systems have uptimes of weeks and even months. Configurations changes should propagate on change. b) There is no valid technical reason for the extra overhead of registry I/O when using a file (ini/XML/sqlite). c) There is no valid technical reason for the increased complexity and extra points of failure.

All that needs to be done for this is: a) A configuration option that switches from registry to file. b) Configuration file location option. c) Implementation of read/write functions for chosen file format. d) Write locking the file properly during configuration writes (with everything that entails). e) Copying current configuration file to .bak when configuration is written. f) Automatically revert to reading configuration from registry if configuration file is corrupted.

Also regarding the use of the registry for configuration in general it used to be the general guideline on the Windows platform but in this age of networking and cloud computing the majority of software is moving away from this practice for years now. The current best practice is to utilize the registry for system specific configuration options only (eg local installation path etc). Anything that could be considered roaming should be stored outside unless the software has networking functionality/APIs built in for syncing etc. But even in this case most projects avoid it as it's extra complexity for no valid benefit.

[twocows]

Makes sense to me. I guess I was trying overly hard to come up with a solution that involved keeping things within the registry.

[B00ze64]

You can already export all the settings to an xml file and import them at will; if you want to sync your preferences to a few machines in your home this will do just fine. If you want to seed the settings in an image or a MSI installer you can easily export the registry keys and import them on install, or load them into the hive inside the image. For me at least, this isn't the kind of program where I constantly change the settings and need to propagate them; once I'm happy with it I don't touch it. Maybe what you need is just some command-line options to load the xml settings? That should be sufficient to distribute the settings to thousands of machines via a script in SCCM. There should be some way to initialize the settings from file when a new user logs onto the machine where ClassicShell is already installed, but for me at least, I don't run ClassicShell from a USB key everywhere I go so I do not need a ini file...

[nyanpasu64]

For me at least, this isn't the kind of program where I constantly change the settings and need to propagate them; once I'm happy with it I don't touch it.

I use the Classic Shell toolbar quite a lot, and customize it on a non-negligible basis. Sync would make switching between computers more painless (XML is also possible but extra work before/after switching, and could go out of sync if I have 2 PCs).

[XenHat]

Once we have a sound, sturdy and back-and-forward compatible design for settings import and export, I will look into integration with OneDrive, Dropbox, and other free APIs, as well as arbitrary folder "sync".

This should give plenty of flexibility should the user wish to use a sync service I do not know about (or wishes to rely on the OS apps instead of the API to do so (i.e. point to %USERPROFILE%\Dropbox or %USERPROFILE%\OneDrive), or does not want to sync at all.

[yereverluvinunclebert]

Import and export to/from the registry is the way to do it.

[Ibuprophen]

Not everyone knows where exactly to look for and export registry entries...

~Ibuprophen

[rmenessec]

For the moment—do either NC-UI or Classic Shell have a method to export settings from the command line, or do settings always have to be exported manually, via the GUI?

[Ibuprophen]

I had created 3 batch files that I'm not done testing out yet...

1) Exports the registry entries for the Classic Shell and Classic Start.

2) Converts the xml export from the Classic Shell for importing in the Classic Start.

3) Converts the registry entries from the Classic Shell to the Classic Start.

There's still more work I've got to do as well...

This is just a general FYI. :-)

@rmenessec, the xml export option for Classic Shell doesn't backup the registry entries and, when the xml is restored, i would estimate that it restores approximately 70-75% +/- of your last configuration.

~Ibuprophen

[rmenessec]

@ibuprophen1: Oof. I guess I'll wait for your solution or an official one, then. Thanks for the heads-up.

[Ibuprophen]

@rmenessec, I'm not an official member of the development team for this Classic Start (now the Classic Neo) software.

So what I come up with is solely for the developers here to QC (QC = Quality Check) and leave it to the pros to determine whether to provide them, hopefully, implemented in the software or as a separate "Migration" release for those going from its predecessor (Classic Shell) to this development.

I personally do what I can to help the development team when I can to make this transition the best Start Menu Software available to those who really want/need it.

I've just hammered out 3 App Updates (that I've developed) and spent approximately 3 weeks working on after taking a 30-45 day break for developments

I even have a few unreleased application/misc projects I've finished approximately 6-8 months ago. LMAO!

This Start Menu has helped rekindle my Microsoft knowledge that I've held Certifications in as well as being a former certified Microsoft OEM System Builder.

I'm jabbing to much but, I wouldn't feel right to provide something without the Development Team looking at it first as a "Professional Courtesy" to them.

When I've completed them, I'll announce that it was provided to the Development Team for review and leave it up to them.

I even thought of a way where 2 of the 3 batch files shouldn't be needed since I believe that I've found a way to implement them via a Github review for a merge. I'm surprised that they didn't notice what i saw previously. LMAO!

Let's all gather around and sing a verse from that song "Abraham, Martin and John"... 😱

~Ibuprophen

[XenHat]

This is my fault, really. I should have implemented export/export or at least reading from the old registry keys but i didn't really have the time when i did the rename, and I underestimated the amount of users who would switch to this code base this early. Again, my deepest apologies. I will look into cooking something up soon enough (I have plans tomorrow and a lot is happening IRL)

I still maintain my goal mentioned in https://github.com/NeoClassic-UI/Menu/issues/9#issuecomment-404910711

Edit: @ibuprophen1 be my guest and fill the gaps while i struggle with IRL :)

[Ibuprophen]

I've got no problem lending a hand @XenHat and just wanted to be sure to communicate things first so I can get a better idea if it's:

1) Something that's being worked on already...

2) Something that one of you prefers to work on...

3) Something that one of you just doesn't want me to work on...

I'll let you guys know... :-)

~Ibuprophen

[XenHat]

I've always preferred things to improve and get worked on, instead of blocking progress because I don't have time and prefer to do it myself. Go ahead, I can always re-write if it's an issue.

As for "being worked on" is usually reflected by "assigned to" on the side. :)

[Ibuprophen]

Ahh... Well there's a few questions regarding what I'm looking at and the direction in which to get there.

I would hate to push a merge request/suggestion for 1 option with one or two other options available for accomplishing the same result in the end.

I'm just asking this as opposed to what you guys may prefer (one over the other).

Is this a preferred Gitter discussion rather than cluttering up a Github issue post?

~Ibuprophen

[XenHat]

Probably :)

[Ibuprophen]

Has any resolution/progress been made with this issue @jimbo1qaz, @coddec & @XenHat?

It's just been open/stale for quite some time and I would hate to have an issue open and/or no discussion for such a long time like this.

Thanks a Bunch! 😱

~Ibuprophen

[Ibuprophen]

I'm just going to close this issue as being abandoned/unresponsive by the OP Issuer.

If you would like, please open a new issue with a detailed explanation regarding your issue.

Thank you very much for your time and understanding with this! :-)

~Ibuprophen

[daiaji]

To be honest, if I use Open-Shell-Menu in WINPE, I need this function very much. It is always troublesome to edit the registry in PE.

[KulaGGin]

Forgot to export settings for the OpenShell. But I fully backed up the whole registry of the old Windows. What registry keys do I have to restore?

Managed to search for OpenShell in the registry file. I imported all the keys that have a name OpenShell in it. But it wasn't it, also had to copy OpenShell folders from the %appdata%/local and %appdata%/roaming in order to also copy custom shortcuts. But it is still not everything: OpenShell doesn't show the list of most launched programs as before the reinstallation of Windows. It's not a big problem, this one isn't a pain, I'll just type the programs I use again.

But, of course, a good solution for this problem is to stop using registry altogether and store all the settings in a single folder: either %appdata%/local or %appdata%/roaming.