Super categories makeover

[Tobias Leupold]

Hi list!

I'm just about doing something concerning Bug #237846. I opened the new branch
"supercategories" for this. It's not yet a lot, but please have a look at it,
before I go on in a wrong direction.

I added a QTreeWidget to the SubCategoriesPage, along with two functions
translating the current two-level hierarchy of super- and subcategories in a
tree hierarchy, which is then added to the QTreeWidget.

Is it okay to do it in this way? If so, "all" that has to be done is renaming,
drag-and-drop support and adding new sub-categories.

Yours, Tobias

[Johannes Zarl]

Hi Tobias,

I like the clean look of the tree representation, but I fear that having the
categories inside the tree will confuse users (e.g. "why can't I make Places a
subcategory of Keywords?"). Having a stronger visual distinction in the final
version would be great.

Do you want the category-tree widget to replace the others on the subcategory
page, or do you intend to keep them side-by-side? In the latter case, we would
need to sync the views somehow.

Post by Tobias Leupold
I added a QTreeWidget to the SubCategoriesPage, along with two functions
translating the current two-level hierarchy of super- and subcategories in a
tree hierarchy, which is then added to the QTreeWidget.
Is it okay to do it in this way?

I don't see why it shouldn't work this way. Maybe it would be good to combine
the drop-down category selector with the tree-view - this way you have
something better than "1" to display as a column title in the tree view
widget, and you don't have the issues I described above in the initial
paragraph.

Post by Tobias Leupold
If so, "all" that has to be done is
renaming, drag-and-drop support and adding new sub-categories.

Sure. Go for it!

Cheers,
Johannes

[Tobias Leupold]

Post by Johannes Zarl
I like the clean look of the tree representation, but I fear that having the
categories inside the tree will confuse users (e.g. "why can't I make
Places a subcategory of Keywords?"). Having a stronger visual distinction
in the final version would be great.

I thought having the "real" categories as top-level items would be nice,
because it eliminates the need for additional GUI elements. What bout simply
making them bold? No context menu, no dragging. Should be clear enough that
the "real" categories can't be handled like that sub-categories (that are just
tags), shouldn't it?

Post by Johannes Zarl
Do you want the category-tree widget to replace the others on the
subcategory page, or do you intend to keep them side-by-side? In the latter
case, we would need to sync the views somehow.

I'd only keep the tree view and drop everything else.

Post by Johannes Zarl
I don't see why it shouldn't work this way. Maybe it would be good to
combine the drop-down category selector with the tree-view - this way you
have something better than "1" to display as a column title in the tree
view widget, and you don't have the issues I described above in the initial
paragraph.

What about simply not displaying the column title at all? (see above)

The current state is of course not what it should look like later. I simply
added what was necessary to display the tree hierarchy (which was not so
trivial to compute as I thought initially ;-)

I'll try to implement the GUI in a way I think it will be nice, saying the
drag-and drop (with a copy/move action) and the rename functions. Let's see
how far I get ;-)

[Tobias Leupold]

Hi List/Johannes!

Would you/someone be so kind to have a look at the current supercategories
branch? I think most of the functionality is implemented now. Groups can be
added, renamed and deleted. When a group is selected as a member of another
group, the tree view is updated accordingly.

I also fixed a bug in FileReader: when adding a new group but no members are
selected, the group was written to the db, but it was not added to the
memberMap on a later reload. Now, empty groups show up again.

Apart from the fact that the new code surely needs some review, I'm a bit
stuck at the drag-and-drop thing now. What it should and should not do is
quite obvious: a group must not be dragged to another category or to the top
level. When it's dropped, the user should be asked (by a context menu) if the
group should be copied there (become a new member of the target group) or
moved there.

I found out how to enable drag and drop, but I don't really know how to do the
rest at the moment ... all help would be greatly appreciated!

Yours, Tobias