Created attachment 37495 [details]
Patch to add "Expand All Children" and "Collapse All Children" menu items to tag and album trees

This is my first shot at this, I tried to follow the guidelines, but please direct me in the right direction if something's wrong.
How does this work? Does someone put this in SVN if it works correctly?
Sorry about all the questions, I hope it helps nonetheless.

Yes, you use the right way. 

Post your patch in Bugzilla file, built against svn trunk. 

Someone from team will review it and test. If all is fine, code will be commited to trunk.

Gilles Caulier

No sign of this patch in RC1. In the meantime, if you select
"Tags already assigned" and then unselect it, all of the
tags in the tree will now be collapsed. I suppose it's a
bug that serves a useful purpose for some.

Bastian,

Can you update your patch against git master reprository ?

Thanks in advance

Gilles Caulier

Hi Gilles

The code has changed over years and this patch is obsolete now. Do you still want to implement this feature? If yes, I can start working over it.

Smit

Yes, this is a feature that we need.

Ask to Andi and Marcel if some new way have already studied to implement it.

In all case, this feature must be included in Tags Manager project.

Gilles

Hello everyone,

I'm a student in CS and I'm preparing to apply for the GSOC this year.

I'm interested in the Tag Manager project and I'm working on it. I would like to make sure that to include this feature of expand all / collapse all when right-click on a tag, or create buttons for them in order to make them more accessible for users?

If they are to be created as buttons I will modify the GUI mockup I made.

Yiou

Greetings,
I just started using digiKam (very nice) and I very much would like to have this feature of expanding and collapsing recursively.

May I suggest that one consider having this as a general feature on any tree structure, in my limited use so far, specifically tag and album trees. Maybe a right-click on a tree node has a menu pick to recursively expand or collapse from that node downward.

(digiKam, v3.1.0, kde 4.10.2, win, bld jun 07, 2013)

..Otto

Collapse or expand by one level is available on Tags Manager options.

(In reply to comment #9)
> Collapse or expand by one level is available on Tags Manager options.

Only being able to "collapse or expand by one level" is the problem, not the solution.

Please clarify your comment or revert the status of this issue to "VERIFIED" if your comment means what it seems to mean.

Tags Manager option to expand or collapse is not clicking on node to expand it.

here is a tree:
first
|---- second
        |---second1
        |---second2
|---- third
        |----third1
        |-----third2

So, expand function will expand on ly first on first trigger, will expand second and third with second trigger and will expand second1, second2,  third1, third2 on third trigger. 

Until you have a really complicated tag hierarchy, with extremply long tag names, you should read the full expand very quick.

I can expand everything at once, but this option gives more flexibility...

(In reply to comment #11)
> Tags Manager option to expand or collapse is not clicking on node to expand it.

Does that mean that it will expand or collapse one level (per "trigger") of *all* nodes in the tag tree, not just the nodes beneath a selected node? If that is the case, then it is not the feature I requested in the description. I do not want to "read [reach?] the full expand very quick", I want to be able to collapse or expand all tags below a *specific* tag in the tree without affecting the expansion state of any other tags, as those other tags may already be expanded to my liking. If the only option is to expand or collapse one level of all tags, then that is much less flexible, not more flexible, as it is a very blunt instrument.

What is the behaviour of your change if applied when the tag nodes are expanded to different levels in different places?

I would like to make some refining definitions... and to define what I personally would like to see happen. At the end, I will give a usage scenario to provide justification why each concept (and implementation) is useful.

First lets take as an example a tree with the fully expanded structure of
A                  A
|..a              A.a
|..b              A.b
B                  B
C                  C
|..a              C.a
    |..1          C.a.1
        |..x      C.a.1.x
        |..y      C.a.1.y
    |..2          C.a.2

One other key concept is that there is a "current cursor" pointing to one and only one item in the tree. There may be several "selected" tree nodes, but there is only one "current cursor" node in the tree. This "current cursor" may not be one of the "selected" tree nodes.

As an abbriv for Expand|Collapse, I will simply use E|C...

There are three fundamental concepts:
1)  [Expand|Collapse] All Children
For me, this means that regardless of where the "current cursor" points, the entire tree is E|C.

2)  [Expand|Collapse] Recursively
For me, this means that ALL nodes beneath the "current cursor" location are E|C. This would be the children, grand-children, grand-grand-children, and so on, from the "current cursor" are E|C.

