Bug 114465

hmmmmm, something like f-spot will have in the next version: http://jimmac.musichall.cz/weblog.php/Photos/Tags.php

I think this could work! 

Former kimdaba (now kphotoalbum) resolves this in an almost unimprovable way:

* you can completely configure your entry window, fields, sizes etc.
* Keyboard entry as well as mouse selection, but keyboard is much faster
* last recently used sort order for keywords as well as alphabetic sort order

I have to admit that this feature alone makes me switch forward and backward between digikam and kphotoalbum. But digikam has the better viewer.

An intermediate step could be the auto-generation of shortcuts for existing keywords, like selection of landscape in the keyword selection process through pressing 'l' or 'alt-l'. A second keypress of 'l' could select the next keyword starting with 'l' on the same level and so on.
Ideally you wouldn't have to touch the mouse after starting the keyword-adding action.

Another simple (and easy to implement) way to add tags within ImageEditor or digikam would be to add a simple shotcut to a Tag.

I use digikam to sort and order prints from my photos. In imageEditor it would be nice to press a shortcut like F8 which assigns the tag...

I'm all for free tagging. It has become so popular with blogs and online magazines and it _is_ the easiest way of doing this, combined with autocompletion and adding tags via "free typing" (in the image editor).

Plus, it saves a whole lot of GUI clutter in the main Digikam interface. And the tags can even be saved in appropriate EXIF/IPTC fields.

Jens

*** This bug has been confirmed by popular vote. ***

Still, I think the nested tags as used by digikam today should still be available. Freeform tags make it easy to accidentally create a new tag by mistyping the name of an existing one. Additionally, in a complicated tag hierarchy like the one I use, it is common for the 'leaf' nodes of the tree to have non-unique names. Since they are sub-tags of different tags, they are still distinguishable. With several hundred tags, having a hierarchy is, in my opinion, a very good thing.

One doesn't contradict the other. You can have both the hierarchy and a freeform entry, with the latter helping the former. With proper autocompletion, the problem of accidentally creating a new tag would go away (if after typing a couple of characters, one could press down and have the correct tag, I don't think anyone would try to type the whole thing and mistype it in the process). Having the parent's name listed in parenthesis after the tag name during autocompletion would solve the problem of multiple tags in the hierarchy having the same name.

In short, I think one is an issue of internal structure, and the other one is a user-interface issue, and they don't hinder each other in any way. In addition I still think that lack of freeform tag entry is currently the biggest weakness of Digikam.

I like last proposal, which is very similar to KMail's move to folder feature. When you browse e-mails in KMail, you can just press "m" key and start typing the name of folder - you get the list of folders with matching name with full hierarchy and you can use arrow keys + Enter to navigate the list and select the folder to move e-mail to.

This is often repeated wish. Creation of new tags by menu/dialog is too complicated. Even entering strings like places/city/street (three levels down) is faster then working with menu/dialog.

Main issue (IMO) is space in sidebar. Adding new inputfield would make this place really crowded. Solution could be making current Search inputfield two-state with choosing of mode with combo.

Everytime I open digikam my desire for better tagging support increases. So much that I thought of doing it myself.

This was what I was aiming at: fast tagging would be useful in icon view. So, when some icon is selected, and the user presses '/', an input box opens up below the picture in the icon. It shows the already assigned tags separated by comma. Enter new tags, separated by comma. There has to be some kind of autocompletion - maybe a dropdown autocompletion box.

(The sad part is after looking at the source files, its looks like a bit non-trivial to implement. But its definitely in my long tooooooodo list.)

I like digiKam, but it's major shortcoming in my mind, is the inability to handle a large set of tags. I tag everything. If I have a picture of John riding a sailboat in hawaii, I will tag it as "John, Hawaii, sailboat, beach, etc.." After a certain amount of photos, there are so many tags in the system that the tag menus become useless. In digikam, the tag menu is so big it won't even fit on my monitor. Tags are basically useless to users that use a very large set of tags. It works if I tag all my photos as "people, places, things" but I think many people out there use tags in a more specific and detailed way.

I want to be able to do a keyboard shortcut, have it pull up a list of keywords that the selected picture contains, and add/edit/delete them easily. It shouldn't pull up the global list of keywords in my opinion. This is how picasa does it, and it is very powerful from an organizational point of view.

If for some reason, 12 comments isn't enough sample from the community, I'd like to add one more...

I have been used to annotating my photographs. I also use IPTC tags: creator, copyright, location, city, state, country, headline/title, description and of course loads of keywords.

I had been trying to switch my workflow to completely open source software for a long time. Finally, after DigiKam 0.9, I took the decision and the plunge... it has been a fantastic experience so far. I feel much more 'at home' with PCBSD/FreeBSD and KDE... DigiKam is fantastic... with a few quirks that are tolerable. But it seems that DigiKam just doesn't want me to actually do anything useful with keywords!

First of all - the tags list is populated with hundreds of my original tags - and it is IMPOSSIBLE to select more than one and move them around - so I can't really get myself to set it up in hierarchy. Moreover - it is again very very difficult to tag a complete photo shoot withing 10 minutes because every time I want to select a specific tag, I have to first search for it... then click on the little checkbox to enable it. When a complete shoot will need about 10 common keywords and each set of photos might need another 10 individual keywords... this UI is cumbersome and unrealistic to get things done.

Freeform tagging means a lot to me. I'm installing KPhotoAlbum as I type this (got reference from a post above) only because I have this OCD for keywording all my photographs.

I really wish that the developers are able to find some time to work on this!  And I'm writing all this not because I'm pissed... but because You Rock! And you can do it! :-D

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

Another feature request along the lines of "make tagging easier"...

I find that I often use a subset of all of my tags for any given tagging session. For instance, I may have a set of photos from my son's birthday party, so first I go through and tag them all with "birthday" and "party", but then I'm down to a set of 8 or so people in varying combinations. It would be excellent to have a panel of tags in current use, ideally associated with keyboard shortcuts lie F1-F12 or Alt-1 through Alt-0. That way, as I go through the photos I could easily add those tags.

Another refinement would be to have an option to auto-populate that list with the most commonly used tags.

Yes, I love this idea! It very much corresponds to the way I do the tagging 
right now. Tagging is done  on a per album basis and
each album groups around one "event", like a birthday party, a hike, 
a day at the beach or in town etc. 

Each event has a typical cluster of tags which are appropriate. 
Therefore it would be nice if for each situation a  (pre-selected) 
collection of tags (or parts of the tag-tree) could be chosen.

- Where to put such a "Tags collection" in the GUI?
  Maybe it could be added as another TAB in the "comments/tags" sidebar?
  On the other hand, it might be better to have as much space
  as possible so that no scrolling is necessary.
  Therefore maybe another window, below the icon view, would be better,
  which could display several different tags collections
  (see the attempt of a mock-up in the following attachment)?
  Another option is to have a fully separate window in
  which the tagging is done (not sure if I like this that much).

  As usual, it is not obvious how to get this right ... ;-)

- How to populate such tags collections?
  a) Maybe the easiest is to start from one album whose images have been
     tagged and then just say: 
     "Make a tag collection out of all present tags"
  b) adding a new tag (in the usual way) would automatically
     add it to the active collection    
  c) Creating a tag collection from scratch,
     item by item, should be possible as well.
  d) Then there might be some super-intelligent pre-creation
     of tag-collections, which does a statistical analysis of
     all the tags combinations in existing albums and out
     of this magically identifies the most common clusters...
     (could be a nice Google Summer of Code project ;-).

Of course, the before disussed free-form entry of tags should
be possible as well. I.e., I don't see these ways of adding tags
as excluding each other.

