gijzelaerr
commented
10 years ago Original comment thread migrated from bugzilla
at 2010-08-15 16:53:10 Oleg Smirnov replied:
At the moment each plot has its own private QLabel used for coordinate tracking. Obviously, only one of these is showing anything useful at any one time, since the mouse pointer can only be in one place at a time. With 2x2 or 3x3 plots, that's a LOT of screen pixels going to waste which I'd rather see used for bigger plots.
A much better solution is to track plot coordinates in the status bar at the bottom of the browser -- get rid of the per-plot QLabels entirely! I can give you a simple API call to stick a message into the status bar, and Qt has a built-in facility for making this message transient (i.e. automatically disappear after X seconds if it's not replaced by another one.)
at 2010-08-16 22:45:41 Tony Willis replied:
I don't disagree with the real-estate complaint, but putting the result on the status bar isn't the best idea because 1) currently if you have a lot of plots the status bar tends to disappear off the bottom of the window (see bug 796) so its not that useful and 2) I like to see the requested information appear close to the window I'm looking at and not (possibly) a long way off on a status bar. Is the Qt facility you mention adaptable to QLabels? I couldn't find any thing directly relevant in the Qt docs. I tried using Qt one-shot timers, but that led to flickering.
at 2011-06-30 12:54:08 Oleg Smirnov replied:
I still think the status bar is a better place for it than what we have now -- and in fact one reason it tends to disappear off the bottom of the screen when many plots are open is because the plot widgets use so much real estate, so fixing this bug will alleviate that problem too. Now that you've admitted to not being very busy, could you please try implementing this in time for the 1.2 release in August?
The API is very simple: from any one of your plugins, you may call
gw.show_message(message,timeout=2000)to put a message into the status bar for
'timeout' milliseconds. 'gw' is the 'gw' argument passed into the plugin
constructor.
Note you will need to update (to r8243) to get this facility.
at 2011-07-05 22:01:23 Tony Willis replied:
Yikes - did I say I wasn't busy?? Unfortunately the inverse seems to be true. I still don't like the idea of putting the output on the status line - its too far away from the area I'm looking at. Lets discuss this in the telecon.
at 2011-07-10 17:57:28 Oleg Smirnov replied:
OK, following up on our discussion of Wednesday -- how about we use a QToolTip popup? QToolTip.showText() will show a tooltip window with the given text, at any position you like. The only question is then when and how to hide the tooltip. Offhand, I'd say hide it when the mouse pointer leaves the plotter widget. So all you have to do is override QWidget.leaveEvent(), and call QToolTip.hideText() therein.
at 2011-07-19 20:16:19 Tony Willis replied:
Should be fixed.I added an option 'Show coordinate tracker' to the right clicked context menu. If selected a QtoolTip showing the coordinates and value will appear just below the given display. The QToolTip only appears while the mouse is inside the plot window (seems to be the default QToopTip behaviour - no need to handle leaveEvent() or hideText() methods.
at 2011-07-20 00:42:14 Oleg Smirnov replied:
Excellent stuff! I think this is a much-improved solution.
I have one last quibble. In the right-click menu, you use "Show XXX" for a
number of toggle-able elements (coordinate tracker, colour bar, etc.), which you
then replace by "Hide XXX" when the item is shown. This is somewhat inconsistent
with the rest of the browser GUI (and with modern GUI usage in general). It is
preferable (and actually easier, code-wise) to use a checkable QAction instead,
which then appears with a checkmark in the menu (see TDL | Sync scripts for an
example). There is then no need to change the menu text -- Qt renders the menu
entry as "Show XXX" (no checkmark) or "
All you have to do is call setCheckable(True) on the QAction when you have created it (optionally followed by setChecked(True), if you want the initial state to be checked), and connect SIGNAL("toggled(bool)") to a slot with a single boolean argument. Please give it a try, I think you'll see it will both simplify the code and the GUI.
at 2011-07-20 23:27:05 Tony Willis replied:
I've now implemented a checkmark on/off display in most of the boolean options of the right context menu. There are still a few left to do for cases relating to visibility display, but we're getting there. :)
at 2011-08-02 23:53:27 Oleg Smirnov replied:
Reassigning this to myself for final testing.
at 2011-08-12 18:38:17 Oleg Smirnov replied:
Seems to work fine, but is there some deep reason why some options are check-to- show, and others are check-to-hide? It would be more logical (and consistent) to have them all called "Show", with some (history, colour bar) being on by default.
A few more quibbles: "Show log range" should be renamed to "Logarithmic range", "Toggle axis flip" should be called "Flip axis" (since they are, semantically, no longer commands, but on/off states), likewise "Toggle l/m axis rotate" should be called "Rotate l/m axis". Can we hide the latter option altogether when the l/m axis is no longer there?
Finally, "Show amplitude/phase" and "show real/imaginary" should be handled as
in the inspector display: with a separate submenu "Complex data display -->
amplitude-phase / real-imaginary".
Finally, in the inspectors display right-click menu, there's still a couple of these old-style "Show/hide" commands, rather than checkboxes.
I think it's important to have consistency in the GUI, so let's try to clean these up as well.
at 2011-08-12 18:45:26 Oleg Smirnov replied:
Same goes for "replace/append vector data" in the inspector dialog. Can we please have a checkbox called "Append data", on by default?
at 2011-08-15 23:04:36 Tony Willis replied:
Your wish is my command. :)
at 2011-08-31 18:38:48 Oleg Smirnov replied:
(In reply to comment #11)
Your wish is my command. :)
Thanks, it's almost perfect now. I've gone in and fixed a few menu text strings (r8389) for consistency with the other menus, I hope you don't mind. I have also removed the use of "Vells" in the menu, as that is a confusing term not meant to be exposed to the user...
My last and most precious wish is to get rid of the popup Vells selector used by display_image_qt4, and instead use the QMenu-based Vells selection scheme from chartplot_qt4.py. We really should be using the same paradigm consistently, for what is the same operation. I prefer the menu-based scheme, as it is quicker to switch Vells, and easier on the eye. Think you could do that quickly? It only a cut-and-paste job I imagine...
at 2011-09-01 20:37:26 Tony Willis replied:
Aargh! No its not that easy. The little popup menu has a lot of extra stuff for handling tree-based stuff such as looking at perturbation output in condeqs for example (look at e.g.the condeq in Waterhole/contrib/AGW/MG_AGW_tree.py). Also the thing I like about it is that the little selection GUI persists on the screen and I can switch from one image to another without having to go back to the original context menu. The one thing that does annoy me with it which I haven't been able figure out how to handle properly is that I cannot get it to appear where I want it to. I would like it to appear under or at the location of the 'Vector/matrix element selection' button (golly - I find that even more incomprehensible than 'Change selected vells' !!! - could we compromise on 'Change displayed data set'?? ) My current attempt is in display_image_qt4.py around line 878. The problem is that I can't seem to find a way to figure out the absolute x,y location to move the little GUI to, because the display windows are buried within your gridded plugins framework.
I will change the stuff in VellsTree_qt4.py to get rid of any mention of Vells in the pop-up GUI.
at 2011-09-01 20:46:46 Tony Willis replied:
I updated and checked in VellsTree_qt4.py and display_image_qt4.py so that the word 'vells' does not appear in the pop up GUI.
at 2011-09-02 20:06:01 Oleg Smirnov replied:
OK, let's leave the popup in place then, I'd forgotten about the perturbed values thing... "Data set" is not a good name for it either, those things are not data sets at all (especially since we use the term loosely to describe something much larger, i.e. an MS), how about you call it simply "Element selector" and "Available elements"? As for the placement issue, you can convert relative position in the current widget to an absolute x,y position via QWidget.mapToGlobal(). Finally, please set the title of the little window to "Element selector", no need for the little QLabel inside it then.
at 2011-09-02 20:09:50 Tony Willis replied:
I'd already found the mapToGlobal function - grrr- I'd actually used it to position the little tracker popup below the X- axis position a month or so ago. I now have this widget pop up a bit up and to the left of the display window where its been requested. That code version has been checked in. I'm open to suggestions for placing the widget elsewhere ... I actually like the behaviour of this widget better than the way its done in the chartplotter stuff and had long term plans to migrate the chartplotter stuff to this widget. I'll check in a new version with your label changes.
at 2011-09-02 20:30:54 Oleg Smirnov replied:
Actually, I've played with it for a bit, and the current placement is just fine. One last quibble: can you please automatically do a setExpanded(True) on the top-level tree widget item? Opening that item is the first thing a user needs to do to get anywhere anyway, there's absolutely no point in coming up with it closed. (In fact, here's a thought -- why do we need this item in the first place? Can't we just have its immediate children -- "[0,0]", etc. -- be the top- level items instead?)
As for the future of the chart plotter, I'm still not completely sold on this widget being better than the menu-based scheme, but if you can streamline it as per the above (mainly reducing the number of clicks required to use it), I suppose it could grow on me. Let's discuss it in Portugal, I have a few improvements to suggest anyway...
at 2011-09-02 21:08:03 Tony Willis replied:
OK - check out revision 8396 for my latest attempt. I don't disagree with some of your comments re top level stuff, but I find the bloody QTreeWidget API annoying and hard to understand. e.g. the system insists on column titles (what you think is a QLabel) and seems to collapse without them.
at 2011-09-02 22:51:51 Oleg Smirnov replied:
I hear you re: QTreeWidget, it took me ages to get to grips with the new API... ok, I know what to do, I'll make a few cosmetic fixes and check them in.
at 2011-09-03 00:07:26 Oleg Smirnov replied:
OK, my latent OCD kicked in so I had to make this thing perfect... please update and review the changes. In particular:
- The trick with the column titles is to call QTreeWidget.header().hide().
- You were displaying the QTreeWidget directly as a top-level window, this is not recommended. I've made it a child of a top-level QDialog -- the window manager can now handle it a lot better (no minimize/maximize buttons, stays on top of the browser, etc.)
- I've added some code to auto-size the thing so that it shrinks down intelligently when there's only a few items to be displayed.
- After much agonizing, I settled on "data element" and "data element selector" for the names.
Then, I realized the cross-section menus were still using your old imperative naming scheme, so I set to work cleaning them up -- they're now properly checkable, exclusive buttons. I also moved the "Remove x-section" option down into that menu, as it seems more logical there, and it cleans up the top-level context menu a bit (which is still way overcrowded).
Finally, I noticed you're carrying a lot of useless baggage from the bad old Qt3 days. All these menu ID tables and endless setData(Qt.QVariant(ouch)) calls are now entirely unnecessary and only serve to bloat & clutter the code. No point cleaning it up just for the sake of cleaning up (not this close to release anyway!), but whenever you go changing the menus in the future, you should take the opportunity to do so. For a convincing example, check out my new cross- section menu code at the beginning of add_basic_menu_items() -- it's about 10 times shorter than the old Qt3-derived implementation, and is, IMHO, infinitely clearer.
Anyway, I think we've just about flogged this horse to death, so I'm going to close the bug (and open another one for a post-release review of the data element selection scheme).
at 2011-09-03 00:08:20 Oleg Smirnov replied:
The updates referenced by comment #20 are in r8398.
at 2010-08-15 16:53:10 Oleg Smirnov reported:
Get rid of individual coordinate tracking widgets -- use status line instead