3)  [Expand|Collapse] 
For me, this means that only the immediate children of the "current cursor" location would be expanded.

Usage scenario...
I have a large complex tree (does not really matter whether it is TAGS or any other tree-ish thing)...

So I am evaluating photos from one set, start tagging. I know that some parts of the tree are deeper than others. Some parts are more broad, some more deep, some more broad and deep.

For some nodes, knowing it is not very deep, and wanting access to all the nodes, I would set the "current cursor" appropriately and Expand-Recursively (2) from that point.

For other uses, I know that the tree is deep in some places, so I want to simply place the "current cursor" and only expand one-level at a time (3). Then maybe make the "current cursor" one of the children and again expand one-level at a time (3) or maybe knowing that I want quick access to all the nodes below that one, I would Expand-Recursively (2).

Finally, I'm done with that tagging group or from expanding so much, my tree display is now just too big. I simply want to collapse everything, regardless of where the "current cursor" may be.

Bottomline, each of the conceptual functions are important. The minimal of (3) (or 1) is simply a requirement of having a tree structure.

That of (1) is quite frustrating if one has a large (breadth or depth or both) tree and it were the only method to expand. That of (1) for collapsing is a joy when the tree has been widely expanded and one wants to quick close everything up and start over in opening up only portions of the tree.

That of (2) is really useful for applying to sections of a tree, when one knows that the node they want is buried a couple levels below a particular node.

Yes this was long, but hopefully clarifies some important concepts.

Personally I would like to have all three items of functionality. It would be nice if this were something that could be generated via template applied to a tree so that it could be coded once and used everywhere a tree structure is used.

Best regards,

..Otto

So, 1 is not 2 applied on root tag?

Also, I see you need the option for right and left sidebars, that means it's no use for it in TagManager,

And the last question, anybody is using latest git?

I will need that for feedback.

In further refinement...

if the state of display of children is with the node, then
1) touches EACH node of ENTIRE tree, saying to E|C children
2) touches the "current cursor" node and all nodes beneath, saying to E|C the node's children
3) touches the "current cursor" node ONLY, saying to E|C the node's children

The implications are that applying (3-C) to a top level node, collapses everything under that node - the collapse is for that node only and because it is collapsed, any children, regardless of how deeply expanded or not, are not affected. However, applying (3-E) again to that top level node, expands just that top level node AND however the nodes under that top level node, whether expanded or collapsed, will remain expanded or collapsed.

The implications of applying (1-C) to any node, collapses the entire tree. Then applying (3-E) will only open just the one node, all children below it have been collapsed due to the full coverage of (1-C) telling each node to not display children.

Hopefully that makes a useful feature more understandable.

