QTreeWidget without the ScrollArea?

**Paalrammer** · 13th February 2007, 15:09

Hi,

I'm trying to create a QTreeWidget that does not allow for scrolling. Basically what I need is that the frame of the widget is the same size of the contents of the tree. So if you expand the tree, the frame should become bigger. By default, the frame stays the same and a scroll bar is added.

(I would like to have this because I have a ScrollArea that contains two QTreeWidgets in a QVBoxLayout. I would like 1 vertical scrollbar for both trees at the same time, not one for each.)

Removing the scroll bars is easy, but the frame stays the same size. I can't find a way to resize it automatically.
I have tried reimplemting sizeHint, but I can't find the complete size of tree, only the part that is visible. Is there a way to find the size of the complete area of which you see a small part in you ScrollArea object? I thought maybe viewport->size() would do the trick, but it doesn't

How would I go about implementing this?
I'm using a Qt 4.3 snapshot :-)

p

**wysota** · 13th February 2007, 15:35

All functionality you want is a bit tricky to obtain as you'd have to react on collapsing/expanding the tree and on adding items. You won't be able to resize it automatically. If you want that functionality, you'll have to subclass, connect to all signals that may result in changing the contents size and resize the widget according to your calculations.

Honestly I'd suggest avoiding such things.... Maybe it'd be faster if you create a widget from scratch? If you're only after displaying some data in a tree form, this shouldn't be very hard. You can even reuse the delegate concept so that all items are drawn exactly the same as in QTreeWidget.

**Paalrammer** · 13th February 2007, 15:54

Hmm, I hoped this would be a very simple thing to do :-(

Your idea of creating a widget from scratch is good but ... I'm the guy who wanted to put hundreds of widgets on my MainWindow in order to simulate a tree, but it was too slow.

I did subclass the QTreeWidget and I think capturing the signals for expand/collapse won't be such a big problem. But I'm confused as to how I would calculate the size of the tree? I hoped there would be a function that would return this size (meaning the size of everything in the scroll area, not just what you can see), but I couldn't find it. Should I start iterating all the expanded items in the tree and add their sizes together to find the complete size?

p

**wysota** · 13th February 2007, 16:36

I'm sure there is such a function used internally by Qt, but at the same time I'm almost as sure that you won't be able to access it

You've reached a point where you want to abuse the widget a little and it wasn't meant to be abused like that for people other than the Trolls

Of course it may be possible to copy&paste the actual code from Qt sources.

**Paalrammer** · 13th February 2007, 17:30

It is at times like this, that I wish I had become a bicycle repairman or creator of fine Belgian chocolates instead of a computer guy.

Heck, I'll see if I can get it to work. (Maybe there is new method in 4.3 for what I want. Let's find out.)

p

**wysota** · 13th February 2007, 19:06

Originally Posted by Paalrammer

It is at times like this, that I wish I had become a bicycle repairman or creator of fine Belgian chocolates instead of a computer guy.

You're exaggerating. Qt eases your job in many places. If it did everything for you programming wouldn't be fun at all.

(Maybe there is new method in 4.3 for what I want. Let's find out.)

I strongly doubt that. There is no reason for it to be there. And such a method essentially checks which items are visible and sums up their size, so you can do the same.