(Keyboard shortcuts might be more difficult, as the simple ones
like Function keys etc. are already in use. <asbestos suit on>On the other hand,
we haven't used any emacs style keyboard shortcuts yet ;=)<asbestos suit off>)

Best, Arnd

Created attachment 22037 [details]
attempt of a mock-up of a possible layout for tags collections

>  --> (http://bugs.kde.org/attachment.cgi?id=22037&action=view)
> attempt of a mock-up of a possible layout for tags collections


Don't like it :(

I would prefer drop-down menu on top of tag tree with filters of tags
and positions:

All (default)
Col1
Col2
--------------------
Add collection...

> Don't like it :(


Fine with me, we have to find the optimal solution ... ;-)

The drop-down menu is indeed another option.
However, I am not sure what happens if there are
many collections (I can easily envisage about 20-30).
How does one quickly change between them?

The problem is, that if a collection has too many entries,
one has to scroll, which takes a lot of time.
Therefore one has to change quickly between collections,
and that's why the mock-up had several collections visible
at once.

So my main point is: tagging should be as fast as possible.
Scrolling around takes a lot of time and should therefore
be avoided. Having several tags collections
displayed at the same time would reduce scrolling ...

Still think it could be done simpler. Eg. add history to search in tags
and properly organize and name your tags. Since searching is limiting
number of tags but include subbranches it would work IMO as a charm.

Just click on dropdown menu in search box, choose Persons and you have
all tags in Persons branch, choose GeoGermany and branch with all names
of geographical locations in Germany, etc.

Additional windows (subwindows in fact) will have to be even smaller
than original tags window so there will be always scrolling

Adding a history to search in tags is a very good idea
(where would one put that? Another button?)

Concerning the additional windows, they need not be smaller,
if they are at a different place as suggested in the mockup in c#17.

Arnd,

>Adding a history to search in tags is a very good idea
>(where would one put that? Another button?) 

It's already done : look "Recent tags" on "Caption and Tags" side bar... This is the history...

Gilles

Gilles, the "Recent tags" is a different history. 
What Mikolaj suggested, if I understood it correctly,  
is to have a history for the entries used in the search field 
(even though I start to wonder
how easy that would be, because it is an incremental search box,
i.e., when should one add the text to the history?).

Arnd,

...an auto-completion mode in fact. If yes, KLineEdit widget used provide aready this feature, and of it's... not enabled by default...

KDE3 API :

http://api.kde.org/3.5-api/kdelibs-apidocs/kdeui/html/classKLineEdit.html

KDE4 API:

http://api.kde.org/4.0-api/kdelibs-apidocs/kdeui/html/classKLineEdit.html

Code is in :

http://websvn.kde.org/branches/extragear/kde3/graphics/digikam/libs/imageproperties/imagedescedittab.cpp?revision=718244&view=markup

... in constructor, you have "d->tagsSearchEdit = new KLineEdit(tagsSearch);"

This object do not have completion enable... If you want to try, it's easy...

Gilles

IMHO a few things which could be easily implemented to ease tagging could be:

- allow to tick the currently selected tag using a shortcut (for instance using the key 'space', for the time being 'space' move to the next picture).

- display the list of recent tags not as a drop down menu as it is done now but as a displayed list of the 12 most recent tags and dynamically assign the shortcuts F1 F2 F12 to assign this tag to the currently selected pictures.

Julien

>- allow to tick the currently selected tag using a
> shortcut (for instance using the key 'space', for
> the time being 'space' move to the next picture).

There could be a toggle switch on the toolbar for switching the space bar function. Actually, instead of ticking the tag, it might tick the photo, similar to BrilliantPhoto. In BrilliantPhoto one would tick some pictures, then apply the tags to the selection. It is very similar in nature to selecting photos, however not as 'delicate', in the sense that one does not need to hold down Shift/Ctrl to tick multiple photos.

>- display the list of recent tags not as a drop
> down menu as it is done now but as a displayed
> list of the 12 most recent tags and dynamically
> assign the shortcuts F1 F2 F12 to assign this tag
> to the currently selected pictures.

I like this. I really like this. I really really really like this idea.

> - display the list of recent tags not as a drop down menu as it is done
> now but as a displayed list of the 12 most recent tags and dynamically assign 
> the shortcuts F1 F2 F12 to assign this tag to the currently selected pictures. 

A dynamically changing list is bad as you always have to look up the current assignment.

But the basic idea is great!

So please implement a way for the user to easily assign (and reassign) the F-keys to any tags.
E.g: Show in the tag list behind each tag that has an assignment the current assignment. When a tag is selected and a F-Key is pressed this tag will be assigned to the pressed F-key. (Default action could show an pop up that asks if the user wants to reassign Fxy from tag foo to tag bar; using Shift-Fxy will directly assign the key to the tag without the popup)

I doubt that a list of 12 tags assigned to F-keys would really make tagging much simpler, since you would need to assign tags to keys and struggle with other programs for the control over these keys (for example F1).

In my opinion the best suggestion I have heard about so far is that described in #9, which resembles KMails nice "move mail" feature: Pressing a key, let's say "t" for "tag", brings up the list of tags. There you can select tags by either navigating with the cursor keys or - preferably - typing the beginning of the keyword and using the autocompletion feature. The prime advantage of this procedure over the current state of digikam is that you don't have to use the mouse anymore, which will speed up tagging considerably.

Just compare how fast you can rate a picture with the Strg+X keys in comparison to how fast you can attach a tag to it. I think tagging will only be fast if it is possible to use the keyboard only. To get an idea of how this works, start kmail and press "m" for moving mail to subfolders. If other people like to work with the preselected list of tags and the F-keys, this could be done as well - In fact, it might be a good idea to have different methods of tagging for different tastes.

But the procedure described here should be easy to implement since all the functionality like navigation of the taglist and autocompletion is already there. All that is needed is a hotkey to switch to the taglist such that it works as fast as in KMail ... 

I'd like to add another vote for the Kmail-style keyboard entry of tags with AutoComplete.  F1-F12 limits you to 12 or less tags (obviously!) and the dynamic assignment sounds like more hassle than it's worth.  (Where would current assignments be displayed to the user?)

The autocomplete idea is simple but very powerful - and copes with any number of tags. Note how the KMail widget refines the list of possible matches as you type - this is a great way of making even complex tag hierarchies easier to use.  It also doesn't preclude people using the mouse if they prefer. 

> x3ri7yz02@sneakemail.com  2008-01-05 17:40
> F1-F12 limits you to 12 or less tags (obviously!) and the dynamic assignment 
> sounds like more hassle than it's worth.  (Where would current assignments be 
> displayed to the user?) 

F1-F12 are only shortcuts to the (currently) most often used keys.
A way to easily assign the keys was described by me in #27. There I also described an easy way to show the user the current assignment.

But I also agree that this shouldn't be the only way to assign tags. 
(I do like the idea of just typing the beginning and working with an auto complete - the drawback here is that you must know all tags, or at least their beginning. So please add both ways ;)

I would also like to see both ways (F1-F12 && type-autocomplete). It should not be difficult to implement, and it would fit most workflows. There should be no problem with global F-key conflicts, as other KDE apps already utilize the F-keys, such as Kate, with no problems. Global F-key shortcuts are usually combined with a modifier key such as CTRL or ALT.

Another vote for keystroke tagging with some form of autocompletion. The current adaptive search works nicely, making it even more of shame to have to grab the mouse in mid operation. ;-)

For me the basics would be 1) a single keystroke command that puts the cursor in the tag search box; and 2) once the search (as currently implemented) had narrowed to a single tag, that tag could be applied with the enter key. 

In addition, implementation of shell-style autocompletion would allow zeroing in on forgotten nested tags, without backspacing.

If the above is how kmail filtering works, another vote for that please. 

I agree with #32. The desribed behaviour is basically how the kmail filtering works: One key to open the tag (i.e. mail folder structure) list, typing letters narrows down the list, and assigning is down with enter. Moreover, you can navigate the filtered list with the cursor keys, which can sometimes be faster than typing until you reach a unique tag. In any case, it is much faster than the currently used keyboard-and-mouse solution.

I'm not sure what is meant by "shell-style autocompletion" in #32, though. The kmail behaviour amounts to a build-in autocompletion: Once the letters you typed uniquely determine a single tag, this is the only tag left in the list.
So I really hope we will see this tagging mechanism, possible as an option, in a future version of digikam.

> ------- Additional Comments From gandalf.lechner esi ac at  2008-02-28 10:55 -------
> 
> I'm not sure what is meant by "shell-style autocompletion" in 
> #32, though. The kmail behaviour amounts to a build-in 
> autocompletion: Once the letters you typed uniquely determine a 
> single tag, this is the only tag left in the list. So I really 
> hope we will see this tagging mechanism, possible as an option, 
> in a future version of digikam.


Me too. My request for "shell-style autocompletion" would be of 
secondary importance to what you described (but really nice :-)). 
I was too cryptic in my description.

Scenario: The user has a large number of tags nested in a 
hierarchy. For example, one high level tag is "colour" which 
contains a "blue" which contains a "cyan". There are numerous 
other tags at each level in the hierarchy. The user doesn't 
remember "cyan" is a tag, but she/he does remember "colour".

To find and select "cyan" the user should be able to type 
"colo..." [autocomplete occurs, and "colour" and the nested tags 
below it are displayed in the Found Tags window]. If the user hit 
the enter key, "colour" would be assigned to the selected image.  
Instead, the the user types "bl.." [autocompletes..]. On seeing 
"cyan" in the now-refined list, she/he types "cy.. " [another 
autocompletion].

In short, this would allow systematic navigation to forgotten 
tags in a large hierarchy, assuming the tags are logically 
organized (we all do that, right :-)

Currently, a user can do this kind of navigation but it is 
clunky. One can find "cyan" by typing "colour" etc., but one 
needs to backspace to get rid of "colour" in the text entry box, 
then start to type "cyan". To me it would be more intuitive, and 
consistent with widely used autocompletion of directory/file 
structures (as in shells), if the behaviour I described occurred.

On the same note, it would be great if the history of recent tags 
would appear, and could be scrolled through, simply by hitting 
the arrow-up or arrow-down key when the cursor is in the search 
filter box. This would again be like bash shell history behaviour 
and so very intuitive (at least for me..). Currently we have 
access to recent tags using the button. Great feature, but it 
seems to demand unnecessary use of the mouse. Could the arrow 
keys be remapped to the tag history when the cursor is in the 
entry box?

Digikam is really great! I should add that it is the only KDE 
programme I regularly use (nothing against KDE, just my inertia 
and history) so my suggestions may be counter to standard KDE 
behaviour.

Tags seem to be one of the biggest issues I have had with digikam.  I have used picasa in the past and the tagging of images in digikam seems extremely difficult.  

The autocomplete suggestion above would be a great improvement.

The remainder of this comment is as much question as comment.

If I understand correctly from reading the IIM and XMP specifications and what information I have been able to deduce online, the tags are saved in the metadata as single "keywords" in the IMM which will translate to the dc:subject in the XMP, and the parent-child relationship of the tags is internal to the database in digikam and is not stored in the metadata? (question).

If I am incorrect in the last assumption let me know and the remainder of this comment is moot.

I have been using picasa in the past and picasa has no such parent-child relationship with the tags.  A single tag text or keyword is "unique".  The tags can be assigned to any file at any time with no relationship.  This in itself can be a major issue as the number of tags increase, up to literally thousands of keywords.  The one saving grace of picasa was already discussed here, it has the capability of allowing a typed field to assign the tags, and also to filter by tag.  This still creates a problem with different tags being assigned if the text is entered differently, for example issues with plural words and words that start with the same first few letters.

I work with 20K+ files.  With multiple tags on each file, the tags are impossible to manage.

I was hoping that the parent-child set up of the tags panels would assist me with this issue.  

I'm not sure I can see where the flexibility to set up the parent-child relationships in the tags is really useful other than as a means to organize and manage the tags. In most cases the tags I set up are a descriptive piece of information in itself.  For example I have multiple albums and a single tag, say something like "new york", is descriptive in itself.  I may have a album of photos containing photos of an event that takes place in new york, and another album with scenic photos of new york.  New york as a tag is descriptive in itself, and with the combination of tags for filtering I can get to the files that I need efficiently.

With the current database set up, this requires me to either set up a unique parent-child relationship for these photos with new york being a child in each, or completely ignoring the parent-child relationship completely and just have a huge list of individual tags, like picasa, that are impossible to manage.

One of the issues I ran into was I "moved" one of my photo collections on disk outside of digikam.  When digikam reloaded the collection, any of the keywords that did not have a complete parent-child relationship (which, ooops, as I was used to using picasa, many did not) created duplicate keywords, outside of the parent-child relationships I had already set up, so I have duplicate tags (keywords) everywhere. 

Allowing the tags to be unique, is one possible solution I might suggest.  

If there is a use for the parent-child relationships that I am missing, possibly just allowing a flag, internally within the program settings and/or tied to the keywords in database, to flag the tags as being unique or not.  

Allowing tags to be unique, when files are imported into digicam, it would find existing tags within the database (similar to what picasa does) and just link the metadata tag to the existing tag in the database.  this would allow the tags to be grouped together by "dummy" tags as parents.  You could to set up parents something like "locations", "events", etc., then all the relevent tags could be grouped as children under those tags.  As the child would be unique, the parent tags would not have to be assigned as tags in the metadata.  

Currently the only way to group these types of tags together requires that all the parents of each tag also be tagged in the metatdata of the file.  Additionally If importing a file into digikam that already has existing tags, but may not match the current parent-child schema that I had set up, it creates duplicate tags, making the tags even more unmanageable.

Stop... (:=)))

This entry is full of ideas but not very constructive as well. For a developper, it's very difficult to handle all entries it and make the best solution for all.

To resume: a lots of ideas here are posted at the wrong place. 
For ex. using Keyboard shortcut ==> http://bugs.kde.org/show_bug.cgi?id=149007.
And there are certainly others one.

I will be more explicit here. The real subject of this file is "_Simpler_ entry of tags". For me make an a tag entry is to create new tags, not to assign already existing one. This is completly different, and here shortcuts for tags will be the ultimate solution.

To make a simpler entry of tags (as Create New Tag), i propose to patch 2 parts in digiKam to provide the same entry logic : 

1/ Create New Tag dialog.
2/ Captions & Tags right sidebar.

For 1/, in "Title" field, i propose to use "/" as separator to create new hierarchy from current selected tag:

"France/City/Paris"

If you use "/" in first, hierarchy is created from root tag album.

This is want mean than "/London" is a simple new tag created from root tag album.

For 2/, we have already the search text field in Caption & Tags side bar. I propose to add a new bi-states button just on the left side to toggle text field as:

- Search text engine (working like current implementation).
- Create new tag entry (using the same logic than for Create New Tag dialog)

What do you think about ?

Gilles Caulier

I'm not sure why you say this is not constructive. Even if you ignore (in my opinion a rather productive brain-storming discussion that follows) the original bug report proposes a very simple solution (it doesn't get any more constructive). Essentially the same idea is implemented for Flickr on http://smark.us --- and it's by far the best way of tag entry I've seen.

What I suspect you are alluding to is that what you propose is considerably easier to implement than what's been requested (and voted for). That may be the case, but that's really the question of choosing programming ease over usability. You seem to prefer the former, I think the latter is more important. Of course, given that I'm not the one implementing it, I have no real say on the matter. 

By the way, to clarify what I don't like about what you propose: tagging photos would still require using the mouse. What I really want is the ability to tag photos using only keyboard. This would make it much simpler to go through tagging a large batch of photos.

Best,
Dmitriy

