[Bug 196927] New: No easy way to expand or collapse deep tag hierarchies

[Veaceslav Munteanu-2]

https://bugs.kde.org/show_bug.cgi?id=196927

--- Comment #18 from Veaceslav Munteanu <[hidden email]> ---
Created attachment 83395
  --> https://bugs.kde.org/attachment.cgi?id=83395&action=edit
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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Otto Hirr]

https://bugs.kde.org/show_bug.cgi?id=196927

--- Comment #19 from Otto Hirr <[hidden email]> ---
(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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Veaceslav Munteanu-2]

https://bugs.kde.org/show_bug.cgi?id=196927

--- Comment #20 from Veaceslav Munteanu <[hidden email]> ---
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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Otto Hirr]

https://bugs.kde.org/show_bug.cgi?id=196927

--- Comment #21 from Otto Hirr <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=196927

--- Comment #22 from DGardner <[hidden email]> ---
(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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Veaceslav Munteanu-2]

https://bugs.kde.org/show_bug.cgi?id=196927

--- Comment #23 from Veaceslav Munteanu <[hidden email]> ---
6 clicks.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Veaceslav Munteanu-2]

https://bugs.kde.org/show_bug.cgi?id=196927

--- Comment #24 from Veaceslav Munteanu <[hidden email]> ---
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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=196927

--- Comment #25 from DGardner <[hidden email]> ---
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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=196927

DGardner <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #26 from DGardner <[hidden email]> ---
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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Veaceslav Munteanu-2]

https://bugs.kde.org/show_bug.cgi?id=196927

--- Comment #27 from Veaceslav Munteanu <[hidden email]> ---
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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=196927

--- Comment #28 from DGardner <[hidden email]> ---
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?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Veaceslav Munteanu-2]

https://bugs.kde.org/show_bug.cgi?id=196927

Veaceslav Munteanu <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #29 from Veaceslav Munteanu <[hidden email]> ---
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 :)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=196927

DGardner <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #30 from DGardner <[hidden email]> ---
(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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=196927

--- Comment #31 from Gilles Caulier <[hidden email]> ---
Veaceslav,

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

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Veaceslav Munteanu-2]

https://bugs.kde.org/show_bug.cgi?id=196927

Veaceslav Munteanu <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #32 from Veaceslav Munteanu <[hidden email]> ---
Yes, Closed.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel