I'm struggling with QMainWindow and QDockWidgets, it seems a messy area.
I need the very simple thing: when application is closed, the arrangement of dockwidgets should be saved, and when application is opened, the arrangement should be restored.
The problem is that saveState()/restoreState() methods deal very strangely with central widget. There are several variants, and each has its own problems:
1. Central widget is set to, say, QPlainTextEdit or QLabel
When state is restored, dockwidgets occupy as much horizontal space as possible, with thin central widget in the middle of left and right dockwidgets. Size and position of central widget is kept only vertically, but horizontal boundaries between dockwidgets and central widget is not saved.
2. Central widget is set to NULL
If I explicitly call:
this->setCentralWidget(NULL);
Then stateSave()/stateRestore() do work: state is saved and restored correctly, but for some strange reason user is unable to dock widgets at the top or bottom. Widgets can be docked only in one horizontal row, no matter how hard I try to dock it at the top or bottom.
3. No central widget
By "no central widget" I mean not touching central widget at all. For some reason, the behavior is different comparing to NULL central widget:
State is saved and restored correctly, but if I make my window small, and then expand it again, then dockwidgets will remain small with huge unused area in the middle. So, user will have to resize them manually.
All of this looks very strange. Probably I'll have to go with "no central widget" variant, but I'm confused because I don't understand the behavior, maybe it's a bug, and then, behavior may change in future versions.
So, each of these ways has its own problems. If anyone can give me some clue on solving any of them, I'd be very glad.
Related
This is a screenshot of a QFormLayout holding a series of widgets. Note that the top and bottom input widgets are not horizontally aligned to the middle two rows. Note also that the labels on the left are not vertically aligned to the middle two rows.
The difference is that the top and bottom widgets are plain QLineEdit and QTextEdit widgets, the second row is a QWidget with a QHBoxLayout holding a QSpinBox and QDateTimeEdit, and the third is a QStackedLayout containing QWidgets each with a QHBoxLayout and API-supplied widgets inside those.
It looks like these middle two have extra margins. I can (partially) improve the situation by calling QLayout::setContentsMargins on the plain QWidgets' layouts. In fact, in the image above I already have, without that it's worse.
I haven't interfered with styles in the application, it's all system-default. This seems to affect Qt5 on Ubuntu 15.04, I don't think I saw this back when it was a Qt4 application.
I tried setStyleSheet ("QWidget {margin:0;}") in the top-level widget, that introduced all sorts of problems. I also tried the variation setStyleSheet (".QWidget {margin:0;}") but that had no effect. QLayout::setSpacing also had no effect, and setting padding:0 in the stylesheet doesn't fix it either.
Nothing I've tried seems to bring the spacing around these custom-layout QWidgets in line with the API-supplied widgets.
What have I missed? Thanks.
What you observe is both the struggle of multi-platform ui and the simple fact that some widgets are horrible. Given a limited amount of time and a big task, dev teams will not treat fairly the set of features. Powerful widgets and layouts like standard widgets, QGridLayout, will be maintained day and night to be defect free while legacy widgets like QStackedWidget will be pushed at the bottom of the maintenance queue.
I tried to reproduce your issue using designer alone and here is what I got (Qt 4.8) :
What you can see:
The second line with a widget container has great marging
The third line doesn't even show the combo box (I swear it's there!!).
My two cents :
There is a difference in behavior in the second row. Because I used Qt4 and you Qt5, and we both set the QHBoxLayout margin to zero then it means there is a potential regression at play, either in Qt5 or the linux implementation. So this confirms what you suspected.
QStackedWidget is horrible. It is the usual widget provided to give quick and basic functionality rather implementing the real deal. Here it would be a widget with a QStackedLayout. Like I said I suspect those kind of widgets to receive less love when big development efforts are required.
In these situations, use QGridLayout instead of a QStackedLayout of widgets with layout of widget. It will solve the issue of labels not being aligned. Difficult to set up at first but the result is usually neat.
By the way, I switched to a widget with a stackedlayout and here is the result :
I heavily use dock widgets to let the user arrange the tools the way she wants. Some of my dock widgets contain static controls (FS, fixed vertical size), others depict images, the larger the better (ES, expanding vertical size).
The problem I face is that I cannot get a configuration of size hints that lets me do this:
Make the variable size dockwidgets as large as possible
Let all dockwidgets tab with each other without buggy behavior
For 1., I can set the Vertical Policy of all FS's content widgets to "Fixed". This will force the container to use all free space for variable size widgets. However, as soon as a ES widget is tabbed with a FS widget, while the FS widget is not shown, I get stubborn behavior at best (user cannot adjust size) and buggy behavior at worst (when adjusting size, drawing errors happen, actual size did not change).
For 2., I can set all Vertical Policies to either "Preferred" (FS) or "Expanding" (ES). This should give preference to the ES, but it doesn't. I also tried playing with Vertical Stretch to no advance (while it is helpful in other scenarios where no DockWidgets are involved).
I am stuck with a situation where by default, the application wastes space and the user has to do several adjustments to the dockwidget sizes whenever the window size/layout changes. It is very tedious and counter-intuitive.
How do I do this right?
And a follow-up question: How to teach a DockWidget that it's contents have a specific aspect ratio?
I found the biggest issue was that I used custom widgets for display which would not overload the virtual QSize sizeHint() const method.
Overloading this method and returning a high number, e.g. 500, for the vertical size, helped the layout considerably.
It seems that the (private API) QMainWindowLayout does an initial guess on best dock widget sizes and then sticks to that. In the same course, it seems to ignore the differences between Preferred and Expanding policies or Stretch settings.
By providing a large sizeHint the custom widget gets better balance with stock Qt Widgets (e.g. QListView) that do the same.
The result is acceptable, but far from perfect.
I am making an app using Qt (currently 4.8) which displays a literal map from a large number of QGraphicsScene items. I would like to annotate the view with a scale. My requirement for the scale is that it is permanently fixed w.r.t the viewport widget. It needs to be updated whenever the view scale changes (zoom in, etc). There are other possible overlay items as well (compass, etc) so I'd prefer a generic solution.
I have looked at earlier questions around this which suggest:
using the ItemIgnoresTransform
using an overlay pixmap.
I tried IgnoresTransform but that way didn't work right: I couldn't figure out how to fix it in place in (say) the bottom corner of the viewport and was having some difficulty getting the text and lines always displaying in the correct size.
I scrapped that and subclassed QGraphicsView, adding an overlay pixmap by reimplementing the paintEvent (calls original one, then paints the overlay pixmap on top), and an alignment option to indicate where it goes. Coding some pixmap paint code produces a usable scale on the view. Yay! ... but it doesn't work with scrolls - I get "shattered" renderings of the scale all over, or sometimes no scale at all. I think this is because QGraphicsView::scrollViewportBy() uses viewport()->scroll() so I wondered if switching to ViewportSmartUpdate would help, but it doesn't help enough. I'd prefer not to switch to ViewportFullUpdate as that would likely slow the app down too much (there are millions of items in the scene and that would require a full repaint just to move around).
So. Any ideas from here? Would adapting my pixmap code to write to a new mostly-transparent Widget that is overlaid on the viewport be a better way?
Thanks for any help...
Though it may not be the best way of doing this, in the past I've added custom widgets to the window that holds the QGraphicsView / QGraphicsScene, which have the same graphic style as the QGraphicObjects in the scene. When the view is then used to move objects in the scene, or the scene itself, the items on the window remain in the same place.
Hope that helps.
I've a QMainWwindow, and I've fixed its size.
i.e. I've set Minimum and maximum size of the window to the same number.
Could anyone tell me whether this will be a problem if I'm to use this in another screen with a different resolution, and if so, how am I to handle it?
Kindly advise, and also if there's another way ( perhaps more elegant) to set the size of the QMainWindow.
UPDATE :
I have a QMainWindow with a QTableView as a widget, amongst others. When I expand the main Window, the tableview does not, and it leaves an ungainly blank space, so I fixed the size.
If I were to make it resizeable, how do I expand the QTableView widget, alongwith the QMainWindow. I have a Central Widget, this widget has a vertical box layout, and to this layout I've added the 3 widgets, one with QGridlayout, one horizontal line, and the other QTableView. The QTableView, on its own, is not inside a layout.
I'd imagined this would be sufficient to expand the table too, once QMainWindow were expanded, or reduced, but it doesn't happen.
How do i go about it, i.e., expanding the QTableView as well?
Thanks.
It will be a problem if you fix the size to one that is larger than the screen can handle. There are various ways to scale the size of a window according to the screen size. I recommend using QApplication::desktop(), which will return the desktop widget (you may need to #include <QDesktopWidget>. Note that this widget can actually encompass multiple screens, so if you just want the current screen, you can just do:
QRect screenGeometry = QApplication::desktop()->screenGeometry();
You could alternatively use QDesktopWidget::availableGeometry().
It is worth mentioning that among Qt users, I think there is a general dislike of fixed size windows. Most recommend taking full advantage of the Qt layout system, which provides lots of flexibility for resizing windows. I'm not saying you should definitely do this, because all projects are different, but it could be worth looking into.
I'm developing a Flex 2 application, and I noticed that part of the library which is responsible for moving GUI windows (TitleWindows) around when you drag them with the mouse gets confused if there is a clickable (buttonMode = true) sprite beneath them. When I say confused, I mean that the window is moved around normally for a while, but then at some point "jumps" into the upper left corner of the flash app, and makes very minor movement there. Then at some other point it jumps back. It is more difficult to explain than to experience, so please go and see for yourself. Here's how to reproduce the problem:
Go to http://www.panocast.com
In the left sidebar, choose "Real Estate"
Just below the bottom right corner of the flash window, choose "high res" by clicking on the rightmost icon.
When (part of) the video loads, click on the staircase. A TitleWindow will pop up.
Try dragging it around the screen. When the mouse cursor is moved above one of the clickable areas (like the staircase), the window is misplaced.
(Sorry, but can't give you a direct link, part of the page is generated dynamically.)
(What's makes the problem even more interesting is that for me, in "low res" mode, the problem does not occur! There is very little difference between the various modes.) I would really appreciate if someone told me what was going on here and how it can be fixed.
I'm not sure if it matters, but the underlying sprite is actually not just plain sprite, rather it is a Papervision3D renderer object with some 3D elements in it. I'm telling this because it is possible that the incorrect mouse coordinates somehow come from the texture UV mapped on the clickable objects.
I've managed to replicate this on the low res mode as well, so I don't think it's related to the resolution.
This looks to be because the MouseEvent is being handled by the TitleWindow AND the Papervision3D window. Perhaps you need to force stopImmediatePropagation() on one or the other? Or maybe switch off the MouseEvent handling for the Pv3D window when the TitleWindow pops up?
That's a tough one to debug without some source; something's apparently calling either move() or setting x and y properties on that TitleWindow and scheduling it be moved.
When I first read the post, it "smelled" like maybe a rotation miscalculation somewhere (using Math.atan vs. Math.atan2 can sometimes have that kind of effect), so you're right, it could have something to do with PaperVision, assuming you're not using Math.atan or setting rotation properties yourself anywhere. Just thought I'd mention it, though it's probably not happening in your case. You never know, though. ;)
More likely the LayoutManager is moving the component in response to a property change on the component. The Flex docs explain that in addition to setting its x and y properties, and explicit calls to move(), a UIComponent's move event can also be triggered when any of the following other properties change:
minWidth
minHeight
maxWidth
maxHeight
explicitWidth
explicitHeight
PaperVision or no, maybe that info might help you isolate the source of the move. Good luck.
I got this figured out. Apparently, this is a Papervision3D problem. There is a class deep inside Papervision3D called VirtualMouse, which is supposed to generate MouseEvents programmatically. This happens, for example, when the user interacts with any of the interactive objects on stage, e.g., a Plane with an interactive material on it (as in my case).
The problem is that the x and y coordinates of the generated event represent texture UV coordinates (just as I suspected) and not real world screen coordinates. When a TitleWindow (or any Panel object) is dragged, a "mouseMove" handler (among others) is added to the SystemManager, which then uses the stageX and stageY properties of the event object to determine the new position of the window. Unfortunately for VirtualMouse's mouse events, these are invalid, since the original x,y coordinates, which are probably used to determine the global stage coordinates are, as I said, not screen coordinates.
Honestly, I'm still unsure whether the events dispatched by VirtualMouse are used anywhere within Papervision3D itself, or they are just offered for convenience, but they sure make it difficult to integrate a viewport into a Flex program. Assuming that such events aren't necessary for PV3D itself, there is a one-liner fix for my problem, which must be added right after the creation of the viewport:
viewport.interactiveSceneManager.virtualMouse.
disableEvent(MouseEvent.MOUSE_MOVE);
BTW., there was a very similar (or rather, as it turns out, the same) bug with dragging sliders, also fixed by this line.