Bug 112799

From my point of view this is correct behavior, and I would be unpleasantly surprised if the subtree below the selected item was *not* automatically selected.

Example:
People -> Family -> Dad
      |         |-> Sister
      |-> Colleagues

If I'm looking for family pictures, I only have to select one Tag, even if I forget tagging pictures with my sister in them as 'Family'. While tagging, I only need to assign a Portrait of my dad one single Tag, and still find him while searching for People, Family, and Dad - which is perfectly logical, since her belongs to People and Family.

Christian, I think you are talking about a different thing.
The left pane should indeed work like you described, e.g. selecting the Family tag also shows the Dad and Sister photos.

However, Chris is talking about the right pane, the tag filter.
Right now, it is not possible to use the tag filter to display photos of Family without Dad and Sister, and I think this is what this bug report is about.

Right now, the desired behaviour is only possible with the advanced search, which is very laborious in case Family has many sub-tags.



OK, I'll explain again what happens now and what should happen:


1. 

Select/Click the Family tag in the left pane. All Family photos, including Dad 
and Sister are shown, which is correct behaviour.

2.

Open the right pane and tick the checkbox of the Family tag. Nothing should change, but now there should be black tickmarks on white ground on the checkboxes of Family, Dad and Sister. Correct Behaviour.

3.

Untick the Dad checkbox. Photos of Dad are no longer shown. The tick of the Family checkbox is now black on grey ground. All correct.
BUG: Photos of Family only (no additional Dad or Sister tags) are suddenly no 
     longer shown. 

4.

Untick the Sister checkbox.
BUG: The tick at the Family checkbox disappears completely, disabling the whole 
     tag filter. Instead, the Family checkbox should still show a black tick on 
     grey ground. Only the Family photos, without the Dad and Sister photos, 
     should be shown (Note that, additionally, the bug in step number 3 also 
     prevents this).

I hope I could make myself clear, and also hope I actually described what the original poster wanted to.

I also think that, for example, shift-clicking a tag on the left pane should show that tag without its sub-tags, thus preventing me to have to fiddle with the tag filter. But that would be an additonal bug report.

*** Bug 140675 has been marked as a duplicate of this bug. ***

I just tested it in trunk's tag filter, and there you can unselect all daughter tags without the parent tag getting unselected. So this bug is resolved.

Sidenote: Now, selecting a parent tag, doesn't automatically select all daughter tags, so if this is something you wish for, reopen or file a separate bug report.

You are wrong
Tag Familie
Undertag parent
Not possible to select only the Familie tag.
This was possible on older versions
+ familie
     -parent
     -sisters

Created attachment 19695 [details]
Screenshot showing that it works in digikam trunk.

Martin, which version did you test? I attach a screenshot, which shows, that it
works for me with trunk. There is one picture tagged "Obst", and five more
which are tagged "Rot" or "Grün", but not "Obst". Only the "Obst" one shows,
as wanted.

Indeed this is not possible, I think the design of the tag filter changed a lot in recent version.
As far as I can see, the tag filter is now working as intended. 
However, excluding tags is not supported. which means when you select the family tag, you will see all pictures which are tagged as family, regardless of what other tags the pictures might have.

I also use the trunk version.

Frank: Okay, I'll try to explain what we want.
Old example again
Family
|-Sister
\-Brother

I think we want to ability to show all pictures which are tagged Family but which DO NOT have a sisters or brothers tag. Actually, I also think this is what bug #140675 wants. I am not sure how this can be done usability-wise though, which is the problem. Putting more stuff in the tag filter just overcomplicates it (like it was before).
Because this bug report was about several different issues (my fault, sorry), do you think it makes sense to reopen bug #140675?

Hi Thomas,

if you look at bug #140675, it says: 
> Now i have picture taged by animals and not birds or
> insects and i'm not able to show only this animals-taged.

Exactly this situation is resolved now, as I showed in the screenshot: 
> Now i have a pictured tagged by Obst and not Rot or 
> Grün, and i AM able to show only this Obst-tagged.

So that bug #140675 is really resolved. Now looking at this bug here:

> In a tag hierarchy on the right pane it is not possible 
> to select only a higher level tag without its children. 
> Let's say you have /T1/T2, whenever you click on T1 the 
> whole hierarchy will be selected, i.e T1 *and* T2."

You can now select a higher level tag without selecting its children. Thus I'll leave this resolved until the reporter Chris says different.

But I do understand, what you are talking about. You say, each tag checkbox should not only have *two* states, i.e. "checked => has to be tagged with this" and "unchecked => doesn't matter", but also a *third* state "third checktype => must not be tagged with this".
I am not sure, if Qt provides for such a checkbox type. If yes, it wouldn't complicate the user interface:

[x] Family
  [-] Sisters
  [-] Brothers

as additional possibility to
[x] Family
  [ ] Sisters
  [ ] Brothers

Instead of using a [-] which causes confusion with expansion/de-expansion symbols, one could probably use a red check for the negative selection, and a green check for the positive selection.
If this is also what you have in mind, and Chris is satisfied with the current solution, we should carry this to a separate wish report.

> if you look at bug #140675, it says:
> > Now i have picture taged by animals and not birds or
> > insects and i'm not able to show only this animals-taged.
>
> Exactly this situation is resolved now, as I showed in the screenshot:
> > Now i have a pictured tagged by Obst and not Rot or
> > Grün, and i AM able to show only this Obst-tagged.

I don't think this is the same. According to comment #6, you did not tag a 
picture with Obst and Grün at the same time.
Then, it would still not be possible to see only Obst which is not Grün.

Same with the animals. The reporter said
>Now i have picture tagged by animals and not birds or insects and I'm not 

able to show only this animals-tagged 
The problem is that he additionally tagged the bird and insect pictures with 
the "animal" tag. Now, when only selecting the animal tag in the tag filter, 
the bird picture is of course shown, because it also has a (superfluous) 
animal tag.
With this, it is not possible to show all animals which are NOT birds or 
insects. Same as you described below really.


> But I do understand, what you are talking about. You say, each tag checkbox
> should not only have *two* states, i.e. "checked => has to be tagged with
> this" and "unchecked => doesn't matter", but also a *third* state "third
> checktype => must not be tagged with this". I am not sure, if Qt provides
> for such a checkbox type. If yes, it wouldn't complicate the user
> interface:
>
> [x] Family
>   [-] Sisters
>   [-] Brothers
>
> as additional possibility to
> [x] Family
>   [ ] Sisters
>   [ ] Brothers
>
> Instead of using a [-] which causes confusion with expansion/de-expansion
> symbols, one could probably use a red check for the negative selection, and
> a green check for the positive selection. If this is also what you have in
> mind, and Chris is satisfied with the current solution, we should carry
> this to a separate wish report.

Yes, you understand me, thanks :) 
I think this was possible in previous versions (at least the checkbox was 
tri-state), but had many bugs and was weird. The current tag filter is much 
cleaner and nicer, I am really not sure how it all could fit in. I'll think 
about it.
Green and red marks sound like a good idea though.
I'll open a new bug report in the next days and try to formulate it as clear 
as possible.
And I still think bug #140675 wants the same, but the reporter probably did 
not formulate it that clearly.

Thanks for looking into this. I know it is complicated :)

Hi Frank
I'm using release 25.2 Opensuse
Screenshot you can see at 
http://www.zahnd.info/Linux/tags.jpg
I'm not able to take the marker from Orchideen away or to put the marker only at Blumen.
Only the hole hierarchy can be selected
Thanks for your great work

Martin: This works with the SVN version.

OK, my new wish to exclude tags is here: bug #141753