Gilles,
I think it is not really possible to separate the discussion about how to CREATE tags from the discussion about how to ASSIGN tags because actually some people think both features should be implemented the same way by just typing the list of tags as in Flickr.
About #1 (use / to separate levels): seems fine to me
About #2  I think the bi state button is hard to use.
I would prefer that if one type a tag in the search field Digikam update the tags list as it is currently implemented, but if there is only one possible tag then if you press enter it assigns the tag. If you type a tag which does not exist then it creates the tag when you type enter.

Best,

Julien 

To Dimitry, #37,

As lead developper, i can said than if all ideas are mixed up at the same place as well without a real shorting issue, the bug will be never fixed... because time is limited to read a very long thread. This is not the only one entry in B.K.O in this case...

About "choosing programming ease over usability", this is not true. I know very well the digiKam code and i can judge what we can do to solve this issue without to break stability of code. Users to not have this vision... And stability is _always_ preferred than all others point... 

To Julien, #38:

"About #2, I think the bi state button is hard to use."

==> no. you toggle the button to edit mode to create new tag and you still in this mode until you toggle button again to Search mode. You can edit more than one tags like this.

The advantage is to have a non-bloated interface like Mik said previously with a complex interface to create new tags...

Gilles Caulier

To Julien, #38: 

"I think it is not really possible to separate the discussion" ==> From a developper point, we have 2 subjects which will be fixed by 2 separate issues.

Gilles Caulier

I admit don't exactly remember what I was thinking proposing mode
button.

I think it was some time before and interface was looking slightly
different - less crowded around search widget.

My current proposition with input from further discussion:

Add another textline for creation and assigning of tags. Yes, it will
crowd interface a bit but button will do the same. Also textline widget
you could add on top of tree widget separating it from the rest. New
button had to be with search field adding another widget to already
really crowded area. OTOH another widget... I think most important thing
reading another comments is to remember about good keyboard navigation.
If you will be able to fast switch modes without use of mouse it will be
"good enough".

Since we have separate, one-state widget how we should treat text
inserted there? Example:

Marta, /Holidays/London 2007

Split this entry with , and trim space. There are now 3 tags:

Marta
/Holidays/London 2007

This should create or assign if they already exists these two tags. One
thing I am not sure is how to treat entries without full path. Should
"Marta" be put in top level? If not how to determine current working tag
;) I would think treat it as top level and don't play with "current
working tag". With drag and drop of tags in tree you can easily
rearrange tags into proper places in hierarchy.

Gilles, I think that the solution that would make everybody happy would be to use the Kmail-style autocompletion (in Kmail it is for moving to folders, but same idea). This could be used for both assigning old tags, and for creating new tags. As an added benefit, UI consistency with another KDE app (Kmail) will be achieved, making KDE a more unified environment.

I agree with Mikolaj, "Add another textline for creation and assigning of tags" seems to me to be a nice and simple solution.

@#42: Yes, that's the way to go! In my opinion, _creating_ tags is not the issue, its all about _assigning_ tags to pictures.

To Arnd, comment #23 :

Auto-completion is now implemented in svn, with revision 791098. If you type a text in Caption & Tags search text bar, digiKam will completed automatically with the tag name witch match all know tag titles from database.

Notes : 

- I have also implemented the auto-completion with all other Search Text bar from all folder view (Albums, Tags, TagsFilters, TimeLineSearch, and Search).

- StatusBar Search Text Bar auto-completion is not yet implemented. Still todo...

Gilles Caulier

Created attachment 24102 [details]
Moc-up of Caption & Tags right sidebar including line to create Tag

To Julien #43,

here a moc-up of Caption & Tags sidebar including a new Line Edit widget
dedicated to Tag Creation.

The new line edit is just behind Tag tree view and a button to valid entry is
placed on right side.

The layout is fine for you ?

Marcel, 

...give me your viewpoint please...

Gilles Caulier

Gilles, 

The mockup looks very nice ! thanks for the hard work.

Do you plan to implement only tag creation of alos tag assignement  using this text field ?

If you choose to implement both maybe I would be better to display "Enter tags here..." instead of "Enter new tag here..."

Best wishes,

Julien

Fabien,

"...tag creation of alos tag assignement"...

I don't understand this sentence (:=)))...

Gilles

It's not me ;-)

(:=)))

Julien, Fabien, sound similar...

Gilles 

Sorry I meant "Do you plan to implement only tag creation or also tag assignement  using this text field ?"

Julien

I think Julien was thinking about:

Do you plan to implement only tag creation or also tag assignment using 
this text field?

If you choose to implement both maybe ut would be better to display 
"Enter tags here..." instead of "Enter new tag here..."

----------------------------------------------------
Niezwyk

Well, i plan to use this line edit for tag creation i a first time.

For Tag assignamen, keyboard shortcuts rock. Look in Kmail, you can assign a shortcut to a mail folder to speedly move a new mail to a repository. This is exactly what we need.

Gilles

Created attachment 24106 [details]
Tag creation from Caption & Tags sidebar (patch #1)

First version of patch against KDE3 svn implementation to solve this issue.

Enter a new tag in text filed and press return. Tag is created as well from
root tag album. 

Note than text field still in focus after creation and content is cleaned. You
can make new tag again without to use mouse...

TODO: 

- a tag text field parser to handle tag hierarchy delimited with "/".
- multiple creation of tags at the same time using " " separator.

Gilles Caulier

Ad c#53: Surely, keyboard short-cuts will be essential.
Still, I am wondering, on how many short-cuts one may define,
so that it is still useable:
a) how many keys/key combinations are still available?
b) how many short-cuts can one memorize?
Maybe for b) having the short-cuts behind the tags names would help.

In addition, I still think that Mikolaj's variant #c18 of #c17, #c16 and #c15
would be extremely helpful...  

To Arnd,

There is no limit. Shorcuts are hosted in memory as KAction. The only limitation is about keys combinaisons depending of already assigned keys as shortcuts by the application and by KDE.

Look in Kmail folders properties. You can assign a shortcuts to move new mail directly in a folder...

Gilles Caulier

Created attachment 24107 [details]
kmail folder/shorcut assignement screenshot

Created attachment 24109 [details]
Tag creation from Caption & Tags sidebar (patch #2)

2nd version of patch against KDE3 svn implementation to solve this issue.

There is a new tag text field parser to handle tag hierarchy delimited with
"/".

Note: if hierarchy start with "/", tags hierarchy is created from root tag
album, else current tag selected in folder view is used instead.

TODO : to be able to create multiple tags hierarchy at the same time using " "
separator.

Gilles Caulier

To all in this room,

If i use ' ' (space) as tags hierarchy separator, we will have a problem with tag names composed by more than one words.

As Mik said previously, it will be more fine to use another special character, like ','. So if we enter this string :

"/France/City/Paris,/GB/City/London"

... we will have 2 hierarchy created from tag root album : one starting by France and another one by GB.

Your viewpoints ?

Gilles Caulier

Instead of "," as a deliminator, I propose ", ". This will be consistent with email address delimination.

Mik, Arnd, Gerahrd, Julien, Fabien,

What do you think about Dotan proposal ?

What other photo-management programs use ?

Gilles

Created attachment 24111 [details]
Tag creation from Caption & Tags sidebar (patch #3)

3th version of patch against KDE3 svn implementation to solve this issue.

Text field parser now can handle multiple tag hierarchies delimited with
",".

Please test this patch indeep before than i apply it to svn...

Gilles Caulier

No comments on patch itself, still compiling.

1. Don't agree with Dotan's proposal. ", " is too strict, requiring of
   whitespace for such casual thing is hard to remember.
2. I think that this field should be used also for assigning of existing
   tags. We have 3 possible scenarios:

   a) user wants to create new tags; focus onto new widget, type
      string of tags, all are created - wonderful
   b) user wants to only assign existing tags; uses shortcuts or dialog
      like as message moving in KMail - wonderful (with caveat*)
   c) user wants to create new tags AND assign existing - for such basic
      functionality (s)he has to perform functions in two different
      interfaces - not so wonderful, frankly - far from it; with use of
      new widget for both actions it will be simple and fast

   * caveat for KMail moving dialog - only one tag at the moment; for me
   it is major one - for whole time evolution in tag assignment was
   going to speed up assignation of multiple tags, now we are
   introducing completely new interface which is committed for doing one
   thing at the time

   Judging by myself, after several months of use, there will be core
   foundation of tags used very often and probably one or two new for
   importing session of describing of 100-200 pictures.

