-
Notifications
You must be signed in to change notification settings - Fork 180
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
Add type hints and refactor most *Common methods to be static or functional #166
Conversation
PySide2 5.15.2.1 added support for Python 3.10
PySide6 prebuilt binaries have support a wider range of CPU architectures (namely Apple Silicon/M1).
ConvertThread.finished conflicted with QThread.finished
With Qt 6, subclassing QApplication no longer seems to segfault
Was indicative of something that needs to be refactored, but this change resolves the ImportError
Object needed to be bound to some variable
Application moved to application.py to avoid circular imports
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Taking a look a this PR it seems it joins multiple things that should individual PRs, which make it quite painful to review. There are many improvements that do make sense, but I think the architecture restructure needs more thinking. So my suggestion is making individual PRs on stuff that is not related to this restructuring first. I'll try to break down the things so it's easier to see what I mean:
- 🟣 type hints4978ab7
- 🟣 general code cleanup (linting)
- 🟣 code cleanup & logic improvement:
- 🟣 removing relative imports
- 🔴
settings.py
->gui/settings.py
(for reasons explained bellow)
Legend:
- 🟣 suggest making individual PRs, based on
main
(as [WIP] Upgrade to Qt 6 #164 is blocked) - 🔴 suggest dropping (see explanations bellow)
What's not in the list is what is actually the content of this PR. So in general my suggestion is to make individual PRs about the above topics and then the real contents of this PR and suggested code architecture change will become much clearer.
I think overall the proposal makes sense, but I'm thinking the code may need a restructuring to accommodate future requirements. So I'd hold off for now on this PR until that restructuring takes place (if it does).
Settings
One of the changes was moving settings.py
into the GUI. While it's presently not being used at all by the GUI component, it the future, it would make sense for for the CLI or any other front-end to inherit it. So I'd keep it where it is.
Comment on common methods
Again, this is quite a big one and I'm still trying to make sense of all the changes proposed.
While trying to take a step back and looking at the goal, it seems to make sense. In the current app's design, common is like a context shared among a significant portion of components. Segregating this into common and gui_common would make sense (as was done), following this logic.
But it almost seems like "common" has lost purpose in the original code base. To the point where now that the "GUI" common doesn't actually serve to keep some sort of shared state, because all of it can be static or functional. This PR addresses this but I think if we're going in this direction, we should go full on. What I mean by this is that unless there is some shared state that needs to be kept, we should remove completely all the "common" and instead move all of its functionality into the new util.py
. What little is left, I'd argue belongs in settings. For example the input file and output file is a transient setting, but still a setting nonetheless.
} | ||
|
||
|
||
def display_banner(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like this method is exclusive for the cli. I suggest moving it to cli.py
.
WINDOW_ICON_FILENAME = "dangerzone.ico" if SYSTEM == "Windows" else "icon.png" | ||
WINDOW_ICON_PATH = get_resource_path(WINDOW_ICON_FILENAME) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both of these are GUI-specific code and should be instead in their respective GUI files.
from .container import convert | ||
from dangerzone import container | ||
from dangerzone.common import Common | ||
import dangerzone.util as dzutil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Importing directly to make the code easier to read. This is also done in the securedrop-client.
import dangerzone.util as dzutil | |
from dangerzone.util import OCR_LANGUAGES |
This refactor also needs to be propagated.
@gmarmstrong if you're short on time, I don't mind opening these PRs. Just let me know if that's the case. |
Thanks a bunch for taking the time to sort these out! My apologies for the disorder. I am pretty booked right now, feel free to make those PRs if you'd like. |
I'm re-implementing many of these changes in a new branch. I had to resort to branching off main as this has diverged too much. |
static methods that are used application-wide should belong to the utilities python file. inspired by @gmarmstrong's PR #166 on refactoring global_common methods to be static and have a dzutil.py
Take whatever you'd like, thanks again for trudging through it. Feel free to close this PR whenever. |
Thanks! I'm going to open the PR in some minutes. Would you like to give feedback on it? Or shall I just go ahead and merge it? |
Happy to take a look! :) |
Reduce "global_common" coupling by moving methods that could be static onto "semantically-closer" py files. Based on work initially made by @gmarmstrong on PR #166: - moves container-specific code out of global_common.py and into container.py - creates a util.py for static methods used through the whole app - move banner code from global_common onto cli.py given that it's only displayed there - updates tests to reflect these changes - move ocr_languages from global_common onto its own json file in share/ocr-languages.json to simplify global_common logic
Superseded by #203. |
This draft PR depends on a work-in-progress PR.
Builds upon commits from #164. This branch begins at 616ba55. See this diff for comparison.
Does some hefty refactoring:
Fixes #122
If this design doesn't feel right to others, feel free to speak up about it! It feels more intuitive to me, but it's a big change.