Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tray icon settings are saved for each install #2673

Open
4x4cheesecake opened this issue Jan 31, 2019 · 5 comments
Open

Tray icon settings are saved for each install #2673

4x4cheesecake opened this issue Jan 31, 2019 · 5 comments
Labels
Enhancement New features or functionality GUI Issues affecting the interactive GUI

Comments

@4x4cheesecake
Copy link

Background

CKAN Version:
1.25.4

KSP Version:
1.6.1

Operating System:
Win 10 Prof 64 bit

Have you made any manual changes to your GameData folder (i.e., not via CKAN)?
No

Problem

CKAN stores the tray icon settings in the 'GUIConfig.xml' which exists for each install managed by CKAN so it must be set for each game install and when a new one is added. I would like to suggest to make this a global setting like the path to the cache folder since I cannot think of any reason why someone would like to have the try icon for 'KSP version xyz' but not for 'KSP version zyx' and it becomes a bit annoying to take care of these settings each time.

@HebaruSan HebaruSan added the GUI Issues affecting the interactive GUI label Jan 31, 2019
@HebaruSan HebaruSan added the Enhancement New features or functionality label Feb 8, 2019
@HebaruSan
Copy link
Member

These are the XML nodes to migrate:

  • EnableTrayIcon
  • MinimizeToTray
  • RefreshPaused

(RefreshRate is already in Win32Registry!)

Other fields that might also make sense to migrate from Configuration to Win32Registry:

  • URLHandlerNoNag
  • CheckForUpdatesOnLaunch
  • CheckForUpdatesOnLaunchNoNag
  • HideEpochs
  • HideV
  • AutoSortByUpdate
  • IsWindowMaximised
  • WindowSize
  • PanelPosition
  • ModInfoPosition
  • WindowLoc

Are there any that are definitely sensible to keep instance-specific? If not then we could think about a project to migrate the whole Configuration object into Win32Registry. At a glance maybe these:

  • RefreshOnStartup - Might not want auto updates if you have an old game version with old mods
  • ActiveFilter, SortByColumnIndex, SortDescending, HiddenColumnNames - Might want a specialized display for some instances

@HebaruSan
Copy link
Member

Or rather than using the registry, we could switch the path from GameDir/CKAN/GUIConfig.xml to Environment.SpecialFolder.LocalApplicationData/CKAN/GUIConfig.xml, falling back to the former for loading if the latter doesn't exist.

@4x4cheesecake
Copy link
Author

4x4cheesecake commented Mar 22, 2019

Are there any that are definitely sensible to keep instance-specific?

The CommandLineArguments are also part of Configuration and in my opinion, it should stay instance-specific. A borderless window is nice to actually play the game but if you want to test/debug mods, it's not necessary or useful.

@politas
Copy link
Member

politas commented Mar 25, 2019

Or rather than using the registry, we could switch the path from GameDir/CKAN/GUIConfig.xml to Environment.SpecialFolder.LocalApplicationData/CKAN/GUIConfig.xml, falling back to the former for loading if the latter doesn't exist.

Is this a new MS standard method? If so, I like it!

@DasSkelett
Copy link
Member

If and when #2820 gets merged, we should have a solid base to bring this request forward.

I would prefer getting rid of the entire GUIConfig.xml, however, there are some options that should be saved per instance. But I think it should be possible to save instance specific options in the Registry/new json config.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New features or functionality GUI Issues affecting the interactive GUI
Projects
None yet
Development

No branches or pull requests

4 participants