Bug 158865 - Adding tags: redundant menu opening necessary
Summary: Adding tags: redundant menu opening necessary
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Usability-Menus (show other bugs)
Version: 0.9.2
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-06 20:58 UTC by Dotan Cohen
Modified: 2017-08-02 21:09 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.1.0


Attachments
Assign Tags pop-up for KDE4 (247.97 KB, image/png)
2008-03-27 20:49 UTC, caulier.gilles
Details
Proposal for less redundant menu (265.19 KB, image/png)
2008-03-27 23:05 UTC, Dotan Cohen
Details
Two columns in rows for submenus (91.27 KB, image/png)
2008-03-28 14:47 UTC, Dotan Cohen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dotan Cohen 2008-03-06 20:58:47 UTC
Version:           0.9.2 (using KDE 3.5.8)
OS:                Linux

When adding a tag that has a subtag via the context menu, one must open the subtags menu to select the parent tag. This is redundant and confuses some users (not me, but people that I've introduced digikam to). The left mouse button currently does nothing when clicking on these tags, as the submenus open on hover. So there is no reason not to add the tag when it is clicked upon, and this would be consistent behaviour with the selection of tags that have no submenu.
Comment 1 caulier.gilles 2008-03-27 11:30:21 UTC
Dotan,

Sorry, but your explaination confuse me. I don't understand all points reported here. Please make a clear report...

Gilles Caulier
Comment 2 Mikolaj Machowski 2008-03-27 20:35:42 UTC
I think I understand Dotan (but don't agree ;)

Context menu on image -> Assign tag.

You will see menu

Holidays >
Marta
Work     >
Hobby

Holidays and Marta are tags on their own but with subtags. To assign
only "Holidays" tag you have to click "Holidays" and navigate furher to
submenu:

Add new tag...
------------------
Holidays
------------------
France
England
Germany

And choose "Holidays" there.

Users not experienced with hierarchical tags could expect that after
clicking "Holidays >" from top level menu tag "Holidays" would be
assigned without more interaction from them.

I completely disagree with his solution because "Holidays >" and
"Holidays" are two completely different interface elements. Yes click on
"Holidays >" is redundant because just hovering opens sub-menu but this
is common behavior in UI to speed up things. What is user only wants to
check what is exactly in this sub-menu? There is no way to tell it.

There are possibly solutions for that:

1) make "Holidays >" more different visually, eg. put it in italics to
   make that different from regular tag assigning entries from this menu
2) split it into two elements titled "Holidays" "sub-Holidays >", where
   "Holidays" assign this tag, and "sub-Holidays >" opens sub-menu

To make assigning of tag *slightly* easier maybe small reorganization?
Sub-menu could look:

Holidays
------------------
Add New Tag...
------------------
France
England
Germany

or

Holidays
------------------
France
England
Germany
------------------
Add New Tag...

In that way main tag would be easier to click - just short horizontal
move of mouse instead of combined horizontal and vertical. But this will
not solve main scope of this bug report. But I am afraid this is the way
of living with hierarchical tags.
Comment 3 caulier.gilles 2008-03-27 20:49:18 UTC
Created attachment 24083 [details]
Assign Tags pop-up for KDE4 

Mik,

This is how Marcel have re-implemented Tags pop-up menu for KDE4...

Pop-up menu items are more clean, but of it's not perfect, especially with huge
tags collection

Gilles Caulier
Comment 4 Mikolaj Machowski 2008-03-27 22:40:28 UTC
If it is possible to assign eg Animal tag from main menu (without
entering with mouse into submenu) I think this bug report can be closed.

BTW: "February 2,008" - thousands delimiter in date? C'mon :)
Comment 5 Dotan Cohen 2008-03-27 23:05:43 UTC
Created attachment 24095 [details]
Proposal for less redundant menu

Maybe the tree could be opened with a submenu that appears below the tag.
Comment 6 Mikolaj Machowski 2008-03-27 23:24:11 UTC
Dotan, that was one of my proposed solutions. Big drawback of this is
size of menus with wide and deep system of tags. If you create 10 top
level tags with sub-tags  it will require 20 item menu. IMO already
coded solution for KDE4 (digiKam 10) is the best.
Comment 7 Dotan Cohen 2008-03-27 23:50:48 UTC
I can only see the screenshot of KDE4, I cannot run it right now. If it allows one to choose a tag with children, without opening the subtree, then I'm all for it. The screenshot does not make it clear if this is possible.
Comment 8 Dotan Cohen 2008-03-28 14:47:22 UTC
Created attachment 24104 [details]
Two columns in rows for submenus

Perhaps there could be two columns for tags with subtags, as illustrated in
attached screenshot.
Comment 9 Mikolaj Machowski 2008-03-28 21:40:38 UTC
I doubt this is possible (not a developer though). But KDE4
implementation as shown on screenshot is similar in spirit. Don't know
if you hover only on checkbox it wouldn't open submenu. Gilles?
Comment 10 caulier.gilles 2008-03-28 21:49:04 UTC
Mik,

Currently the behaviors is the same between KDE3 and KDE4. In My screenshot posted to #3, you can see than to assign tag "Animal", you need to use "Assign This Tag" sub-menu entry.

But on the left of "Animal" entry, you have the checkbox. Currently, this one is an indicator to see if tag is already assigned. It cannot be used to assign this tag as well, but perhaps we can use it for that. This will be natural...

So the question is forked to Marcel who have re-implemented Tag pop-up menu for KDE4...

Gilles 
Comment 11 Marcel Wiesweg 2008-03-29 20:44:28 UTC
The relevant menu entries are QWidgetActions, this means there is a real QWidget which is using QStyle for 100% custom drawing.
The QMenu will close if it notices a mouse click.
We could try to use this widget to catch mouse press event, or the QMenu code is installing an event filter, in which case this might not be possible so easily.
Comment 12 Dotan Cohen 2008-12-04 19:16:21 UTC
@Marcel: If the mouse event cannot be captured to click the checkbox, then could the split view as illustrated in comment #8 be used?
Comment 13 Marcel Wiesweg 2008-12-04 22:22:39 UTC
I dont see high priority for this one, it's more for post-0.10.0.
I need to investigate what is possible wrt #11, which usually takes a bit of time and calmness.
Comment 14 Dotan Cohen 2008-12-04 23:20:49 UTC
Certainly not a high priority, I agree. But it would be a nice usability enhancement for those of us who make extensive use of tags.
Comment 15 Andi Clemens 2010-09-25 17:43:06 UTC
Closing some old bugreports that are related to old digiKam version, and that have not received answers for two years now.

If you think the reports are still valid, feel free to re-open them, but please provide updates and do not just open them without giving feedback.
Comment 16 caulier.gilles 2015-07-04 06:00:56 UTC
New digiKam 4.11.0 is available.

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?
Comment 17 caulier.gilles 2016-07-15 21:19:33 UTC
With digiKam 5.0.0, this problem is not reproducible.
I close this file now. Don't hesitate to re-open if necessary.
Gilles Caulier