-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
MEP22 implementation for QT backend #9934
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
Conversation
New Toolbar and QT specific tools
@tacaswell @anntzer @OceanWolf |
In general looks fine to me, although my comments in #8712 still stand :) |
I guess it's fine for this to go in (when properly reviewed) as any change per #8712 will require changing all backends anyways... |
Well that was the point of waiting @anntzer, to get #8712 and MEP27 finished first because at the moment we don't have any other backends to change. Only Sorry @fariza, I haven't been much use of late. real-life... I do make headway though in reducing the length of my todo list, so hopefully back before not too long :). |
@anntzer @OceanWolf Can we move ahead with this and get the important people to play with MEP22? Most of the matplotlib maintainers use the QT backend, if we get this implementation in, we can get them to try it. Then the other pending points #9941, #9966 hopefully will get more attention. It is my fault for pushing MEP22 with GTK3 instead of QT, but too late to complain |
quick skim looks good, will need more time to do proper review |
@fariza Thanks for pushing on this and no worries about starting with gtk3 if that is what you use day-to-day! |
self.toolbar.message.connect(self.statusbar_label.setText) | ||
if not self.toolmanager: | ||
# add text label to status bar | ||
statusbar_label = QtWidgets.QLabel() |
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 code used to happen regardless of self.toolbar
. Is it OK that it only happens if its none?
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.
toolmanager and the old navigation toolbar are different. So that widget is initialized only if there is no toolmanager
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.
Yes, but can self.toolbar
be None
? Because even if it was, the old lines 492-494 were called. Now they aren't.
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 really don't know if that was a mistake before.
The reasoning behind is: If you don't want a toolbar, you don't want a statusbar, we don't have separate controls but maybe we should
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.
Isn't the status bar the thing at the top that says "Figure 1"? I think you want that regardless of whether there is a toolbar... Or is it something else?
del self._toolitems[name] | ||
|
||
|
||
class StatusbarQt(StatusbarBase, QtWidgets.QLabel): |
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.
Sorry, maybe I need to read the MEP, but all these buttons existed in Qt before. How did they get set before and do these new buttons supercede the old way or are they alongside the old way? If they replace the old way, then I why is no code deleted?
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.
The new toolmanager and tools are set to replace the old navigationtoolbar. That is why we have to "repeat" some code
We can not just delete the old one, because many users play with the internals of navigationtoolbar. So for compatibility reasons we have to keep the old code there until it is fully deprecated
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.
OK, but if I use Qt5Agg now, w/o mucking with internals I will get these widgets?
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.
@jklymak if you look at the example, the only thing you have to do is
import matplotlib
matplotlib.use('QT5Agg')
matplotlib.rcParams['toolbar'] = 'toolmanager'
at the begining of your code
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.
OK, I figured it out - toolmanager2
is still the default, and this only works if toolmanager
is called.
self, name, group, position, image_file, description, toggle): | ||
|
||
button = QtWidgets.QToolButton(self) | ||
button.setIcon(self._icon(image_file)) |
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.
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.
For the hi-dpi I have to check, but for the lightning bolt thing, this is normal. One of the main ideas behind MEP22 and MEP27 is to homogenize the tools and what is available in each backend.
Right now that tool is only available on QT with the navigationtoolbar
This PR is just to implement the basics of MEP22 to QT
Later another PR can add that tool for QT or preferably for all the backends
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.
Fo hi dpi, NavigationToolbar2QT
has some logic associated with is_pyqt5()
that switches to '_large.png
and calls setIconSize
.
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.
Here the logic is the same, we use a _icon_extension
attribute in backend_bases.ToolContainerBase
.
In the case of qt
it gets replaced with a property
@property
def _icon_extension(self):
if is_pyqt5():
return '_large.png'
return '.png'
I have to carefully check this. But you are right, this can be done in a separate PR, because it might affect all the backends and not just this one.
No. The statusbar is where the coordinates of the.cursor appears
…On Jan 24, 2018 2:06 PM, "Jody Klymak" ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In lib/matplotlib/backends/backend_qt5.py
<#9934 (comment)>
:
> if self.toolbar is not None:
self.window.addToolBar(self.toolbar)
- self.toolbar.message.connect(self.statusbar_label.setText)
+ if not self.toolmanager:
+ # add text label to status bar
+ statusbar_label = QtWidgets.QLabel()
Isn't the status bar the thing at the top that says "Figure 1"? I think
you want that regardless of whether there is a toolbar... Or is it
something else?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9934 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABa86b07FEnc86Q6SS8ZFy1N2SsDuokQks5tN39GgaJpZM4Q2k3F>
.
|
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'm approving and if its hard to work on, maybe the HiDpi work can be done after this is merged in a separate PR. Its certainly usable at HiDpi, just doesn't look great.
plt.show() | ||
|
||
The main example `examples/user_interfaces/toolmanager_sgskip.py` shows more | ||
details, just adjust the header to use QT instead of GTK3 |
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.
As per the call, this probably needs to be explicitly marked as an experimental API so we can change it w/o having to go through deprecation cycles.
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.
@jklymak I don't understand your comment, as soon as you run, it shows a warning about experimental status
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.
Sure, and the whats-new should make this explicit as well.
@jklymak I added the warning text in the whats new |
Thanks @fariza ! Glad we can move this along. |
PR Summary
Continuing with MEP22 development, here is the implementation for QT4/5
New Gui components
New tools
PR Checklist
To test it
Check out this branch and run