Summary: | When adding name, the list should only contain people [patch] | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Julien Narboux <Julien> |
Component: | Faces-Workflow | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | caulier.gilles, knizek, mario.frank, mick, simon, swatilodha27 |
Priority: | NOR | ||
Version: | 5.3.0 | ||
Target Milestone: | --- | ||
Platform: | Unlisted Binaries | ||
OS: | Linux | ||
Latest Commit: | https://commits.kde.org/digikam/f11e34f7c376e92d8820c81f743a7fdeaaa380a1 | Version Fixed In: | 5.5.0 |
Sentry Crash Report: | |||
Attachments: | A quick-shot patch |
Description
Julien Narboux
2011-01-05 11:18:05 UTC
In the beginning, when you had a tag hierarchy from 1.x, there will be no "people" tags but normal tags for people. You will want to assign them. Maybe the user of Digikam 1.x should be advised to put their people tag under people ? Julien I did not like to restrict users - there is no requirement any more to put your people tags under "People". It is suggested, but you can put them anywhere, or have a flat hierarchy. I though about only showing people tags but providing autocompletion for all tags. But that would be "surprising" which is bad for usability. Any filtering checkbox "Show only people tags" is hard to find space for. Though, could be done in a context menu. As an easy solution, we could scroll to and expand the "People" folder, if there is one. What about a general preference in digikam as a checkbox : o Always put people tags under "People" Then the gui could be simplified: If the option is checked then you have completion only in the people list and creation of new tags only under People. If the option is not checked then the behaviour is the same as a normal tag. Note that a people tag could be considered different from a normal tag. For instance people tag could automatically get as a thumbnail one of the faces it is attached to. Julien Agree with #4: Adding an option to general preferences could work. Users could also be advised to migrate their existing "people" tags to /People and synchronise database with images (Write to images). (It is actually my case - I have /family, /friends, /others). I dont want to impose anything - having a friends/family hierarchy should be fine. People tags _are_ treated specially, in some contexts at least. It's rather easy to make a tag a people tag. So we'll need that option, and maybe a context menu action to make a tag a people tag. i just want to add that it's irritating when asked in the tag dialog "Who is this" to be not only presented with the list of Peoples to choose from and a so a default Assumption to add all Persons to the "Person" Category would be fine for the average Beginner User and allowing to opt for a "don't restrict People Tags to peoples category" would allow advanced users to customize for their needs. i believe its good to start with a easy and straightforward default Behaviour in this case Julien, It still valid using digiKam 2.4 ? Gilles Caulier This is still valid in digiKam5.0.0-beta6 (I think this should be added to wishlist) In my view this is an essential feature. I have many event tags, birthdays, weddings etc, which contain peoples names, these should not be included in the list when selecting a person tag. This is still the same in the latest appimage. Created attachment 103441 [details]
A quick-shot patch
This patch introduces the functionality to filter tags for assigning.
Only face tags are given if configured so. The setup option is located in misc setup settings. Made small tests. Seems to work.
Can someone test the functionality, too?
Mario, The patch is fine for me... Gilles (In reply to Mario Frank from comment #11) > Created attachment 103441 [details] > A quick-shot patch > > This patch introduces the functionality to filter tags for assigning. > Only face tags are given if configured so. The setup option is located in > misc setup settings. Made small tests. Seems to work. > Can someone test the functionality, too? Just tested on 5.4.0 and it does not work for me. I cannot see a setup option, where is it? I looked in Settings > Configure Digikam - Miscellaneous tab, but there is nothing that refers to tags. Mick (In reply to Mick Sulley from comment #13) > (In reply to Mario Frank from comment #11) > > Created attachment 103441 [details] > > A quick-shot patch > > > > This patch introduces the functionality to filter tags for assigning. > > Only face tags are given if configured so. The setup option is located in > > misc setup settings. Made small tests. Seems to work. > > Can someone test the functionality, too? > > Just tested on 5.4.0 and it does not work for me. I cannot see a setup > option, where is it? I looked in Settings > Configure Digikam - > Miscellaneous tab, but there is nothing that refers to tags. > Mick Hey Mick, it is not yet included in the release. I will commit a patch for digiKam 5.5 when I am finished with polishing the code. As soon as we have that, there will be a beta AppImage where this feature will be included. Git commit f11e34f7c376e92d8820c81f743a7fdeaaa380a1 by Mario Frank. Committed on 16/01/2017 at 20:20. Pushed by mfrank into branch 'master'. This patch introduces the functionality to filter tags for assigning. Only face tags are given if configured so. The setup option is located in misc setup settings. Also, the Unconfirmed face tag now shows the count of contained faces. Related: bug 336253 FIXED-IN: 5.5.0 M +3 -1 NEWS M +10 -0 app/items/overlays/assignnameoverlay.cpp M +3 -0 libs/database/dbjobs/dbjob.cpp M +2 -0 libs/settings/applicationsettings.cpp M +3 -0 libs/settings/applicationsettings.h M +10 -0 libs/settings/applicationsettings_miscs.cpp M +3 -0 libs/settings/applicationsettings_p.cpp M +3 -0 libs/settings/applicationsettings_p.h M +11 -0 utilities/facemanagement/assignnamewidget.cpp M +8 -2 utilities/setup/setupmisc.cpp https://commits.kde.org/digikam/f11e34f7c376e92d8820c81f743a7fdeaaa380a1 Thanks Mario, that's neat. I would even argue only showing face tags should be the default. To Mick, comment #10, The digiKam 5.5.0 test AppImage bundle 64 bits is under upload to GDrive repository. It will be available in one hour, including patch from this file. Gilles Caulier OK just tested again and it works!! Still have that odd behaviour of only getting the drop down suggestions on every other character, but I think that is covered in another bug. Great work guys. Mick (In reply to Simon from comment #16) > Thanks Mario, that's neat. I would even argue only showing face tags > should be the default. Hey Simon, Setting this as default is not yet a good idea. If you want to tag some name that is a tag but not yet a face tag would not be accomplishable easily. We need a context menu item in tags sidebar that marks an ordinary tag as face tag. Git commit 434b0ee73c9a6bb80eac2b8280e8d86d963bda7c by Mario Frank. Committed on 17/01/2017 at 09:17. Pushed by mfrank into branch 'master'. This commit introduces the possibility to mark tags in tag sidebar as face tags, if they are not already face tags. Meaning, when one tag is selected and is no face tag, the context menu for it contains an properties action to set this tag as face tag. If multiple tags are selected, the context menu contains the action to mark them as face tags if at least one of the selected tags is no face tag. The default option for filtering names for confirmation in people sidebar is set to true. Meaning, by default, the suggested tags in line edit and tag tree are filtered to only be face tags. The option can be unset in setup->misc->Show only face tags ... . M +20 -0 app/utils/contextmenuhelper.cpp M +6 -0 app/utils/contextmenuhelper.h M +1 -1 libs/settings/applicationsettings.cpp M +18 -1 libs/tags/tagfolderview.cpp M +34 -0 libs/tags/tagmodificationhelper.cpp M +24 -0 libs/tags/tagmodificationhelper.h https://commits.kde.org/digikam/434b0ee73c9a6bb80eac2b8280e8d86d963bda7c (In reply to Mario Frank from comment #19) > (In reply to Simon from comment #16) > > Thanks Mario, that's neat. I would even argue only showing face tags > > should be the default. > > Hey Simon, > Setting this as default is not yet a good idea. If you want to tag some name > that is a tag but not yet a face tag would not be accomplishable easily. We > need a context menu item in tags sidebar that marks an ordinary tag as face > tag. Done |