just like the title described, when i redraw the scrollbar in QTreeView which has a header(QHeaderView), but the scrollbar's height is the entire height of QTreeView, and i want to let the scrollbar's height equals the QTreeView's height minus the header's height.just like the pic below:
A solution for your problem might be setting the location of the vertical scrollbar to a constant_offset value acquired from the QHeaderView (on the y axis).
This could be done by subclassing the QTreeView like so:
class MyTreeView : public QTreeView
{
public:
MyTreeView(QWidget* parent = nullptr): QTreeView(parent){}
void updateVertScrollBar()
{
auto* ptr = verticalScrollBar();
QRect rect = ptr->geometry();
rect.setTop(header()->height());
ptr->setGeometry(rect);
}
void resizeEvent(QResizeEvent* ev) override
{
QTreeView::resizeEvent(ev);
updateVertScrollBar();
}
};
Depending on the sizePolicy the updateVertScrollBar method could be called just after data is filled or as presented in the sample implementation the update can occur for each resizeEvent - which should cover various resizing performed to the widget.
EDIT
Additionally removing the blank space left from the shrunk scrollbar would be tricky. First denote that the QTreeView is built from a viewport widget and scrollbars (among others). The issue you now see comes from the fact that viewport plus vertical scrollbar widths (if visible) should match and this is calculated internally.
I stated that it's tricky since there is a load of stuff happening when you try to force the size of these components. Some updates are called in-place some are called through the event loop. You can check this to get more detaile info about the concept. Similar approach is probably applied to QTreeView.
Basically what you would need to do is to stretch the viewport width. This should be probably done during the resizeEvent but calling from there methods like viewport()->setGeometry() might not end well - you might get caught into a loop. You might try blockSignals but I'm not sure this would help. In general if you want to mess with the internals of a given Qt widget you should go through it's implementation at least briefly.
Related
I got a QHBoxLayout, which contains 2 QWidgets. Both of these QWidgets have a fixed aspect ratio (square) and have a minimum expanding QSizePolicy by doing this:
QSizePolicy policy(QSizePolicy::MinimumExpanding, QSizePolicy::MinimumExpanding);
policy.setHeightForWidth(true);
setSizePolicy(policy);
and implementing heightForWidth like this:
virtual int heightForWidth (int w) const override {
return w;
}
Now, I would like those widgets to be centered in my layout. Thus I add them to the layout like this:
layout->addWidget(widget1, 0, Qt::AlignCenter);
However, like this they end up at their preferred size, but do not taking up all space that's available. Why is that? It seems like Qt::AlignCenter overwrites my SizePolicy?!
In contrast using Qt::AlignVCenter will actually make them occupy all space available. How does that fit together?
Thanks you!
Please note that Qt::AlignCenter = Qt::AlignVCenter + Qt::AlignHCenter.
Note that if you set alignment of any kind then you are saying that you want preferred size (what sizeHint returns) but object should positioned in proper way. When you want to fill whole space then alignment has no sense.
So I suspect that behavior you have described is designed like that.
Digression: Note that QGraphicsWidgets have 3 sizeHints: minimum, preferred and maximum, so in this case when some alignment expanding size policy still applies since there is maximum size widget can occupy.
it's not the first time that I want a scroll area which behaves like the following (imagine a log or chat window, but too complex to use a simple QTextBrowser):
I want to add multiple widgets, which appear one below the other (like when placed in a QVBoxLayout)
Each widget within this layout should have a fixed size or a height-for-width (like a simple label)
The scroll area should auto-scroll to the most recently added one
(optional) When there is space left (scroll bar not yet enabled), the contents should be aligned to bottom
Using QScrollArea:
My attempt in the past was using a QScrollArea using a QVBoxLayout inside. But this seems to be not as simple as I thought: Whenever I add a widget to the layout, the layout doesn't resize the scroll area content widget immediately, resulting in a delayed adjustment of the contents. For one short moment, the widgets contained in the layout are resized so that the total size equals the total size before the add operation, resulting in a too small size per widget. Also, scrolling to the newly added widget is thus not possible until the layout corrected its size to the new total size of widgets, so even a QTimer::singleShot(0, ...) doesn't help here. Even with a timeout of 20 or so, there are situations in which the layout needs more time to resize. It's not deterministic, and thus far away from a nice solution.
In order to get the bottom alignment behaviour, I initially place a spacer item in the layout. It won't require any space as soon as there is no space left and scrolling gets enabled.
Using QListView:
As my items are too complex, they need to be QWidgets. They can't have the focus, aren't selectable, so an item-based solution seems to be just "the wrong way". Also, this solution sounds too "heavy".
I just can't believe that there is no easy way, so I think I just haven't seen it yet!
QListView should be fine. You claim that your items are static, there's no interaction with them: no focus, no selection. It'd seem that a QWidget is an overkill for such items. You only need something that has a fixed size and can draw itself. That is precisely what delegates in the Qt's model-view system are for. Just implement one or more QAbstractItemDelegates for your items, and provide an implementation of a model for the data they will be rendering. The QAbstractItemView is is already a QAbstractScrollArea!
If you want to paint HTML within a delegate, it's easy to do -- again, QWidget is an overkill for a static display! There is a very food reason why it's "hard" to use QWidget for this -- the API guides you to the correct solution. Assuming your model contains html for each item, here's how you can paint it. You can go fancy with the sizeHint, of course, and should be caching the text document, ideally storing it in the model I'd think.
void MyDelegate::paint(QPainter* p, const QStyleOptionViewItem & opt, const QModelIndex & index) const
{
QTextDocument doc;
doc.setHtml(index.data().toString());
doc.drawContents(p, QRect(QPoint(0,0), sizeHint(opt, index)));
}
QSize MyDelegate::sizeHint(const QStyleOptionViewItem &, const QModelIndex &) const
{
return QSize(100, 200);
}
I have a subclass of QListWidget, the widget holds text items in a single column and multiple rows (the usual kind). I want the widget to resize itself to the minimum size where the text items will still be visible. I've tried using the resize() method with the contentsSize() argument, this will resize the widget's height to fit the text contents, however the width stays the same.
Here's a snippet of an overriden method that I'm testing this with:
override void mousePressEvent(QMouseEvent event)
{
this.resize(this.contentsSize());
}
Note: This is in the D language, and I'm using the QtD wrapper library. Unless I'm doing something wrong it might even be a QtD bug (but I doubt it).
If you're content to switch to a QTableView or QTreeView, you can call resizeColumnsToContents(), and resize your widget based on the resulting width. Otherwise you'll have to iterate over your QListWidget contents and get the maximum of the widths of the items.
I am trying to use a QTextEdit widget inside of a form containing several QT widgets. The form itself sits inside a QScrollArea that is the central widget for a window. My intent is that any necessary scrolling will take place in the main QScrollArea (rather than inside any widgets), and any widgets inside will automatically resize their height to hold their contents.
I have tried to implement the automatic resizing of height with a QTextEdit, but have run into an odd issue. I created a sub-class of QTextEdit and reimplemented sizeHint() like this:
QSize OperationEditor::sizeHint() const {
QSize sizehint = QTextBrowser::sizeHint();
sizehint.setHeight(this->fitted_height);
return sizehint;
}
this->fitted_height is kept up-to-date via this slot that is wired to the QTextEdit's "contentsChanged()" signal:
void OperationEditor::fitHeightToDocument() {
this->document()->setTextWidth(this->viewport()->width());
QSize document_size(this->document()->size().toSize());
this->fitted_height = document_size.height();
this->updateGeometry();
}
The size policy of the QTextEdit sub-class is:
this->setSizePolicy(QSizePolicy::MinimumExpanding, QSizePolicy::Preferred);
I took this approach after reading this post.
Here is my problem:
As the QTextEdit gradually resizes to fill the window, it stops getting larger and starts scrolling within the QTextEdit, no matter what height is returned from sizeHint(). If I initially have sizeHint() return some large constant number, then the QTextEdit is very big and is contained nicely within the outer QScrollArea, as one would expect. However, if sizeHint gradually adjusts the size of the QTextEdit rather than just making it really big to start, then it tops out when it fills the current window and starts scrolling instead of growing.
I have traced this problem to be that, no matter what my sizeHint() returns, it will never resize the QTextEdit larger than the value returned from maximumViewportSize(), which is inherited from QAbstractScrollArea. Note that this is not the same number as viewport()->maximumSize(). I am unable to figure out how to set that value.
Looking at QT's source code, maximumViewportSize() is returning "the size of the viewport as if the scroll bars had no valid scrolling range." This value is basically computed as the current size of the widget minus (2 * frameWidth + margins) plus any scrollbar widths/heights. This does not make a lot of sense to me, and it's not clear to me why that number would be used anywhere in a way that supercede's the sub-class's sizeHint() implementation. Also, it does seem odd that the single "frameWidth" integer is used in computing both the width and the height.
Can anyone please shed some light on this? I suspect that my poor understanding of QT's layout engine is to blame here.
Edit: after initially posting this, I had the idea to reimplement maximumViewportSize() to return the same thing as sizeHint(). Unfortunately, this did not work as I still have the same problem.
I have solved this issue. There were 2 things that I had to do to get it to work:
Walk up the widget hierarchy and make sure all the size policies made sense to ensure that if any child widget wanted to be big/small, then the parent widget would want to be the same thing.
This is the main source of the fix. It turns out that since the QTextEdit is inside a QFrame that is the main widget in a QScrollArea, the QScrollArea has a constraint that it will not resize the internal widget unless the "widgetResizable" property is true. The documentation for that is here: http://doc.qt.io/qt-4.8/qscrollarea.html#widgetResizable-prop. The documentation was not clear to me until I played around with this setting and got it to work. From the docs, it seems that this property only deals with times where the main scroll area wants to resize a widget (i.e. from parent to child). It actually means that if the main widget in the scroll area wants to ever resize (i.e. child to parent), then this setting has to be set to true.
So, the moral of the story is that the QTextEdit code was correct in overriding sizeHint, but the QScrollArea was ignoring the value returned from the main frame's sizeHint.
Yay! It Works!
You may try setting minimumSize property of the QTextEdit to see if that force the layout to grow.
I don't understand most of Qt's layout scheme but setting minimum and maximum size pretty much does what I want it to do. Well, most of the time anyways.
I have a QListView in Icon mode with lots of icons, so that a scrollbar appears, but the scrolling is not smooth and this IMHO confuses the user since it jumps abruptly from one point to another at each scroll. I would like to make the scrolling smooth but I didn't find anything in the docs. Is it possible?
Maybe QListView.setVerticalScrollMode(QAbstractItemView::ScrollPerPixel)
If I understand your question correctly you would like to redefine the scrolling behavior of the widget. I guess what happens is that listview is getting scrolled by the item's height whenever users hits a scroll arrow (marked as b on the image below).
For a vertical scroll bar connected to a list view, scroll arrows typically move the current position one "line" up or down, and adjust the position of the slider by a small amount. I believe line in this case it is an icon's height. You can adjust items height by installing and item delegate (setItemDelegate) and overriding its sizeHint method. Though this would not help you to solve this problem. What you could try is to create a QListView descendant and override its updateGeometries method. There you can setup the vertical scrollbar step to the value you want, I guess 1 or 2 for this task. Below is an example of the custom listview:
class TestListView : public QListView
{
Q_OBJECT
public:
explicit TestListView(QWidget *parent = 0);
protected:
virtual void updateGeometries();
};
TestListView::TestListView(QWidget *parent) :
QListView(parent)
{
//???
}
void TestListView::updateGeometries()
{
QListView::updateGeometries();
verticalScrollBar()->setSingleStep(2);
}
hope this helps, regards
I have a QlistWidget* in ui->barra_scroll and I feel very smooth with this.
QScrollBar *qsb = ui->barra_scroll->verticalScrollBar();
qsb->setSingleStep(5);