-
-
Notifications
You must be signed in to change notification settings - Fork 1k
Spike: refactor disable/enable logic for statusbar widgets via composition #8240
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
base: main
Are you sure you want to change the base?
Spike: refactor disable/enable logic for statusbar widgets via composition #8240
Conversation
47aa461
to
78c451b
Compare
5a4254d
to
8ceec13
Compare
3f6c414
to
711cd44
Compare
a4c6854
to
c65b057
Compare
I am still not very happy with the outcome here. We need to keep `urltype` on the widget class, because it needs to be exposed to as a `pyqtProperty` to make it available to the stylesheet.
437a234
to
76e2ad6
Compare
Moving the factory out of `StatusBar`, as the only `self` used in there is being passed as `parent` to `ProgressWidget`. Heavily influenced by the idea @toofar explained in his comment[1]. It's not a decorator, yet, but after thinking for too long about this approach I needed some tangible feedback by building something. I am still not quite sure what to use as a unique key for each `StatusBarItem`, as we need to look them up from other places (e.g. `MainWindow`[2]) eventually. [1] qutebrowser#7407 (comment) [2] https://github.com/pylbrecht/qutebrowser/blob/d1c7f9482662d1aacd252a7876ff501f3c7b18af/qutebrowser/mainwindow/mainwindow.py#L516-L546
One more place, where we are now able to remove direct references to `StatusBarItem`s.
Looks like `_text_widgets` is on longer necessary. I hope this is the result of my glorious refactoring skills and not just me being too tired to realize I am missing something.
76e2ad6
to
6194126
Compare
Probably a better place to store these globally.
Apparently we used the same widget instance for both scroll and scroll_raw. Not sure if that was intentional.
Nothing is referencing this, so we can safely remove it.
I am not too happy about that, because not all subclasses will implement `on_tab_changed()`. I hope I will find another way to iron this out later. For now it's at least something.
objects.statusbar_items["scroll"].on_tab_changed(tab) | ||
objects.statusbar_items["scroll_raw"].on_tab_changed(tab) | ||
objects.statusbar_items["history"].on_tab_changed(tab) | ||
for item in objects.statusbar_items.values(): |
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.
Regarding the commit message:
I am not too happy about that, because not all subclasses will implement
on_tab_changed()
The options I see are a) this, make signals part of the StatusBarItem
interface and make them optional to implement, b) have subclass items connect to signals they need on their own (either from the global object interfaces or from the MainWindow
interface which could be passed down in the constructor).
There might be other options though, I haven't thought about it too much.
These are WIP changes. I am using this PR to track progress.
TODO
backforward.py
clock.py
keystring.py
percentage.py
progress.py
searchmatch.py
tabindex.py
url.py
textbase.py
StatusBarItem
interfaceStatusBarItem
interface inStatusBar
(final integration step)StatusBarItem
subclassesbackforward.py
clock.py
(tricky)keystring.py
percentage.py
progress.py
searchmatch.py
tabindex.py
url.py
(tricky;pyqtProperty
)textbase.py
Backforward
instead ofBackforwardWidget
)Open questions
Command
widget? Seems special compared to the ones above.Relates to #7407