[Digikam-devel] Tagging context menu

[Tina Trillitzsch]

Hi,

concerning item 1.2 ("Show which tags are already assigned") of my  
review of tagging  
(http://www.uni-koblenz.de/~trilliti/digikam_tagging/main.html),  
Sébastien Laoût mailed me to say that he is done implementing  
something similar for Basket. He attached some screenshots and the  
code (so you could use it for digikam if you like), which I uploaded  
to the web to save bandwidth.
Screenshots:  
http://www.uni-koblenz.de/~trilliti/bilder/checked_menuitems/IMPLEMENTfinal.png
Code:  
http://www.uni-koblenz.de/~trilliti/bilder/checked_menuitems/Tags-Checkbox%20Decoupled%20from%20Icon%20in%20menus%20--%20Source%20Code.txt

I'll quote the pertinent bits of Sébastien's mail here and let you  
decide if you can use his code:

> So, I've done what was wanted:
> - Checkboxes to unchecked items
> - Align non-tag menu-items icons and texts
[...]
> And some plus:
> - When the mouse is hover a checkbox item, show a blue highlight
> - Radiobutton for multi-states tags

> The 3 top screenshots show the tags adding/removal menu with  
> checkboxes aswanted, and with one item highlighted to show the  
> "blue highlight glue",consistent with the rest of KDE when  
> hovering checkboxes.
> The left one: the one I prefer.
> The middle one: with pressed-in look of checked item. I find this  
> uggly anddon't think I will include it in my program (but I  
> provide it for comparaisonand discution, and if other developers  
> want to have it in theire programs).
> The right one: with Plastik theme. So, without gradient  and as it  
> willappear on the everyone's KDE.

> The bottom ones are the same but for multiple-states tags.
> I think it's something highly BasKet-oriented.
> I don't expect other programs to use multi-states tags, perhapse  
> Tenor couldhave them for files, but I don't know.

> The top-right is for the disabled "Unassign All" (when there is no  
> tag, sonothing to unassign) I've got a lot of harm to make it  
> appears OK (and that'sstill an hack, that could be broken when  
> Plastik will fix the bugs I'veposted to them).

> I join you the source code, if you want to give it to other  
> programers.

> And I quickly looked at the style codes (sent patch for 5 bugs to  
> Plastikauthor) and yes, it's a style issue to decouple icon and  
> checkmark.
> But I'm afraid I seen no way to differenciate exclusive and  
> non-excluviechecks.
> ie. from what I've seen I see no way to determine if the style  
> should draw acheckbox or a radiobutton.
> And drawing checkboxes everytimes will be worst, usability wise, I  
> think.
> I've not looked too far, but I don't know if it's even possible to  
> know if"this menu item is not checked, but it CAN be checked, so  
> we should draw anempty-checkbox instead of nothing to tell the  
> user it will be checked onclick"...

> I think that should be thinked NOW, before KDE 4, to come up with  
> a good modelfor KDE 4.
> For example, if it's not possible, a programer should then write  
> codeexplicitly to set that an item can be checked or is in a  
> radiobuttonsgroup...
> And those things have to be done in kdelibs, so before KDE is  
> released.

Bye,
Tina