One comment about shortcuts. Yes they are theoretically unlimited, but
practically they are *very* limited. Many Ctrl-x (x as "something", not
literally) are reserved for global actions, many Alt-x are reserved for
hotkeys or even input of regular charactes (think AltGr), besides
- together with Ctrl-Fx and Alt-Fx will be probably reserved for custom
global task of user (and last two are not very convenient).
Alt-Ctrl-x shortcus are only for people with big hands.  So, practical
reserve of keyboard shortcuts is limited.

If digiKam migrate to system of one key shortcuts (like GIMP, Inkscape)
it would change situation but only marginally. With one key shortcuts
modus operandi is: one hand on keyboard, one hand on mouse. With such
setup number of combined shortcuts you can comfortably execute with one
hand also isn't big.

Thanks for the feedback Mik. I will commit my patch to svn.

I have take a look into KMail to see how folder shortcuts is implemented: it's not too complicated and i will do a similar implementation into digiKam core.

About one key shortcut for tag, are you sure than it's currently impossible to do it with KDE3 applications ?

Gilles

SVN commit 791266 by cgilles:

digiKam from KDE3 branch : Caption & Tags sidebar tab : add new text edit field to create new tags in database
CCBUGS: 114465
TODO: KDE4PORT


 M  +88 -11    imagedescedittab.cpp  
 M  +2 -1      imagedescedittab.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=791266

SVN commit 791285 by cgilles:

backport commit #791266 from KDE3 branch
CCBUGS: 114465


 M  +92 -13    imagedescedittab.cpp  
 M  +2 -1      imagedescedittab.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=791285

> About one key shortcut for tag, are you sure than it's currently
> impossible to do it with KDE3 applications ?


I can easily assign any KAction in shortcuts configure dialog to single
letter and it works. For hardcoded shortcuts try jk and JK in Konq :)

Mik,

Then, for me, there is no limitation to use Keyboard shortcuts with Tags as well...

Gilles

I tested the new text edit field. It works nicely, thanks Gilles.

Except this :

if you type tag1, tag2 it creates a tag2 with a space in front, I think the space should be ignored.

Concerning the syntax for multiple tags entry there are several options :

#1 : Use ',' as a separator, assuming ',' is forbidden in tags. I think the spaces after each ',' should be ignored.

Example:
tag1, the tag2 

produces "tag1" and "the tag2"

#2 : Use ' ' as a separator, assuming that if the user wants a space inside a tag, he puts the tag between quotes.

Example:
tag1 "the tag2"

produces "tag1" and "the tag2"


Arguments:

#1 one does not have to know about the quote trick
#2 one does not have to know about the ','

Flickr use #2.



Concerning where the tags are created in the tag tree:

Currently the tags are created as a child of current selection.
This means that if you type tag1 enter then tag2 enter you get tag2 as a child of tag1.

I am not sure that this behaviour should be kept.

There are several possibilities :

#t1 Create tag as a child of current selection, newly created tag gets the selection. (Currently implemented).

This means that if you type tag1 enter then tag2 enter you get tag2 as a child of tag1.

#t2 Create tag as a child of current selection, assign the tag but do not change the selection

Example: if you type tag1 enter and tag2 enter, it creates two tags as child of the current selection.

#t3 Create tag as a child of root by default. If one wants to create a tag in a subtree he has to use the "/tag1/tag2/tag3" syntax. We could also invent a syntax to mean current selection, for instance @/tag1 would create a child of current selection.

Example: if you type tag1 enter and tag2 enter, it creates two tags at the root level.


#t3 seems to be a good option because it is easy to grasp for first time users. 
Tags are created at root level, if one want to organize them in the hierarchy one can use the mouse.

#t2 is easier to use for doing complex thing

Best,

Julien

> if you type tag1, tag2 it creates a tag2 with a space in front, I
> think the space should be ignored. 

Yes, leading and trailing spaces should be ignored.

About "," vs. " " as separator:
maybe one could use both at the same time, i.e.:
if a "," is detected: #1 applies. If a "
is detected, #2 applies?
(Or make this configurable?)

Concerning the place where tags are created:
The advantage of #t1 is that one visually sees
where a new tag is created.

I don't like variant #t3, but this
could be made a configuration option?

(BTW: Excellent overview, Julien!)

Concerning tag assignment using text field, consider the following tag tree:

people -> family -> peter jane bob
       -> friend -> bob alice


I think if one types a tag which appears already in the tag tree and which appears only one time (example: alice) it should be assigned even if one did not type the full path.

I am concerned about tags which appear at two places (example: bob).

Then what should be done ?
- ask the user which "bob" ?
- assign both ?
- ... ?

I suppose if the text field is used for both tag assignment and creation then a different color should be used for existing tags and newly created.

Julien 

> About "," vs. " " as separator:
> maybe one could use both at the same time, i.e.:
> if a "," is detected: #1 applies. If a "
> is detected, #2 applies?
>(Or make this configurable?)

These two option are not really  deeply different, so I think this should not be an option.

From usability point of view it is better IMHO not to have too many options.
From implementation point of view as well ;-)

>Concerning the place where tags are created:
>The advantage of #t1 is that one visually sees
>where a new tag is created.

I think in #t2 one visually sees as well because the selection is still displayed, it is just that the selection is not moved to the newly created tag.

I guess the current behavior #t1 (vs #t2) is just a random consequence of the implementation.

Julien

To Julien #69:

>Concerning where the tags are created in the tag tree:

>Currently the tags are created as a child of current selection.
>This means that if you type tag1 enter then tag2 enter you get tag2 as a child of >tag1. 

No. 

- If no tag album is selected in tree view root tag album is used as parent.
- If root tag album is selected in tree view root tag album is used as parent.
- If a sub-tag album is selected in tree view this tag album is used as parent.
- And the most important : if you use a '/' as first char of a tags hierarchy, root tag album is used as parent.
- If there no '/' as first char, current tag album is used as parent.

Ex: "/Country/City/Paris" ==> will be created using root tag album as parent.
    "This/is/Another/one" ==> will be created using current selected album in tree-view as parent.

Like this, all cases can be done from user to create new tag hierarchy.

Gilles

SVN commit 791367 by cgilles:

strip white-space at bigen/end of tag
CCBUGS:114465


 M  +1 -1      imagedescedittab.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=791367

Julien,

Checkout svn. white-space are stripped at beginning and end of tag strings...

Gilles

To Gilles in #73: Julien is right:
if you type (any place, root or sub-tag, does not matter):
tag1 <return>
tag2 <return>
you get 
  - selected_tag_when_you_start_adding_tag1_and_tag2
    - tag1
      - tag2
I.e. tag2 is a subtag of tag1 and not of selected_tag_...
(i.e. case #1 above)

1. Julien is right: When I create tag One<Enter>, digiKam creates tag
   One and focus on it. It means if I type Two<Enter> Two will be
   created as subtag of One - in other words it will create hierarchy
   One->Two. Not necessarily bad thing but:

   Problem is not with high level tags at root hierarchy but with those
   nested deeper. Solution would be introduction of basic keyboard
   navigation for tag tree *without leaving focus of text widget*. For
   example Alt-Left is moving focus one level up, Alt-Up moves one tag up,
   Alt-Down moves focus one tag down.

2. This is keyboard driven widget, there must be a way for giving focus
   to it with keyboard. Label (one letter would be enough) with hotkey
   is obvious solution.

3. When I enter tag which already exists digiKam gives me message "Tag
   name already exists". a) I think this widget should also assign
   already existing tags b) if there is was given more than one tag eg,
   "One, Two, Three" there is no way to tell which tag wasn't assigned.
   Message should be changed to "Tags already exist: <tagnames>"

