[Bug 114465] New: Wish: simpler entry of tags

>
> Please note: Whereever I search photos having certing tags leaf-autocompletion
> is of course very useful. However when entering a new tag I think a leaf in
> the tag hierarchy tree like described above should not be shown by
> autocompletion.
>
>  

The point is that you can also assign tags, in that case autocompletion
of leaves is useful IMHO.


Julien
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[krienke]

Am Montag, 31. März 2008 14:23:20 schrieb Julien Narboux:
>
> The point is that you can also assign tags, in that case autocompletion
> of leaves is useful IMHO.

Yes thats correct again. But what about this proposal:
The thing that is puzzling in my eyes was that autocompleteionj start way to
early when entering new tags. In my hierarchy  "/parent/a"  when trying to
enter a new parent  subtag "b" the autocompletion is already proposing
something when you type "/parent/" .  What about the idea that at that point
nothing is autocompleted because no single letter after the "/parent/" has
been typed yet?

Rainer  
--
Rainer Krienke, Uni Koblenz, Rechenzentrum, A22, Universitaetsstrasse  1
56070 Koblenz, http://www.uni-koblenz.de/~krienke, Tel: [phone]
PGP: http://www.uni-koblenz.de/~krienke/mypgp.html,Fax: [phone]
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Rainer Krienke a écrit :

> Am Montag, 31. März 2008 14:23:20 schrieb Julien Narboux:
>  
>> The point is that you can also assign tags, in that case autocompletion
>> of leaves is useful IMHO.
>>    
>
> Yes thats correct again. But what about this proposal:
> The thing that is puzzling in my eyes was that autocompleteionj start way to
> early when entering new tags. In my hierarchy  "/parent/a"  when trying to
> enter a new parent  subtag "b" the autocompletion is already proposing
> something when you type "/parent/" .  What about the idea that at that point
> nothing is autocompleted because no single letter after the "/parent/" has
> been typed yet?
>
> Rainer  
>  

I think you are right, it is confusing. It can be solved by setting
another completion mode using the contextual menu of the text entry.
Gilles, maybe the default completion mode could be changed ? or is this
a general KDE setting ?

Best wishes,

Julien
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2008/3/31, Julien Narboux <[hidden email]>:

> Rainer Krienke a écrit :
>
> > Am Montag, 31. März 2008 14:23:20 schrieb Julien Narboux:
>  >
>  >> The point is that you can also assign tags, in that case autocompletion
>  >> of leaves is useful IMHO.
>  >>
>  >
>  > Yes thats correct again. But what about this proposal:
>  > The thing that is puzzling in my eyes was that autocompleteionj start way to
>  > early when entering new tags. In my hierarchy  "/parent/a"  when trying to
>  > enter a new parent  subtag "b" the autocompletion is already proposing
>  > something when you type "/parent/" .  What about the idea that at that point
>  > nothing is autocompleted because no single letter after the "/parent/" has
>  > been typed yet?
>  >
>  > Rainer
>  >
>
> I think you are right, it is confusing. It can be solved by setting
>  another completion mode using the contextual menu of the text entry.
>  Gilles, maybe the default completion mode could be changed ? or is this
>  a general KDE setting ?
>

The default completion mode come from KDE settings (in general) but in
this case, i have set a specific one.

Just play with others completion mode and let's me hear which is the
better. I have no preference.

Question : Why this thread is continued _outside_ bugzilla ?

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=114465         




------- Additional Comments From mikmach wp pl  2008-03-31 20:36 -------
Dnia Monday 31 of March 2008, Gilles Caulier napisa�:

> 2008/3/31, Julien Narboux <Julien narboux fr>:
> > Rainer Krienke a �crit :
> > > Am Montag, 31. M�rz 2008 14:23:20 schrieb Julien Narboux:
> >  >> The point is that you can also assign tags, in that case
> >  >> autocompletion of leaves is useful IMHO.
> >  >
> >  > Yes thats correct again. But what about this proposal:
> >  > The thing that is puzzling in my eyes was that autocompleteionj
> >  > start way to early when entering new tags. In my hierarchy
> >  > "/parent/a"  when trying to enter a new parent  subtag "b" the
> >  > autocompletion is already proposing something when you type
> >  > "/parent/" .  What about the idea that at that point nothing is
> >  > autocompleted because no single letter after the "/parent/" has
> >  > been typed yet?
> >  >
> >  > Rainer
> >
> > I think you are right, it is confusing. It can be solved by setting
> >  another completion mode using the contextual menu of the text entry.
> >  Gilles, maybe the default completion mode could be changed ? or is
> > this a general KDE setting ?
>
> The default completion mode come from KDE settings (in general) but in
> this case, i have set a specific one.
>
> Just play with others completion mode and let's me hear which is the
> better. I have no preference.
>
> Question : Why this thread is continued _outside_ bugzilla ?
>

Redirecting to Bugzilla with all previous messages.

This new dialog is nice. Personally I like most completion method
"Dropdown menu & Automatic" but I know some people are confused. IMO the
best common denominator is "Dropdown menu" commonly used in very many
applications on Windows and Linux.

I think there is some small problem with automatic. Normally suggested
completion is in slightly paler color from main text but with new color
themes in digiKam suggestion is exactly the same shade as inserted text,
this may be really confusing.

Several issues:

1. when opening dialog header is

Create new tag in
"/"

But when I start to insert something beginning with /  second line
vanishes causing resizing of whole dialog. Ugly. This apply to all cases
of relative paths - when new path "negating" second line is typed this
line vanishes.

2. I think Julien mentioned problem: Completion doesn't take into
   account that line from header about context.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=114465         




------- Additional Comments From mikmach wp pl  2008-03-31 20:45 -------
> 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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=114465         




------- Additional Comments From Julien narboux fr  2008-03-31 21:03 -------
I vote for "Dropdown menu".

Julien
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=114465         




------- Additional Comments From arnd.baecker web de  2008-04-01 08:28 -------
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 ...)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=114465         




------- Additional Comments From mikmach wp pl  2008-04-01 17:26 -------
> > 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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=114465         




------- Additional Comments From marcel.wiesweg gmx de  2008-04-01 18:58 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=114465         




------- Additional Comments From Julien narboux fr  2008-04-01 20:00 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=114465         




------- Additional Comments From mikmach wp pl  2008-04-01 20:13 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=114465         




------- Additional Comments From arnd.baecker web de  2008-04-01 20:23 -------
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).
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[krienke]

Hallo,

This comment does not really belong to Bug 114465 (so I only sent it to the
list) but is strongly related to the new solution for Bug 114465 .

I think in the new interface for creating tags very fast and easily via
keyboard there is something important missing:  A way for deleting a single
tag using only the keyboard.

At the moment one can assign a keyboard shortcut to delete tags but even if I
select (not assign) *one* certain tag in the tag sidebar so the background of
this tag line is filled blue and then press the  shortcut key I assigned
to  "delete tag" this would not delete the one tag  selected but instead it
would delete all tags assigned to the photo that is currently selected.  

However since creating tags is very easy now an easy way to delete single tags
(in contrast to: all tags assigned to a photo)  via keyboard is needed as
well I think. At the moment  the only way to drop a single tag is to press
the right mouse button over the tag and select the delete action.

Have a nice day
Rainer
--
Rainer Krienke, Uni Koblenz, Rechenzentrum, A22, Universitaetsstrasse  1
56070 Koblenz, http://www.uni-koblenz.de/~krienke, Tel: [phone]
PGP: http://www.uni-koblenz.de/~krienke/mypgp.html,Fax: [phone]

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=114465         




------- Additional Comments From andi.clemens gmx net  2008-04-14 21:01 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=114465         




------- Additional Comments From andi.clemens gmx net  2008-04-16 11:42 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=114465         




------- Additional Comments From x3ri7yz02 sneakemail com  2008-05-22 03:47 -------
Created an attachment (id=24885)
 --> (http://bugs.kde.org/attachment.cgi?id=24885&action=view)
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...
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=114465         




------- Additional Comments From caulier.gilles gmail com  2008-05-22 10:37 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel