2017-02-02 11:39 GMT+01:00 Elvis Stansvik <elvst...@gmail.com>:
> 2017-02-02 11:23 GMT+01:00 Elvis Stansvik <elvst...@gmail.com>:
>> WIth the following minimal example:
>>
>> #include <QApplication>
>> #include <QTreeView>
>> #include <QStandardItemModel>
>> #include <QStandardItem>
>>
>> int main(int argc, char *argv[])
>> {
>> QApplication app(argc, argv);
>>
>> QStandardItemModel model(3, 2);
>> model.setHorizontalHeaderLabels({ "Header 1", "Header 2" });
>>
>> for (int row = 0; row < 3; ++row) {
>> for (int column = 0; column < 2; ++column) {
>> model.setItem(row, column, new QStandardItem("Foo"));
>> }
>> }
>>
>> QTreeView view;
>> view.setModel(&model);
>> view.show();
>> view.resizeColumnToContents(0);
>>
>> return app.exec();
>> }
>>
>> I get the attached result. Note how the first column does not snugly
>> fit the contents. The limiting factor should be the width of the
>> header ("Header 1"), but there's plenty of room left to shrink the
>> column.
>>
>> Anyone else had this problem? Is there a way to improve the accuracy
>> of QTreeView::resizeColumnToContents ?
>>
>> This is with Qt 5.5.1 (Ubuntu 16.04 package).
>
> I wonder, considering the amount of extra space, could it be that the
> calculation is taking the width of a sorting indicator (the ^ and v
> arrows) into account, even if no such handle is visible (sorting is
> not enabled)? If so, should that be considered a bug that I should
> report?
Nevermind, I realized now that QHeaderView delegates to the style to
draw the header section, and that this is a bug in my style (Breeze).
With the Fusion style the result is as expected.
Breeze should take the sort indicator into account somewhere around
here:
https://github.com/KDE/breeze/blob/master/kstyle/breezestyle.cpp#L2901-L2940
I'll report it to the KDE folks.
Elvis
>
> Elvis
>
>>
>> Thanks in advance,
>> Elvis
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