(In reply to comment #14)
> So, 1 is not 2 applied on root tag?

I do not believe there is a "root" tag.
The tree has several top level tags.
In computerize, the tree widget, displays a forest, i.e. there are a multiple top level trees.

So (1) is really (2) applied to every top level tag.
Furthermore, (2) is really (3) applied to the "current cursor" AND recursively for each child of the "current cursor".

Git commit 575ce7b429f1414c8afb94b0c3ea440bfcfb8715 by Veaceslav Munteanu.
Committed on 07/11/2013 at 10:17.
Pushed by munteanu into branch 'master'.

M  +94   -0    digikam/tags/tagfolderview.cpp
M  +10   -0    digikam/tags/tagfolderview.h

http://commits.kde.org/digikam/575ce7b429f1414c8afb94b0c3ea440bfcfb8715

Created attachment 83395 [details]
Screen shot

As you can see, I only Have one root tag: My Tags

And my latest commit added 2 options to expand/collapse recursively.

Expand /Collapse recursively on My Tags, will do what you requested on 1.

I don't know where is the "forest", since it's visible only one root tag. There are other, color tags, that you can't manage.

(In reply to comment #18)

First I want to emphasize that I consider it important to discuss things from a user perspective, and only then, later, discuss how it is implemented. To discuss implementation without a clear understanding of what a user would like, leads to poor implementations. I am a user of digiKam, and though I do sw dev, I always want to know and spec user requirements before considering implementation. It is the role of sw dev to translate user requirements into implementation.

> Created attachment 83395 [details]
> Screen shot
> As you can see, I only Have one root tag: My Tags

Yes, you are correct. I just pulled up digiKam. Yes, "My Tags" has the ability to be a "current cursor" in the tree widget.

> And my latest commit added 2 options to expand/collapse recursively.
> Expand /Collapse recursively on My Tags, will do what you requested on 1.

Yes, you are correct. If "My Tags" is able to be a "current cursor" and able to apply the E|C methods, then you are correct in that it will do 1.

> I don't know where is the "forest", since it's visible only one root tag.

I used the "forest" CONCEPT in that no one would ever tag anything "My Tags" - that node, which is an implementation detail, is not a categorization (tagable) item.

I, as a user, perceive each top level tag as the top of a tree of tags. In your image, I see six top level tags. Each of these top level tags could be a tree of categorization. Such as 'Events', 'Places', 'People' - and everything under each of these top level tags as a refinement of the top level tag.

So from the user's perspective, I view your image of your tag-set as a forest of six trees. Each could be a whole categorization system of refinement of the top-level tag AND that tags under any of the top level are not mutually exclusive. An image could have a tag under People and under Events. Whereas a tag system of Animal, Plant, Mineral ... or whatever is mutually exclusive, ie it is not both a plant and animal. People are free to do what they want.

So from a USER perspective, I did not consider the 'My Tags' as a "current cursor" - it would not be something anyone would "select"...

But from an implementation perspective, since "My Tags" is able to be a "current cursor" - it will work beautifully for E|C recursively.... yet no one would ever "select" it to tag an image. From a usability, would a user consider making the "My Tags" a "current cursor" so as to apply E|C to the whole forest of tags. This is a documentation and/or live-cursor pop-up help tip issue.

> There are other, color tags, that you can't manage.

Yeppers, I can be kinda pedantic in my thinking, but it does provide for clarifying distinctions. 

I have not tried or read through your code. But I do look forward to using the functionality.

Thanks.

Sir, you are very rude. 

It's really rash to come up with words "poor implementation" and suggest me that I don't listen to user's wishes. Users always comes with fantastic requests and sw devs need to figure out how to get this working.

Without 2 options that I added, digikam already had 11(!!!) entries in context menu, and your request is to add another 6(!)(for every point one expand and one collapse). How this one will look like?

Did you ever tried to run digiKam from git with my fix ? Because it doesn't seem so. You didn't even know about root tag.

You know, I spend 2 hours reading theoretical science, and it took me 10 minutes to implement it.

I provided a fix for your problem, but you just wasted a lot of my time and also you're lecturing me.

Veaceslav,

I want to humbly apologize that you received my comments as rude. That was not my intent at all. I greatly appreciate the time and effort people put into open-source development. And I appreciate that you have taken the time to work on this.

My intent was not at all to imply your implementation was poor. I was simply stating a general principle that I have observed in sw dev projects.

I was not at all trying to lecture. I apologize that it came across that way to you.

I simply was attempting to explain MY PERSPECTIVE on its use. You had stated:
>I don't know where is the "forest", since it's visible only one root tag.
and I simply attempted to explain how I perceived it.

Again, I thank you for your work. Again I am sorry that the communication appeared rude. That was not my intent at all.

Best regards,
..Otto

(In reply to comment #20)
> Sir, you are very rude.
> [...] Users always comes with fantastic requests [...]

OK, OK, so Otto is rude and I live in some fantasy world. Now, let's get back to my description of the feature I request some years ago. I cannot tell from your comments if the change you have implemented addresses my specific request #196927 or not. Please walk me through your new feature and explain how I can use it to reduce a tag tree in this state:

  [+] Events
  [-] People
      |- [-] Family
      |      |- Alice
      |      |- Bob
      |      |- Carol
      |- [+] Friends
  [-] Places
      |- [-] Australia
      |      |- Adelaide
      |      |- Melbourne
      |      |- Sydney
      |- [-] Germany
      |      |- Berlin
      |      |- Hamburg
      |      |- Munich
      |- [-] Spain
      |      |- [-] Andalucia
      |      |       |- Granada
      |      |       |- Seville
      |      |- [-] Catalonia
      |               |- Barcelona
      |               |- Tarragona
      |- [-] USA
      |      |- Boston
      |      |- Los Angeles
      |      |- New York
  [+] Things

to a tag tree in this state:

  [+] Events
  [-] People
      |- [-] Family
      |      |- Alice
      |      |- Bob
      |      |- Carol
      |- [+] Friends
  [-] Places
      |- [+] Australia
      |- [+] Germany
      |- [+] Spain
      |      |- [+] Andalucia
      |      |- [-] Catalonia
      |               |- Barcelona
      |               |- Tarragona
      |- [+] USA
  [+] Things

I raised the feature request because the only way to go between these tag trees was to click the "[-]" to close the sub-tree for each country other than the country on which I wanted to focus. Closing the unneeded tags would make it less likely that I would have to scroll up and down to view my "Places" tags and my "People" tags (the latter are already in the requires expansion state) during a "tagging session". My suggestion was to be allowed to right-click and select "Collapse All" on the "Places" tag and then just expand out "Places/Spain/Catalonia", leaving all other "Places" tags collapsed. That would take four clicks (one for the menu and three for the tags), vs. one click for each unwanted country. I have about 25 countries in my actual tag tree, so that requires 24 clicks to close all other countries and then some more to focus on the state/city within the country of interest.

Now, as you are the developer, you do not have to comply with any specific implementation that I, your user, suggest. If you do not want to use a right-click menu, that is OK. However, I do expect that if you mark this issues as FIXED, that I will now have some new facility available to transform the tag tree in the manner that I require and that the facility will not be significantly less efficient that I would expect.

Can you explain to me what mouse clicks are required and on what elements of the UI to transform the first tree above into the second tree? Feel free to insert a "My Tags" root tag if that is a necessary new element. If you can do that, I will be satisfied that my request has been granted.

Thank you in advance for clarifying this for me.

6 clicks.

Ok, let's say  6(+2 maximum) actions, since some options are in context menu.

Also, if you can't test now, you can always reopen this one and specify exactly what option should be modified.

Can you please explain what these 6 or 8 clicks are? Why are you uncertain about the exact number of clicks? I'm sorry to be insistent, but this is the fourth time I have had to ask you for clarification on the use of your new feature to understand how it addresses my original use case.

I cannot test your changes now (sorry), but when I do test them in the future I will not know what to do. The only explanation you offered was in terms of "functions" and "triggers" (in comment #11). I cannot click a function or a trigger with my mouse. I do not know if you have added new buttons, new context menus, or something else and I do not know where I will find them. You feel that your approach "gives more flexibility", but I cannot think of any use cases for this "flexibility" that would justify 50%-100% more clicks that the approach I suggested.

So, again, thank you for engaging with me, but please just write a simple comment that states something like this:

1. Click on "Places" to select the tree node.
2. Click on <some button somewhere> to collapse <something>.
3. Click on <some button somewhere> again to collapse <something else>.
4. Click on the "[+]" symbol beside "Places" to expand the node.
5. ....
6. ....
7. ?
8. ?

Something as short and concise as that and we can be done with this issue.

Veaceslav,

Please, please, please explain how your patch addresses the use case in my issue #196927. The few details you have provided suggest that your patch does not fit my use case. Perhaps it fits a different use case and will be a very useful feature. I think you have chosen to apply your patch to the wrong issue. Issue #161988 would seem to be a more appropriate fit. Please move your patch there.

In comment #24 you told me that if I cannot test your patch now, that I should "reopen this [issue] and specify exactly what option should be modified." OK, I cannot test it now, and I will not be able to test it in the future because you will not explain what to test, so I am reopening this issue. Please see comment #22 for my specification of exactly what should be modified. You can modify your current patch, or you can apply that patch to a different issue and create a separate patch that addresses the use case in this issue.

Thank you.

Ok, I will explain what current implementation can offer.

Before explaining: Note that both digikam sidebars have a root tag called My tags that house all kind of visible tag. You can't tags in other places so "My Tags" is the root of everything.

What does digiKam support:
1. Click on tag to expand/collapse with one level(basic operation - was implemented). Tags Manager also support multiple selection and expand via context menu options. But here, Tags Manager is not suitable for working with tag-image interactions such as tagging images (it's only for reorganizing tags + few batch options).

2. Recursively expand a tag via context menu, So [+]Tag1 will become [-]Tag1->[-]Child1->[-]Nephew1 ... until all it's children will be expanded. The same goes goes for collapsing - all it's children and tag itself will be collapsed. So if you collapse a full expanded node and click it to expand one level you will see [-]Tag1 ->[+]Child1 (You have both options for recursive expand/collapse in context menu). Also option works with multiple selection: Select two independent tags using Ctrl and you will have both tags fully expanded/collapsed.

3. Otto requested a full tag collapse/expand. I avoided creating new options by allowing user to apply previous recursively collapse/expand on My Tags. If you apply recursively collapse to My Tags, you will only see [+]My Tags, if you apply recursively expand, you will see entire tag tree.

So, expanding/collapse all and expand/collapse one should be enough to build your custom tree more easy. 

You should understand that I can't provide you with expand 2 levels, or expand x to  levels, or expand only first child or third child and keep everything the same.

In short, I implemented Ottos "paper"

I can't provide you a more detailed expanation than this.

Thank you, Veaceslav,

I have just one more point on which I am confused:

(In reply to comment #27)
> Tags Manager is not suitable for working with tag-image interactions
> such as tagging images (it's only for reorganizing tags + few batch options).

The name "Tags Manager" is confusing me a bit. I reported this issue with respect to the behaviour of the tag tree shown in the "Tags" tab of the "Caption/Tags" panel on the right side of the viewing area. The issue is still relevant as of 3.5.0. My only interest was in organising that tag tree prior to "interactions such as tagging images". If the new context menu for recursively expanding/collapsing descendants of a selected tag tree node, as you described in point "2", applies to the nodes of the "Captions/Tags" tag tree, then it sounds like you have given me exactly what I need, thank you. If the "Captions/Tags" tag tree is not the same thing as the "Tags Manager" tag tree, then I'm more lost than before.

Is the "Tags Manager" the same thing as the "Tags" tree in the "Captions/Tags" panel?

Tags Manager is a new feature introduced in 4.0.0 from my GSoC work and it has it's own pop-up window. you will see a button "Open Tags Manager" on Caption/Tags.

And yes, I implemented recursive functions on Captions/Tags tree context menu and sidebar from left. I reffer them as sidebars.

This small sentence from your first post:
 "if I could right-click on a tag and select "Collapse All" and "Expand All" to collapse or expand all tags at all levels beneath that tag. "

was enough for me to uderstand what you want.

I will close this for now, and I'm happy that I could explain it for you :)

(In reply to comment #29)
> And yes, I implemented recursive functions on Captions/Tags tree context
> menu and sidebar from left.

Excellent! Thank you, Veaceslav.

Veaceslav,

This file have been re-opened. This can be closed now ?

Gilles Caulier

Yes, Closed.