GNOME Bugzilla – Bug 332584
Inconsistency in displayed tag icons
Last modified: 2006-10-29 23:22:41 UTC
Please describe the problem: If a tag has a parent tag, then the parent tag is displayed in browsing mode whereas the child tag is displayed in edit mode. It should probably be the child tag in both cases. This bug was originally reported in Debian's BTS, at http://bugs.debian.org/347470 I had a quick look at fixing this bug in the way suggested by the OP, but it seems to me the change is non-trivial as TagView was intended to be used in a GTK box while IconView was made to work with absolute positionning. But it's the first time I get to play with C# and I have close to no experience with GUI code so don't take my word for it. Steps to reproduce: 1. Define a tag as a child of another one 2. Assign that tag to a picture in the library 3. Go from Browse mode to Edit mode Actual results: The assigned tag is displayed using the icon of its parent tag in the Browse view but with its own icon in the Edit view. Expected results: I expect the same icon to be used in both cases, presumably the child's. Does this happen every time? Yes Other information:
Created attachment 60135 [details] [review] proposed trivial (albeit non-elegant) fix
this was actually done intentionally as the tag displayed in the icon view was initialy going to just be the toplevel group. I don't think this is really working out well but I want to give it a little thought before changing.
I find the top-level group idea to be a bad one - I already know, for example, that all photos were taken in some location (I have very few photos taken in a void :) ); what I really want to know is _which_ location they were taken in.
(In reply to comment #3) > I find the top-level group idea to be a bad one - I already know, for example, > that all photos were taken in some location (I have very few photos taken in a > void :) ); what I really want to know is _which_ location they were taken in. To me it sounds like your argument is more against the "Places" tag than against the mere existence of a top-level tag. In any case, I can see the use for the "Places" tag, at least in my own photography (namely to identify photographs mainly about a place as opposed to, say, portraits or abstract works). Or is it just the example you have given that is fooling my judgement? Still, I would argue that consistency is important here (everywhere, really) and that the same tag should be displayed in all views. Especially considering I cannot imagine a use case where the current behaviour would be desirable. Larry, am I missing something?
I think of the Places tag as a way of organising my categories, rather than as a tag I'd ever apply directly to a photo. Similarly I have a People tag, under which are about 50 people, and a Events tag with weddings and parties and things under it. Generally, I can tell from the thumbnail if the photo has people in it, or if it is a landscape, for example - so why bother having a little icon on the photo that gives me no more information than what I can trivially tell already? Or am I missing something too? :)
I was thinking of tags mainly as a way to easily filter, not as a way to quickly tell the subject of a particular picture. Which is still not relevant in discussing which icon should be used ;)
Other possibility to solve this issue: give priority to t.icon instead of t.category.icon, but ensure there is still something done if t.icon is null. A bit more elegant, but not by much.
Created attachment 62884 [details] [review] Alternate patch (safer?)
*** Bug 340886 has been marked as a duplicate of this bug. ***
*** Bug 341839 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > give priority to t.icon instead of > t.category.icon, but ensure there is still something done if t.icon is null. I'm in favour of that...
Created attachment 73880 [details] [review] new version there's a bug in the 'safer' version... while (category != null && icon == null) { icon = category.Icon; category = t.Category; ///Ooops, endless loop if t.Category.Icon = null }
Fixed in CVS, thanks guys.