Overhaul Tools > Options panels
#653
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a huge UI project, but it'll bring some nice benefits: 1) Easier for me to add/remove/modify preferences going forward 2) Much faster loading of the Tools > Options dialog for users 3) Room for many more preferences panels, which would allow for better organization 4) Way more manageable code maintenance 5) I could finally split out direct links to individual options panels via a dedicated Tools > Options submenu, the same way Photoshop does (without losing current behavior) The new standalone windows don't work yet - that's coming!
...to generalize the code so that I can steal it for the Tools > Options window too.
I *think* panels are working again? Everything looks good, but additional testing is underway. Still TODO: fixing "reset all preferences"
Fixes #486. It took years, but I eventually found the source of this damn bug!! Thank you to Alexander, the developer of Alt+Tab Terminator, for his email correspondence on this issue. And thank you to @hi5 for catching and reporting this problem initially! (Yes, the problem was a typo on my part. The bug was obscured because PD typically uses the active image as the app icon, but early in startup, it also sets a default app icon to the hidden top-level "ThunderMain" window used by VB6. It was *that* function that had a typo where the large and small app icons were being switched. Windows always pulls the current main window icon, so I couldn't reproduce the bug there, but Alt+Tab terminator uses only the icon from the top-level window, hence the 16x16 icon instead of the 32x32 one.)
Each `Tools > Options` panel now exists as a separate window, and at run-time I simply "stitch" individual panels onto the parent Options window if/when the user interacts with them. As noted in previous commits, this greatly decreases load-time of this dialog, greatly simplifies the underlying code (by organizing it per-panel), and perhaps most importantly, it makes it much easier for me to expand Options panels in the future. (Note also that translation files are reordered a lot by this commit, but nothing in them has actually changed!)
Thank you to Roy K for his ongoing work, and thank you also to him for catching my inconsistent use of "center lines" v "centerlines"
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When I first released PhotoDemon, I never imagined it'd someday have as complicated a
Tools > Optionspanel as it does now!(I don't generally like shoving program options into a complex dialog like this - I'd rather just make a firm design choice and stick to it - but the longer I work on PD, the more I get requests for small features that really help one person but totally mess up someone else's workflow. Separate options do work well for implementing features like this, and it feels good to help where I can.)
Each
Tools > Optionssub-panel now exists as a separate window. (Before, they all existed together as a single, extremely complex window!) At run-time, I now "stitch" these separate panels onto the parent Options window if/when the user interacts with them.As noted in the commits comprising this pull request, this greatly decreases load-time of this dialog (particularly on older PCs), greatly simplifies the underlying code (it's finally organized!), and perhaps most importantly, it makes it much easier for me to expand available options in the future. And in fact - I've got some options I'm ready to implement right away, thanks to this change!