-
-
Notifications
You must be signed in to change notification settings - Fork 450
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
refactor: Un-singletonize Paths & Updates #5092
Conversation
dc30ab1
to
b258187
Compare
|
||
namespace chatterino::mock { | ||
|
||
class EmptyApplication : public IApplication | ||
{ | ||
public: | ||
EmptyApplication() | ||
: updates_(this->paths_) |
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.
This seems scary. There should be a comment in the Updates
constructor saying that it must never check for updates right away.
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.
How so? (Also this is the mock app)
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.
I'd assume that once I initialize the updates, it will eventually check for updates (or some other component will trigger it).
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.
Nothing new in this PR really, except that we know where Updates is initialized. I have added some documentation to the Updates
class in 596484f
(#5092)
No longer necessary since we call new CrashHandler
To unsingletonize Paths, I had to unsingletonize Updates
Nothing groundbreaking, but there's a few things to check & review before merging this in. There's probably also a few places that could bypass the
getIApp()->getPaths()
workaround