I'm a Java dev by profession, but decided to have a go at other stuff.
Really like playing games, have too many, depressurizer is a godsend. Here's how I want to make it better: Mass setting auto update settings.
I have too many games installed, but don't really want to uninstall any.
When I get home from work, and run League of Legends - not through steam. Instantly, steam starts updating all the things, including one finger death punch which I installed half a year ago, and will maybe play again in a year's time, as well as all the new games I've installed.
Since updating games is a local, per-game setting, and steam really has no way to manage it, I figured depressurizer would be able to knock it out of the park :)
With this update, I can flip a switch, and all the old and new games I add to steam now will be changed to "don't update" by default. Use a different setting, and you can set your favourite/pinned games to update with a higher priority than all your other steam games.
CHANGE NOTES:
Chunk change Auto-update settings of your installed games.
4 Fabulous Styles of update.
Tests - unit and integration - should be a good description of new functionality.
FUTURE PROOFING:
Written in such a way that it's easily extendible.
Next step: possible to add per-category and per-game auto update settings.
Actually possible to tinker with game's "allow update in background" settings (ie: if game doesn't contain tag for multiplayer).
CONFLICT RESOLUTION:
Aka: please don't get mad at me for the way I added stuff
1. Java dev
= lots of tiny spread out files rather than one per functionality.
Reasoning:
Easier to manage separation of concern, and to locate similar things more quickly (eg: lists of games)
Down sides:
Different from current project format. You might not like this style
Mitigation:
Refactored/added as little as possible to make merges easier.
I can move stuff to a single files, and let you re review.
Extending:
I'd actually like to move all the Dlgs to one folder, so it's easier to see what's going on in the solution explorer. But I haven't checked the dev branch, and assume it would break a lot of stuff
2. Testing
Reasoning:
Don't have to do it, but it's a good way of confirming code works. After that might as well leave it there to make sure it keeps working.
Down sides:
Another project inside the solution = eye sore? Extra work to write them. Good luck convincing anyone to write tests for the entire existing code base.
Dependency injection lets you insert stuff everywhere, and makes it more obvious what's stateful during the run of the application. Waaaay easier to test. Don't have to make Program public to test certain classes (that use logger or gamedb).
Down sides:
Difficult to implement, and maybe overkill for a small project.
Mitigation:
I didn't. I just extracted some stuff in to an instance container. But it's a good future proofing tool.
3.5. App Settings public
Reasoning:
Testing with a different steam folder.
Down sides:
Other apps built on top of depressurizer can now directly access settings?
Mitigation:
Set up proper dependency injection
4. Auto generated code mess
Reasoning:
Had to change the UI (add update settings to settings), and kept faffing with trying not to change it, then gave up.
Down sides:
Depressurizer/DlgOptions.resx and Depressurizer/DlgOptions.Designer.cs look like I've changed more than I have.
Mitigation:
I can go through it with a diff, and change stuff back line by line. Only reason I didn't was because it was a lot of effort for only a little cleaner difference in SCM
5. Copyright stuff
I've added your copyright to the top of all the files. If I missed one/don't like that, shout.
CHANGE EXPLANATION:
Author's note: It's advised to look at the diff first, then refer back to here if any of the changes don't make sense. Also, bigger title = more interesting. Smaller title = less interesting. Bullet points = more functionality.
From top to bottom as the files changed go:
Depressurizer.sln
This was automatically generated. It added the unit test project (DepressurizerUnitTests) to the solution for easy browsing. Might also have added a few more weird lines for running stuff?
Depressurizer/DlgOptions.Designer.cs and Depressurizer/DlgOptions.resx
Auto generated stuff? Added a checkbox and dropdown to a new tab in Settings.
Depressurizer/DlgOptions.cs
Saving to settings, and disabling dropdown if checkbox isn't ticked.
Depressurizer/Games/InstalledGames.cs
Class that holds installed games, but is not global/public, and can only have certain operations performed on it (possible to get around it a little as shown in a test for it for reading/writing all)
Depressurizer/Lib/AppSettings.cs
Set to public to support Settings being public for testing, so you can change the steam path in unit tests.
Depressurizer/MainForm.cs
on SaveProfile and menu_Profile_Export_Click, export update settings (this is closest as I could figure out where "finalize depressurizer settings to steam" was)
on UpdateLibrary, import installed games (closes as I could figure out where "grab stuff from steam now" was)
ImportGameUpdateSettings
ExportGameUpdateSettings (maybe needs some extracting to a different class? - feels like this needs to be unit tested)
Program.cs
Moved stuff out of here to InstanceContainer. Refactored Logger setup to a method. Maybe this is better in the logger constructor, if that's the way it'll be used?
Depressurizer/Properties/Resources.Designer.cs and Depressurizer/Properties/Resources.resx
stuck to string output scheme for appManifest files. Doesn't feel quite right, because it's duplicated for input (regex), but up side, is it's nicely visible.
Depressurizer/Service/InstanceContainer.cs
Global variable container. Would be better as a set of injects.
Depressurizer/Settings.cs
Visible for testing (better injected?). Added auto update y/n and style.
Interface. Model of an installed game. Can be implemented to be fully C representation, or be a wrapper for a json-esque steam file reader/writer that only fails on explicitly mismatched terms (less work to implement).
The implementation. Fairly bog standard. Takes a Vdf file node. Returns a Vdf file node. Complains if it's asked for something it doesn't have. Sees and changes only a small set of things (safer/fallback/less work than implementing the full thing).
Depressurizer/SteamFileAccess/Enums.cs
Start of a new glorious file to interface with existing steam files. Know their lingo.
Depressurizer/Util/EnumUtils.cs
Stuff that would probably be inside enum classes if it was java. Separated here because doesn't necessarily belong to one enum or another.
Depressurizer/Util/GamesAggregator.cs
Another util class. This one matches up Installed Games with owned games (GameData.GameList). They could be merged in to one, but I wanted to disturb as little existing code as possible. Maybe better performance if coded right? (not coded for performance now, as it'll always import installed games it finds)
Depressurizer/Util/InstalledGamesLoader.cs
Attempt to separate internals and externals as much as possible. This'll tell Vdf node creator what to do in terms of getting and exporting stuff to disc.
Depressurizer/VdfFile/VdfFileNode.cs
Flattened GetNodeAt, and tested (code visibility)
Added overload GetNodeAt(string) for quick access
ADDED NEW PutNodeAt, and overloads. Modifies the VdfNode.
Load of test resource files.
Possibly better to set up some sort of config to manage which files are loaded to which test? But very complicated.
Bigfootmech
commented
9 years ago
Hey,
I'm a Java dev by profession, but decided to have a go at other stuff.
Really like playing games, have too many, depressurizer is a godsend. Here's how I want to make it better: Mass setting auto update settings.
I have too many games installed, but don't really want to uninstall any.
When I get home from work, and run League of Legends - not through steam. Instantly, steam starts updating all the things, including one finger death punch which I installed half a year ago, and will maybe play again in a year's time, as well as all the new games I've installed.
Since updating games is a local, per-game setting, and steam really has no way to manage it, I figured depressurizer would be able to knock it out of the park :)
With this update, I can flip a switch, and all the old and new games I add to steam now will be changed to "don't update" by default. Use a different setting, and you can set your favourite/pinned games to update with a higher priority than all your other steam games.
CHANGE NOTES:
Chunk change Auto-update settings of your installed games.
4 Fabulous Styles of update.
Tests - unit and integration - should be a good description of new functionality.
FUTURE PROOFING:
Written in such a way that it's easily extendible.
Next step: possible to add per-category and per-game auto update settings.
Actually possible to tinker with game's "allow update in background" settings (ie: if game doesn't contain tag for multiplayer).
CONFLICT RESOLUTION:
Aka: please don't get mad at me for the way I added stuff
1. Java dev
= lots of tiny spread out files rather than one per functionality.
Reasoning:
Easier to manage separation of concern, and to locate similar things more quickly (eg: lists of games)
Down sides:
Different from current project format. You might not like this style
Mitigation:
Refactored/added as little as possible to make merges easier. I can move stuff to a single files, and let you re review.
Extending:
I'd actually like to move all the Dlgs to one folder, so it's easier to see what's going on in the solution explorer. But I haven't checked the dev branch, and assume it would break a lot of stuff
2. Testing
Reasoning:
Don't have to do it, but it's a good way of confirming code works. After that might as well leave it there to make sure it keeps working.
Down sides:
Another project inside the solution = eye sore? Extra work to write them. Good luck convincing anyone to write tests for the entire existing code base.
Mitigation:
Delete it when it's no longer useful
3. Dependency injection (not really) / Instance Container
Reasoning:
Dependency injection lets you insert stuff everywhere, and makes it more obvious what's stateful during the run of the application. Waaaay easier to test. Don't have to make Program public to test certain classes (that use logger or gamedb).
Down sides:
Difficult to implement, and maybe overkill for a small project.
Mitigation:
I didn't. I just extracted some stuff in to an instance container. But it's a good future proofing tool.
3.5. App Settings public
Reasoning:
Testing with a different steam folder.
Down sides:
Other apps built on top of depressurizer can now directly access settings?
Mitigation:
Set up proper dependency injection
4. Auto generated code mess
Reasoning:
Had to change the UI (add update settings to settings), and kept faffing with trying not to change it, then gave up.
Down sides:
Depressurizer/DlgOptions.resx and Depressurizer/DlgOptions.Designer.cs look like I've changed more than I have.
Mitigation:
I can go through it with a diff, and change stuff back line by line. Only reason I didn't was because it was a lot of effort for only a little cleaner difference in SCM
5. Copyright stuff
I've added your copyright to the top of all the files. If I missed one/don't like that, shout.
CHANGE EXPLANATION:
Author's note: It's advised to look at the diff first, then refer back to here if any of the changes don't make sense. Also, bigger title = more interesting. Smaller title = less interesting. Bullet points = more functionality.
From top to bottom as the files changed go:
Depressurizer.sln
This was automatically generated. It added the unit test project (DepressurizerUnitTests) to the solution for easy browsing. Might also have added a few more weird lines for running stuff?
InstanceContainer
+using Depressurizer.Service -Program.Logger +InstanceContainer.Logger -Program.GameDB +InstanceContainer.GameDB
Depressurizer.csproj
Auto generated. Added files to project.
Depressurizer/DlgOptions.Designer.cs and Depressurizer/DlgOptions.resx
Auto generated stuff? Added a checkbox and dropdown to a new tab in Settings.
Depressurizer/DlgOptions.cs
Saving to settings, and disabling dropdown if checkbox isn't ticked.
Depressurizer/Games/InstalledGames.cs
Class that holds installed games, but is not global/public, and can only have certain operations performed on it (possible to get around it a little as shown in a test for it for reading/writing all)
Depressurizer/Lib/AppSettings.cs
Set to public to support Settings being public for testing, so you can change the steam path in unit tests.
Depressurizer/MainForm.cs
Program.cs
Moved stuff out of here to InstanceContainer. Refactored Logger setup to a method. Maybe this is better in the logger constructor, if that's the way it'll be used?
Depressurizer/Properties/Resources.Designer.cs and Depressurizer/Properties/Resources.resx
stuck to string output scheme for appManifest files. Doesn't feel quite right, because it's duplicated for input (regex), but up side, is it's nicely visible.
Depressurizer/Service/InstanceContainer.cs
Global variable container. Would be better as a set of injects.
Depressurizer/Settings.cs
Visible for testing (better injected?). Added auto update y/n and style.
Depressurizer/SteamFileAccess/ApplicationManifest/AppManifest.cs
Interface. Model of an installed game. Can be implemented to be fully C representation, or be a wrapper for a json-esque steam file reader/writer that only fails on explicitly mismatched terms (less work to implement).
Depressurizer/SteamFileAccess/ApplicationManifest/impl/AppManifestFileWrapper.cs
The implementation. Fairly bog standard. Takes a Vdf file node. Returns a Vdf file node. Complains if it's asked for something it doesn't have. Sees and changes only a small set of things (safer/fallback/less work than implementing the full thing).
Depressurizer/SteamFileAccess/Enums.cs
Start of a new glorious file to interface with existing steam files. Know their lingo.
Depressurizer/Util/EnumUtils.cs
Stuff that would probably be inside enum classes if it was java. Separated here because doesn't necessarily belong to one enum or another.
Depressurizer/Util/GamesAggregator.cs
Another util class. This one matches up Installed Games with owned games (GameData.GameList). They could be merged in to one, but I wanted to disturb as little existing code as possible. Maybe better performance if coded right? (not coded for performance now, as it'll always import installed games it finds)
Depressurizer/Util/InstalledGamesLoader.cs
Attempt to separate internals and externals as much as possible. This'll tell Vdf node creator what to do in terms of getting and exporting stuff to disc.
Depressurizer/VdfFile/VdfFileNode.cs
Load of test resource files.
Possibly better to set up some sort of config to manage which files are loaded to which test? But very complicated.
DepressurizerUnitTests/DepressurizerUnitTests.csproj
Auto generated new proj file for new tests project, yay!
DepressurizerUnitTests/Properties/AssemblyInfo.cs
Honest to god, have no clue what this is.
Tests!
Bunch of tests. Their name and location corresponds to the class they're testing :)