Headers in Treeview could we remove them?

UX/UI Design
1

So what is up with the headers in the treeview?
I kinda feel that it’s useless. realthunder also removed it in his linkstage branch.

I managed to remove it with some qss wizary. But it might and probably breaks something somewhere else that uses Qtreeview?
There is also a boolean and the docs actually say you can disable it but no where it is mentioned about how to do this true qss.

With code:

QTreeWidget QHeaderView::section {
  background-color: transparent;
  border: 0px solid #696968;
  color: transparent;
  margin: -100%;
}

chennes

2

You could submit a PR to switch the default for that preference to “False” (though it won’t get reviewed until after 0.21 is released).

3

On that same token, what value/use-case is there for the description column? Is it something which could be disabled via a property? It takes up unnecessary screen space in my opinion. I’d rather see that text be applied to a tooltip for treeview items anyway.

Sort of along the same lines of using good naming conventions vs commenting everything in source code. I don’t even know how to make entries into the description column (not that I’ve tried hard).

4

+1 for removing the headers and +1 for a preference to show the description on tooltips only

5

I can’t recall ever seeing anything in that column. Let’s kill it and see if anyone screams.

6

I’ve seen people using it and have done so myself when I felt a feature could use an explanation, that being said it’s not worth the lost real state to me. I say make it optional (off by default), and only show the headers when the description column is visible.

7

+1 to remove the headers and at least disable description by default.

The root of the tree called “Application” could also be removed. It useless.

8

Description is for label2.
Since it doesn’t have the same namr it’s even a better reason to remove. Or at least rename it.

9

Label2 as a property is hidden by default. What’s it for?

10

Add a description, pretty usefull actually but not so good implemented, definitely not something that we should hide. I remember I had a discussion about this a while ago. But nothing came out of it.

11

Just for a bit of counterweight, review a bit the options and use of the tree columns in Creo and NX for example, to see from where this is coming and why/how it can be useful…

12

sliptonic

I propose the following…
1: rename the “application” part of tree view to the filename.
2: remove headers completely
3: make the description text show as a tooltip with a 400 millisecond delay on mouse focus.

13

Is the description column same as label2?

I have used it a lot (in the past) and found it very helpful, but…
seldom use it nowadays, because it occupies valuable space.

If it could be converted to a kind of tool tip I would love it again

sliptonic - scream :wink:

14

Yes! Label2=description.
AS far as I read here:

treeView->header()->hide()

Should remove the header in treeview.

15

Maybe I don’t understand. We already have a node for the document. The Application node is the root of the tree. There’s only one and I don’t think there’s any utility to it.

2: remove headers completely
3: make the description text show as a tooltip with a 400 millisecond delay on mouse focus.

  1. Remove the description column so the object label can occupy the entire width of the panel.

+1

16

Sorry, i was posting (incorrectly, it seems) from memory. I agree completely.

17

I see that the headline costs real estate.
I don’t see where the description column costs real estate and thus I don’t see how removing it will save space. I make the widget smaller and that’s it::

18

True. Column resize is disabled and it favors the first column.

Still, since Label2 is a hidden property and, it appears, hardly anyone is using it for descriptions, It makes more sense to put it into a tooltip and ditch the second column. It’s cleaner.

19

If the property is filled out, it will take up UI space, additionally, if an overlay style form of the tree view, such as found in linkstage, is ever implemented it will become a problem. Implementing this type of change now essentially loses nothing and would make such a future change as overlay less problematic down the road, in my opinion.

I’m of the mind that anything which effectively minimizes interface in relation to the work area without negative impact, it is good. No matter how minimal that is.

20

That’s probably what it’s all about: If the property is filled out, then because someone wants to show it.