I've got a QGraphicsItem (a map) that has some children (icons on that map). No issues so far.
However, I want to be able to remove the icons from the screen. In order to do this, I tried to just break up the parent-children relationship:
foreach(QGraphicsItem* item, displayedIcons) {
item->setParentItem(NULL);
}
In some way, the map and the icons are detached from each other, i.e. when I pan the map, the icons remain at their absolute position on the screen. But the problem is, that the icons are still displayed at all.
Is there anything I am missing in order to actually remove the icons from the screen?
Use QGraphicsScene::removeItem().
Related
I am trying to achieve something what, I thought, would be a super easy thing to do. But for some reason QtDesigner is driving me crazy, it simply won't work...
I created a GUI and freely arranged different elements in the window, without layout or anything like that. At some point there were to many elements, so all I wanted to to, was to make it scrollable up and down, to see all elements.
So I added a ScrollArea in QtDesigner and added all elements as children of this ScrollArea (which btw also was a pain in the ass, because apparently drag and drop in the Object viewer is not a thing, and editing the .ui file by hand, is also not allowed... great).
So the result I have now is the following:
before resize - no scrollbar, elements at bottom inaccessible
resized vertically - some stuff still snapped off at the bottom
So as you see, although I created a ScrollArea... There is no scroll area. So I googled a little bit and found out that you can add layouts to your scrollarea, and yey, finally, a scroll bar! But how in this world am I supposed to arrange the elements in the way you see in the screenshots, with layouts. They are so super restrictive.
How am I supposed to simply get a vertical scrollbar, without this restrictive layout stuff?!
Here is how my object viewer looks
And here is what is called upon GUI creation:
ui->setupUi(this);
//setCentralWidget(ui->scrollArea);
//ui->scrollArea->setWidgetResizable(true);
I tried it with, and without the commented lines. No scrollbar, no matter what I do.
Try this to fix it:
In Qt Designer:
Select QScrollArea object.
Uncheck the QScrollArea properties widgetResizable.
In C++:
// If you want to set `widgetResizable` programmaticly
ui->scrollArea->setWidgetResizable(false); // Optional if you did it in Qt Designer
ui->scrollArea->widget()->adjustSize();
I am programming a game and I have a tab widget which takes up the majority of the window. I want to use the extra space in the tab bar for buttons. I have the tab widget in a grid layout. To accomplish this, I use the code below in order to remove and add back the button widgets to the desired areas (the solution to someone else's question).
ui->centralLayout->removeWidget(ui->exitButton);
ui->centralLayout->removeWidget(ui->ResizeButton);
ui->centralLayout->addWidget(ui->ResizeButton,0,4, Qt::AlignTop|Qt::AlignRight);
ui->centralLayout->addWidget(ui->exitButton,0,4, Qt::AlignTop|Qt::AlignRight);
This does not work for me; however, because I would like the second widget-- the resize button-- to be just to the left of the exit button. What is occurring is that it instead overlaps the exit button. I simply need to move it 21 pixels to the left and have no idea how!
I tried putting both buttons in a frame and then removing and adding the frame the way I did the buttons. Unfortunately the same functions I used do not exist for the qt frame object.
Here are some pictures of my window.
https://docs.google.com/document/d/17w5USWQcCtb6OdcRShdcYcRjXTcdVpmdrG5TWLX71y8/edit?usp=sharing
you are using void QGridLayout::addWidget(QWidget * widget, int row, int column, Qt::Alignment alignment = 0) overload.
2-nd and 3-rd parameters are row and column of a grid. And you put 2 widgets in the same cell so they are overlaping each other.
I solved my problem. Earlier when I was trying to add them to a frame and reposition it I could not but using a widget as the container for my buttons let me place them the way I was earlier attempting to individually place the buttons.
Is there any way to add QActions as a list item on QListWidget?
I want to make a customization window which will show list of actions on a widget for move up, move down, Rename and other options. I'd like to display it on the widget same as it appears as a context menu.
I tried adding it as a list item with icon and text, but the look it not very good:
i) list items with blank icon are not aligning properly, even after adding a blank icon of size 16*16 is not taking up any space and text with icons & w/o icon are not aligning.
ii) I'm unable to add right-pointing black triangle at the right most, in-case of sub-menus cause somehow unicode character for this is not getting displayed on my Linux machine.
That's why I want to add QActions as it are getting popped at original place.
Any suggestions?
Yes I have a suggestion : do not try to make fancy widgets like this, users will not find it intuitive
You should find another way to implement this.
Imo, something like a QToolButton with a QToolButton::MenuButtonPopup popup mode will do the trick. This way, you can embed menu and sub-menus in a widget, using QToolButton::setMenu().
Excuse me if so topic is also created. I have look for it and, regardless, not found one.
Can I get qgraphicsitem by click coordinates that is just beneath the topmost item by cute small way? I mean I can try to use this fact that scene sends click-signal to all items beneath the cursor position, but it seems like unnecessary complication.
Use QGraphicsView::items(const QPoint& pos) const to return all the items under a viewport coordinate, they are in descending stacking order (docs).
How do you change the behavior of a QListWidget so that it resizes its height instead of choosing a (seemingly arbitrary) height and adding scrollbars? See screenshot:
The QListView's should fill up as much space horizontally as they can (creating as many "columns," if you will.) Then they wrap and make as many rows as necessary to fit all the items. These calculations should be adjusted as the window is resized. This is all working fine.
However, what I want to happen is that instead of the height staying the same, the QListView should grow or shrink vertically and never need any scrollbars. The scrolling, if necessary, will be handled on the parent QWidget that hosts all of the labels and lists. It seems like once the height of the QListWidget is established (not sure where its default is coming from), it never changes. It is too big in some cases (see second "Test" list above) and too small in others (see first "blank maps" list above.)
The layout above is nothing surprising: two QLabel's and two QListWidget's in a QVBoxLayout. Here are the properties I have set on the QListWidget's:
setMovement(QListView::Static);
setResizeMode(QListView::Adjust);
setViewMode(QListView::IconMode);
setIconSize(QSize(128, 128));
(I already tried setting the horizontal and vertical scrollbar policies, but that just turns the scrollbars off, clipping the content. Not what I want.)
Maybe you could this without using QListWidget. The Qt's examples contain a new layout class, QFlowLayout, which could be useful. With the following kind of widget hierarchy you could get multiple groups with labels and they all would be inside one QScrollArea.
QScrollBox
QVBoxLayout
QLabel "Blank maps"
QWidget
QFlowLayout
your own widgets showing map images and labels
QLabel "Text"
QWidget
QFlowLayout
your own widgets
The problem is that this kind of solution would create much more widgets than QListWidget based solution. So if you have hundreds of items in your list, this might not be the best solution.
There is a protected member function called contentsSize() in QListView. It is used to calculate the required minimum(), maximum(), and pageStep() for the scrollbars (as mentioned here).
Can you subclass the QListView class and make use of that information? I suggest you recalculate the size of your widget in the same function where you add contents to it. While somewhat lacking elegance, this appears to be a pretty reliable solution.