search

vslavik / winsparkle

App update framework for Windows, inspired by Sparkle for macOS
http://winsparkle.org
Other
1.31k stars 267 forks source link

Registry use LOCAL_MACHINE instead of CURRENT_USER #217

Closed abemedia closed 4 years ago

abemedia commented 4 years ago

Hi, first off thanks for such a great lib!

I recently created Go bindings for WinSparkle at https://github.com/abemedia/go-winsparkle and noticed when using them that it always saves to the CURRENT_USER registry. Is there any way to use LOCAL_MACHINE instead?

Thanks again!

vslavik commented 4 years ago

I recently created Go bindings for WinSparkle

Nice! It's about time I start linking to the bindings...

Is there any way to use LOCAL_MACHINE instead?

Well, submit a PR with a rationale… But why? The few things WinSparkle saves are user choices or per-user state, so HKCU is the appropriate root, isn't it?

abemedia commented 4 years ago

You are definitely right that it is user settings really...

My rationale is that if the software is installed in program files for all users then an update also affects all users. Also if it's enterprise software that's installed by an admin it makes sense to me that the admin would be able to set the options for all users.

I guess the counter argument to the latter is that the admin would also be the person in charge of system updates.

Also since you're trying to mirror the functionality of Sparkle which stores the settings in app defaults i.e. ~/Library/Preferences which is also user-specific I understand if you'd rather keep it as it is.

vslavik commented 4 years ago

My rationale is that if the software is installed in program files for all users then an update also affects all users.

Yes, but if you look at what is stored, it's stuff like whether this particular user wants to be bothered with updates (or a specific update), whether to check for update now (i.e. last check time; if a user that never updates checked recently, that shouldn't prevent the user that does updates from being alerted to a new version) etc.

And then there's also the small matter of non-privileged users not having permission to write to HKLM...

Also if it's enterprise software that's installed by an admin it makes sense to me that the admin would be able to set the options for all users.

To be clear: when WinSparkle reads config values, it looks into HKLM if user-specific HKCU value isn't present. So admins can do machine-wide configuration, e.g. disable update checks, by writing to HKLM.

Also since you're trying to mirror the functionality of Sparkle which stores the settings in app defaults i.e. ~/Library/Preferences which is also user-specific I understand if you'd rather keep it as it is.

I don't think that's all that relevant, this is strict platform-specific territory. I'm more interested on what is right on Windows here.

I should also say for completeness that you can always customize this using win_sparkle_set_config_methods().

abemedia commented 4 years ago

Thanks a lot for the detailed response!

You make a very good point with what is being stored and the permissions issues.

I haven't implemented win_sparkle_set_config_methods() in the Go bindings yet but doing that would make it easy for anyone wanting to customise this behaviour to do so with a custom function so I think we can close this.

Thanks again!