4. When I have tag "/One" (in root level) and want to create new subtag
   with command "/One/Two" digiKam refuses with "Tag name already
   exists".

Very good feature but it requires a bit of polish :)

With revision #791391, new tag created do not take focus.

Gilles

Tested revision #791391, this solved the problem of the focus.

There is a small issue about tag unselect. 
Scenario:
click on a tag -> the tag is selected.
click on the white space under the tag tree -> the tag is unselected but has focus
click on the tag text edit -> the text edit gets the focus
type a tag name
the tag is created has child of a tag which does not appear to be selected.

I think there is a confusion between "focus" and "selection" the tag creation mechanism takes into account focus.

Julien

Comment on attachment 24111 [details]
Tag creation from Caption & Tags sidebar (patch #3)

code is now in svn

To julien #79 => fixed with rev. #791417

Gilles 

Two more points about the new tag entry field:
a) For /known_tag
   /kno<TAB> should complete to /known_tag.
   It would be even better, if for

     /tag1
     /tag2 
     /tag3
    
   typing /t<TAB> will show  /tag
   and another TAB will show /tag1
   and another TAB will show /tag2
   and another TAB will show /tag3
   (i.e. cycling through the tags which are available)
   (This is a bit in spirit of c#32).
   Is this something which in princple could be done with the 
   completer?

b) After adding a new tag,
   "Revert all changes" only unticks newly created tags,
   but it does not remove them.
   Well, it was never the case so far, and it is disputable, if
   we want to do this. 
   However, with the new mechanism it is pretty easy to add
   several tags in one go, and maybe accidentally at the wrong place.
   So a quick undo might be more necessary than before?
   ((For me this is not a show-stopper, but I wanted to at least
   mention it ;-))

SVN commit 791545 by cgilles:

digiKam from KDE3 branch : Captions & Tags: Create New Tags line edit now support auto-completion.
CCBUGS: 114465


 M  +4 -0      imagedescedittab.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=791545

SVN commit 791558 by cgilles:

digiKam from KDE3 branch : Caption & Tags: Create New Tags text field : 
- support tags path as with autocompletion (not only tags name)
- new rule in tag hiearchy parser to do not show an error message if tag already exist.
CCBUGS: 114465


 M  +25 -4     imagedescedittab.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=791558

Mik,

Can you test current svn implementation ?

- Auto-completion is supported for tags creation.
- if tags already exist, now error message is show... but tag is set to current image selection.

Gilles

> - if tags already exist, now error message is show... but tag is set to
> current image selection.


Don't understand you here. It works as I dreamed :) New tags are
created, existing ones assigned. Great!

OK, there is bug:

/Europe  is created
/Europe/France is created

but

/Europe/France/Paris isn't created while if it already exists only
/Europe is assigned. Completion works, so digiKam is "aware" of
existence of complete hierarchy.

also

/Europe/France isn't assigned if it already exists - only /Europe.

Mik,

> - if tags already exist, now error message is show... but tag is set to
> current image selection.

==> no error message is show... i want mean. I'm a little bit tired

I will take a look about others point that you have just reported.

Gilles

Mik,

Fixed with rev. #791762. Try again (:=)))...

Gilles

SVN commit 792122 by cgilles:

digiKam from KDE3 branch : Tag Edit Dialog is now the common implementation for simpler and fast Tags hierarchies entry.
- Dialog is now redesigned. There is new text to guide user for fast tagging creation.
- In this dialog, the rules are the same than Caption & Tags create new tags field.
- Dialog includes several static methods to create TAlbums and show errors if creation fail.
- Tags Folder View, Tags Filter View and Tags pop-up menu use these new static methods.
CCBUGS: 114465



 M  +163 -15   digikam/tageditdlg.cpp  
 M  +17 -1     digikam/tageditdlg.h  
 M  +7 -10     digikam/tagfilterview.cpp  
 M  +7 -8      digikam/tagfolderview.cpp  
 M  +5 -9      digikam/tagspopupmenu.cpp  
 M  +25 -80    libs/imageproperties/imagedescedittab.cpp  
 M  +2 -4      libs/imageproperties/imagedescedittab.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=792122

Mik, Gerhard, Arnd, Fabien,

To simplify source code, i have factorized several parts with commit #792122 and redesigned the Tag Creation dialog used everywhere.

Please tests tags creation in all possible cases, especially from Tags Folder View, Tags Filter View, and Tags pop-up menu.

Thanks in advance

Gilles Caulier

TODO: Next stage is about to use keyboard shortcuts with Tags. After that, i will close this file...

Created attachment 24136 [details]
New Tags creation dialog

Great Gilles ! you program almost quicker than I can compile...

Tested revision 792130 :

- the completion does not take into account the current selection, completion is always computed with regard to the root

- completion proposes a solution even if it is not unique (it gives the first solution), I think it should wait to have enough letters

- pressing the tab key does not complete current word but move to the next widget, maybe it shouldn't ?

Best,

Julien

To Julien #92,

>- the completion does not take into account the current selection, completion is >always computed with regard to the root

yes. more complicated to do. in my TODO list.

>- completion proposes a solution even if it is not unique (it gives the first >solution), I think it should wait to have enough letters

yes. idem.

>- pressing the tab key does not complete current word but move to the next >widget, maybe it shouldn't ? 

For this point, the issue come from KDELibs KLineEdit API which only support "end" key to complete strings (i'm not sure, but i haven't found explanation in KDE source code).

Also, unforget than TAB is used in GUI to change widget focus. It's incompatible with shell auto-completion rule.

Try to change auto-completion mode by line edit pop-up menu. There is combo box mode which is interesting to use.

>Try to change auto-completion mode by line edit pop-up menu. There is combo box mode which is interesting to use.

Ok thanks I was not aware of this menu.

Dnia Monday 31 of March 2008, Gilles Caulier napisa

> Fixed with rev. #791762. Try again (:=)))...


Works as charm :)

*cough* small interface issue: when leaving tagging widget with tab
after writing in some text this text isn't removed. Works OK if nothing
was written. It works properly of course not assigning/creating any tags
just this small usability problem.
-------------------------------------------------------
Reposting to bugzilla

I vote for "Dropdown menu".

Julien

To Gilles, c#93:

> Also, unforget than TAB is used in GUI to change widget focus. It's 
> incompatible with shell auto-completion rule.

So what is then used in the GUI?
(I never use TAB for anything else than completion ;-)

> Try to change auto-completion mode by line edit pop-up menu. There is combo 
> mode which is interesting to use.

It would be nice if this setting (for all the different
text entry fields) would be saved.

Then two issues, one minor, and a more serious one:
- on startup, all entries for the 
  right "Captions/Tags" sidebar are de-activated
- For tags filtering: If you have
    - 000
      - High Stone
      - High Dune
   Typing "Hig" only shows "High Stone"
   deleting the "g", in addition reveals
   "High Dune"
   It should always show all matching ones.
   (I am not sure whether this was introduced with the last patch; somehow
   it could be that this is there already for a couple of revisions ...)

> > Also, unforget than TAB is used in GUI to change widget focus. It's
> > incompatible with shell auto-completion rule.
>
> So what is then used in the GUI?
> (I never use TAB for anything else than completion ;-)


End in KDE. Somtimes in other programs Enter is used.

