After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 347638 - Can't select a parent tag without it's child
Can't select a parent tag without it's child
Status: RESOLVED FIXED
Product: f-spot
Classification: Other
Component: Tags
CVS
Other Linux
: Normal minor
: ---
Assigned To: F-spot maintainers
F-spot maintainers
Depends on:
Blocks:
 
 
Reported: 2006-07-15 23:41 UTC by Douglas Watson
Modified: 2006-10-06 04:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
new behavior for selecting/deselecting tags (2.25 KB, patch)
2006-07-18 13:44 UTC, Stephane Delcroix
none Details | Review
New behaviour for child tag deselection (1.79 KB, patch)
2006-07-18 20:12 UTC, Douglas Watson
none Details | Review

Description Douglas Watson 2006-07-15 23:41:21 UTC
If you select a parent tag, it will select all of it's children, which is a rather nice feature I think. The problem is, you can't deselect those children, to display the pictures that have just the parent tag.

Example:
I tagged all of my pictures from my last trip to Sweden as "Places > Sweden". I also copied the best pictures, resized them and added a stylish border in ImageMagick, then reimported them, tagging them as "Places > Sweden > Edited". I can easily display only the edited pictures, by selecting the "Edited" tag, but there's no way of having the non-edited pictures without the edited ones, which I find a bit ennoying sometimes.

Steps to reproduce:
- Select a parent tag
- Try to deselect a child : impossible
Comment 1 Douglas Watson 2006-07-16 00:09:14 UTC
I'm really sorry, I just noticed there's a typo in the title : I meant "a parent tag", not "a parent child" [need...more...sleep...]. Is there no way of editing it?
Comment 2 Bengt Thuree 2006-07-16 06:41:19 UTC
Changed title.
Comment 3 Stephane Delcroix 2006-07-17 09:21:07 UTC
What's the expected behavior?

- select a parent tag
- deselect a child
- the parent tag is deselected, all the child -exept for the clicked one- stay selected

is that right ?
Comment 4 Stephane Delcroix 2006-07-18 13:44:21 UTC
Created attachment 69114 [details] [review]
new behavior for selecting/deselecting tags

This is a proposal for an alternate behavior for selecting/deselecting tags.

* Selecting a Category will select all the subtags (same as before)
* Deselecting a Category will deselct all the subtags (idem)
* Deselecting a tag (or category) will deselect the parents line (that's the new part)

I'm still wondering if I prefer the old or the previous behavior. Give it a try and report on it !
Comment 5 Douglas Watson 2006-07-18 20:12:19 UTC
Created attachment 69138 [details] [review]
 New behaviour for child tag deselection

Thanks for the title change!

What I wanted was to be able to deselect a child tag without it deselecting the parent tag.

Here's my patch. It's very much based on yours (without which I probably wouldn't have found which file to edit).
Comment 6 Stephane Delcroix 2006-07-19 07:13:30 UTC
Hi Douglas,

Technically speaking, what you're doing is ok. But logically, as a category 'contains' tag and subcategories, you can't deselct a tag without deselecting a child.

It's like saying 'I like *all* the fruits AND I don't like apples'. What you can say is 'I like all fruits but apples', which imply that you do not like *all* fruits... (I feel hungry now ;) )
Comment 7 Douglas Watson 2006-07-19 17:49:32 UTC
Long Answer:

I understand that. However, in every single file manager I have used, you can view the contents of a folder without viewing the contents of it's subfolders. So why can't I view a category tag without it's child tags? The list view in Nautilus (now a tree view) is a better example of my expected behaviour: inside an expanded folder, you can expand some of the folders to view their contents and keep the others collapsed. If it acted like F-Spot's tag selector, your only choice would be to have every single child folder expanded recursively, which isn't really very practical.

It is possible to work around the limitations of the current behaviour by tagging pictures with only non-category tags : for my example, instead of having:
- Sweden   [Containing non edited pictures]
  - Edited [Containing edited pictures]
I would have
- Sweden       [Containing nothing]
  - Non-Edited [Containing non edited pictures]
  - Edited     [Containing edited pictures]
That would let me choose exactly which pictures I want, but on a large scale it would mean quite a lot of extra tags to create. Considering that's a minor problem, here's a bigger one : tags don't look good without icons, and a Category tag that doesn't have any pictures associated to it can't have an icon assigned : the edit icon dialog thinks it's an empty tag. But to not get lost, I'll consider that as another bug, and this whole paragraph as a personal preference issue.

Sorry if that wasn't very clear. To sum it up, category tags and non-category tags work just like folders and files do, so why not make them act the same?

Short answer:

My suggestion doesn't interfere with the original behaviour, so why not just keep it?
Comment 8 Richard Laager 2006-08-26 07:26:30 UTC
From a UI standpoint, this is what I think should happen:

- Check a parent tag.
   - All the child tags are selected.
      - Then, uncheck one child tag.
         - The rest of the child tags stay selected, but the parent tag turns to
           a greyed-out checked box to indicate that it's partially enabled.
Comment 9 Gabriel Burt 2006-10-06 04:22:26 UTC
With the new search functionality that just landed in CVS, you should now be able to search for a parent tag, which will also search for its children, but you can filter its children out by ANDing them to the query and NOTing them (double click or right-click -> exclude).