Technically Tab key presses could be caught by reimplementing QWidget::event() (see docs of QCoreApplication::notify()). Unseen technical difficulties left apart, the question is if this violates GUI guidelines etc.

To marcel #100:

In fact, I think there is no need to do something about the tab key because if you choose the right completion mode (list) then the tab key is taken into account by the widget.

Julien

Arnd, what exactly is your problem? Automatic completion behaves in this
dialog  as in other KDE apps. Tab accepts current suggestion AND moves
to next widget. Breaking this would be really, really bad.

At the moment there is problem  because digiKam doesn't remember setting
of completion type.

Mikolaj: if I use drop-down, everything works fine
(I can't compare to other KDE apps, because I don't use any, 
at least not at this level ... ;-).
So once the completion type is saved, everything is fine with me.

(So the only problems I see are the two issues detailed in #c98).

I really like the new way to enter tags, but it is still a little bit complicated and sometimes confusing.
When I have a hierarchy like this:
    Persons
        |- A
        |- B
        |- C
    Places
        |- X
        |- Y
        |- Z
and try to assign the Tag 'A' to a picture, I have to write 'Persons/A' into
the line edit field, otherwise it won't be found. It would be easier to just
type 'A' like in the search field to enter a new tag.
Also when trying to add more than one tag separated by a comma, auto completion
won't work anymore.
If I have selected a tag in the tag-list window, entering 'Persons/A' into the
new tag field will add a new hierarchy under the selected tag. This is strange
because if auto completion is looking for tags, it normally should not complete
the term 'Persons/A' while the tag is selected? It should only complete this
term when entering '/Persons/A'?
One other thing: If I type '/Persons/A', two tags are assigned to the image:
'Persons' and 'A'. But when I select the tag 'A' from the tag-list window, only
the tag 'A' is assigned which is the way I want it. I normally use the hierarchy
only in digikam to have things structured, but I don't like having this
structure assigned as tags to my image. Maybe it is just me but I think a lot
of people order their pictures this way.

So my suggestions would be:
* auto completion for entering new tags should work recursively (type 'A' and find the tag '/Persons/A')
* auto completion should work when entering many tabs (separated by commas)
* when entering a tag already assigned, it should be removed from the image (toggle function)
* maybe only the last tag in a hierarchy like '/Persons/A' should be assigned

I know it is not easy to implement something like this and I'm really not the
one to complain, I'm just a normal user, but I think this could really improve
the speed of adding tags. Because now I'm only creating new tags with this
dialog, already existing tags are assigned by filtering the tag list window and
than clicking on the tags with the mouse, this is a huge slowdown.

Digikam is my favorite KDE application, but assigning tags is still a pain... I
really like the way it is solved in F-Spot, you just type while viewing the
image in fullscreen (if you want to) and auto completion also works when
assigned more than one tag separated by commas.

Another suggestion that may be mentioned before, but the thread is so long I
didn't read everything.
Maybe it is possible to combine the new create tag field with the search tag
field below? So when typing a tag that is not found by the filter, it is
created when pressing <enter>, otherwise auto completion will filter the tag list window like it is
done right now. You than can move through the filtered list with the cursor
keys (up and down) like in kmail other users mentioned before. When hitting
<SPACE>, the tag will be assigned.
For example you have a tag hierarchy like this:

Persons
    |- Peter Brown
    |- Willi Brown
    |- Marta Brown
    |- Andi Brown
    |- Peter Smith
    |- Willi Smith
    |- Marta Smith
    |- Andi Smith

Now you want to tag an image of a family meeting. All Brown's are gathered in
this image. You type 'Brown' into the search field, only the 4 tags above are
displayed. Now you can move the up and down cursor to select the tag and hit
<SPACE> to assign it. By pressing <CTRL>+<BACKSPACE>, the search field is
cleared again and you can type a new search criteria or even a new tag that
should be created.

Pressing PAGE UP and PAGE DOWN should navigate through the images (like it is
done right now) and the cursor should stay in the search field (what is not
done right now). So you can assign, create and remove tags just by using the
keyboard. If you want to, you still can use the mouse so I guess this is a good
compromise. I think the two fields that we have right now are a little bit
confusing, combining them should not be too hard (ok I don't know but it sounds
like it is possible to do) and really help in assigning tags.

Andi

Created attachment 24885 [details]
screenshot: kmail move mode showing dynamic filtering

Sorry to add again to this long report.  There seems to be some agreement that
Kmail-style keyboard-based tagging would be a good thing for Digikam tagging. 
But after reading this through, I think one thing needs clarifying: in Kmail
there are two ways to move messages into folders:
 
1. Keyboard shortcuts.	Works by assigning a specific keyboard shortcut to an
individual folder (Gilles has posted a relevant screenshot here: 
http://bugs.kde.org/show_bug.cgi?id=114465#c57 )   

2. A more general "move mode".	By pushing "m", Kmail presents a list of
available folders. This list is dynamically refined as the user types, to show
matching folders. The arrow keys then move only between matching folders.   

I didn't see a screenshot in this BKO report for (2) and so have included one
here. The image attached shows the window presented by Kmail when you push "m"
for "move".  

I think some people in this BKO report are talking about (1) and some people
about (2).  I would like to see Digikam use something similar to (2) as a
keyboard method for assigning tags to images.

This would allow rapid tagging with several advantages:
- entirely keyboard based (mouse optional)
- a single shortcut to remember (eg "t" for "tag" or something)
- very quick access to tags, for tag lists of any size

In contrast, method (1) would require you to assign (and remember) a different
shortcut for each tag....  While this could be useful for some very commonly
used tags, I don't think this is a usable solution for the general problem of
tagging images.

If I've misunderstood and everyone was already talking about (2), then
apologies in advance...

To tauri from #106,

Thanks for the report. I will use your comments when i will start Tags Keyboard shortcuts implementation. It very usefull...

Gilles Caulier

Very agreed with Andi in comment 105 (now that I finally have 0.9.4 - I've made a PPA for it in Ubuntu 8.04 - see https://launchpad.net/~davidf/+archive if you're interested)

I really like the way that the tag search now autocompletes with available tags. However, I can't find away to actually apply those tags using the keyboard, so a lot of the gain of this is lost. Also, having a new tag automatically assign the parent tags seems wrong.

My wife has been using Facebook's tagging and she finds it very simple (although it has some bugs) - you go into tagging mode, click on the photo, start typing and a dropdown is filtered with names etc.

Simplest first step for digikam I think would be:
 * Enable keyboard shortcut to enter the tag search text box
 * Highlight the first visible matching tag while in tag search box
 * Enable keyboard shortcut to select/deselect highlighted tag while in tag search box
 * Enable keyboard shortcut to apply the first matching tag

I would suggest that there could be a control bar with 10 buttons that can be specified to most used tags. Then make it easy to make different sets of buttons you can save and edit.

To even speed the use you could assign keyboard shortcuts to the buttons. Lets say i have one set of buttons that has people and a second with places. First i select the people and use keyboard shortcuts like Ctrl+1, Ctrl+2 and so on for the buttons. Then i change the set of buttons to places and use the same keyboard shortcuts for the buttons that now have different meaning.

Easy and simple to use!

A similar idea is used in Aperture and can be viewed here
http://speirs.org/2008/04/12/129/
And here: http://www.apple.com/fi/aperture/tutorials/#organizecompare-keywords

> I would suggest that there could be a control bar with 10
> buttons that can be specified to most used tags. Then make
> it easy to make different sets of buttons you can save and edit.

In Bug 144179 it was suggested that the tagging menu only present the most recent / most popular tags in the Tags menu item. While that suggestion would not solve the problem of that bug, it may address your suggestion.

Here's a proposal that would be fast and discoverable for the following use case:

What I usually do is add the same tag multiple times to multiple photos. So, the way to minimize the number of clicks is the following:

- after I add tag "x", the drop-down menu is extended with entries "Add tag X", "Remove tag X" (or even "Add/Remove tag X", see below for the reason). Same if I just create a new tag.
- If I add another tag by selecting it from "add tag" item in the dropdown, the "Add tag X" entry is switched to the new item.
- A simple shortcut (something like 't') is added automatically, and shown in the menu.

This way, the sequence of actions for adding 10 instances of tag "x" would be: 3 clicks to select tag for the first time (or to create one), and then 10 keypresses to add them to the selected photos. This is, as opposed to 20 or 30 additional mouse clicks for the same.

Thinking of this, the same result is probably achievable by just selecting all the necessary photos and then adding the tag to all. The only problem with this is that the selection is a fragile thing - it is too easy to reset, and then the process will have to be started over. So maybe a better overall solution would be to make the selection more reliable, for instance by adding undo to selection changes.

Consider the following implementation: when a selection is changed too drastically (e.g., more than 5 photos are changed from selected to deselected and back), a label with "undo selection change" button appears at the top of the window, similarly to how gmail interface operates, and the button automatically fades out after 10 seconds.

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

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

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

A few weeks ago I posted similar suggestions to the mailing list
(http://mail.kde.org/pipermail/digikam-users/2010-May/010452.html)

I'd like to add a minor suggestion
Instead of opening new report for it, I think it's valid to add it here:

A shortcut to reset focus location in the tags tree would be useful to.
It is annoying to remember before adding new tags if another tag is was selected
or the root node has focus, so new tags can be added directly below the root.

Marcel,

What do you think to store tag keyboard shortcuts to DB Tags table ? Like this, all is hosted at the same place. Moving a DB from computer to another one, no keyboard shorcuts is lost.

Gilles

The autocompletion in the tag text entry box in 1.7.0 really works great, but what I am badly missing is the ability to focus on this box via a keyboard shortcut, in order to allow quick tagging of many photos purely from the keyboard (i.e. completely mouse-less).  Surely this would be easy to add?  Thanks ...

Marcel,

There is already a list of existing Tags properties to patch ? I would to use "KEYBOARD_SHORTCUT" as new property name... Currently, it's hardcoded in TagsActionMngr class. It's better to factorize definition of properties names in an header file.

Gilles Caulier

Yes, there is the TagPropertyName namespace in libs/database/databaseconstants.h for such constants

Yes Marcel, i discovered myself the enum...

Tags shortcuts is now implemented to 70% on branch. You can assign a shortcuts via tags edit dialog. If you press shortcut keys, a signal is fired but not yet connected to GUI. Look debug message in the console.

In fact, the pending problem is : how to handle shortcut action with right GUI. Tags Action Manager is a singleton, initiate at digiKam starup from digikamapp.cpp. We must manage this signal if AlbumGUI, or ImageEditor, or LightTable are active and are visual focus on screen.

My idea, when signal is fired, is to check which active windows have focus and get lead windows instance accordingly, using dynamic_cast. After that, i call the right method to get which image item have the focus, from icon-view, or editor canvas, or light table preview, and assign tag as well.

What do you think about ?

Gilles Caulier

Yes, sounds all right.

There is QApplication::activeWindow to get the active top-level window.
There is also QApplication::focusWidget() to get the focus widget down the hierarchy, and climb up using QWidget::parentWidget(). Sometimes focusWidget() can be 0 though.
You could also use an interface class with a pure virtual method, and going up the QObject hierarchy from the focusWidget use dynamic_cast to find the first object also inheriting this interface. That would only be necessary if there are multiple components in the same window reacting differently to the shortcut. If the behavior is clear per-window, the activeWindow() solution will be easier.

SVN commit 1217185 by cgilles:

create registered tags shortcuts to dedicated action collection from AlbumGUI, IE, and LT.
connect tag actions manager to Iconview. It's work.
CCBUGS: 114465


 M  +3 -1      digikamapp.cpp  
 M  +4 -1      digikamview.cpp  
 M  +2 -0      digikamview.h  
 M  +1 -1      tags/tageditdlg.cpp  
 M  +50 -28    tags/tagsactionmngr.cpp  
 M  +11 -5     tags/tagsactionmngr.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1217185

SVN commit 1217201 by cgilles:

now Tags Action Manager handle Image Editor and LightTable to assign tag from keyboard shorcut
CCBUGS: 114465


 M  +0 -9      digikam/tags/tageditdlg.cpp  
 M  +0 -1      digikam/tags/tageditdlg.h  
 M  +2 -0      digikam/tags/tagsactionmngr.cpp  
 M  +5 -0      utilities/imageeditor/editor/imagewindow.cpp  
 M  +2 -0      utilities/imageeditor/editor/imagewindow.h  
 M  +15 -1     utilities/lighttable/lighttablebar.cpp  
 M  +3 -1      utilities/lighttable/lighttablebar.h  
 M  +5 -0      utilities/lighttable/lighttablewindow.cpp  
 M  +2 -0      utilities/lighttable/lighttablewindow.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1217201

hi,
good to see the progress, i just can't try it out as the git ebuild is still not there so my question - please ignore if it already works this way:

does this allow  me to just type a, b , c (no shortcut definition needed beforehand) during the slideshow and specify _afterwards_ the mapping to tags ( a => PersonA, b => Person B , c=> CountryX) ?

i hope not to annoy when repeating myself, the way kimdaba handled this was the perfect workflow, while reviewing the images in the slideshow i just press key(s) and afterwards i get the listing of pressed keys and assign a tag to each key without creating immutable shortcuts.

SVN commit 1217244 by cgilles:

now, Tag keyboard shortcuts are toggle action. You can assign or unassign tag to items with the same shortcuts.
BUGS: 114465


 M  +16 -0     digikam/digikamimageview.cpp  
 M  +2 -0      digikam/digikamimageview.h  
 M  +2 -2      digikam/digikamview.cpp  
 M  +1 -1      digikam/digikamview.h  
 M  +8 -2      digikam/tags/tageditdlg.cpp  
 M  +3 -6      digikam/tags/tagsactionmngr.cpp  
 M  +1 -1      digikam/tags/tagsactionmngr.h  
 M  +11 -5     utilities/imageeditor/editor/imagewindow.cpp  
 M  +1 -1      utilities/imageeditor/editor/imagewindow.h  
 M  +2 -2      utilities/lighttable/lighttablebar.cpp  
 M  +1 -1      utilities/lighttable/lighttablebar.h  
 M  +2 -2      utilities/lighttable/lighttablewindow.cpp  
 M  +1 -1      utilities/lighttable/lighttablewindow.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1217244

Thank you Gilles for this great work! I have compiled 2.0 from svn to test the latest changes and they look really good.

However, for me it still does not quite reach my dream of completely mouseless tagging, because if I have 100 tags, I need to set up 100 shortcuts.  And my keyboard/hands/brain are not big enough for that :)

So it would be a MASSIVE improvement if the 'Configure Shortcuts' dialog contained a shortcut for focusing on the 'Enter new tag here...' text field.  The auto-completion in this text field already works great, but currently it requires a mouse click for each photo, and this makes tagging a large collection much slower.

Thanks again!

SVN commit 1218099 by cgilles:

provide a way to manage tag keyboard shortcuts to KDE key shortcuts config pannel from digiKam setup dialog.
CCBUGS: 114465


 M  +1 -1      tageditdlg.cpp  
 M  +1 -1      tagmodificationhelper.cpp  
 M  +16 -5     tagsactionmngr.cpp  
 M  +8 -5      tagsactionmngr.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1218099

While adding keyboard shortcuts is a good improvement, for my feeling digikam needs more improvement to assign multiple tags at once and also to use a evolving tag set. 
A proposal for this is
  https://bugs.kde.org/show_bug.cgi?id=114465, 
what do you think?

Sorry, please see
  https://bugs.kde.org/show_bug.cgi?id=225562