Version: 0.7 beta 1 (using KDE KDE 3.3.0) Installed from: Slackware Packages OS: Linux It would be quite useful to add the possibility of searching for multiple tags in digikam. At the moment it is only possible to click on one single tag in the tag tree and view all images associated with that tag. Making it possible to create queries such as "has tag A and tag B" with simple operators such as AND, OR and NOT would make digikam even more powerful.
*** This bug has been confirmed by popular vote. ***
Created attachment 10352 [details] screenshot with proposed arrangement of picture tags Hi, I would propose the following to do this: Copy - and extend - the GUI of Apple's iPhoto. Their method is very simple, but effective (IMHO) and easy to use. I do not think the seperation into "Places", "Events", "People", etc. is necessary. Just let people specify arbitrary tags (flat, one level). Then split the sidebar with the tree view into several parts (possibly Konq-style "multiple sidebar" tabs can be used for album tree, tags etc). See screenshot (attached): Every tag is a button. Clicking the button will make digiKam - only show pictures with that tag - only show albums containing pictures with that tag Clicking several buttons will make digiKam combine those buttons with logical "AND". (Optional: one button is colored differently and labeled "AND|OR" or similar, switching between AND and OR combinations). In addition, I would propose to remove the tag "tree" in the album tree view and just list albums there. If this is not clear enough, please do ask. ;-) Thanks, Jens
Check kimdaba interface.
Hi, I did. I think kimdaba's interface is far too crowded. IMHO one should not need a second window for searching. Please keep Digikam's GUI simple and clean. A small "live" search input field would be nice (like it is appearing in many KDE apps), which would search file names, comments, tags and keywords for the given string and perhaps "intelligently" parse a date if one is given. A row of buttons to filter for tags/keywords on the side. Also, IMHO the seperation into people, places and keywords is, strictly speaking, unnecessary: Basically, people and places are also keywords, or used as such when searching for images. And it complicates searching, because you have to remember/look in which of the three categories you entered a keyword. Please do not require the user to fill out a dozen fields and read loads of documentation before being able to search for or sort images. Thank you :-) Jens
First, I dont think anybody really wants kimdaba's people/places/keywords distinction here. Second, you are right, the live/filter search bars have been appearing in many KDE apps, because it appeared first in one app (amarok?) and people - including me - simply like it: -result is immediately visible -no extra dialogue, no keyboard shortcuts, only mouse action -result view tightly integrated into main app. So I would support integrating such a field in the search tab of the coming sidebar. There might even be such a little text edit field in the upper right corner in the header of the main view. I am not sure about the right way for the rest of the search tab. Allowing AND, OR and NOT operations for keywords and additionally search for photos taken in a period of time would make search powerful, on the other hand the GUI needs to be intuitive.
> Second, you are right, the live/filter search bars have been appearing > in many KDE apps, because it appeared first in one app (amarok?) and JuK > people - including me - simply like it: -result is immediately visible > -no extra dialogue, no keyboard shortcuts, only mouse action > -result view tightly integrated into main app. > > So I would support integrating such a field in the search tab of the > coming sidebar. There might even be such a little text edit field in the > upper right corner in the header of the main view. Not only in sidebar. In main window also. And it should be modelled rather after KMail with possibility to choose 'field' to filter.`
> A small "live" search input field would be nice (like it is appearing in > many KDE apps), which would search file names, comments, tags and > keywords for the given string and perhaps "intelligently" parse a date > if one is given. Would be life changing. > Also, IMHO the seperation into people, places and keywords is, strictly > speaking, unnecessary: Basically, people and places are also keywords, > or used as such when searching for images. And it complicates searching, > because you have to remember/look in which of the three categories you > entered a keyword. I think this is only to present few examples. To check what is in context menu etc. And should stay for this purpose.
To Comment 5: Yes, the live search is good. IMHO it should "just" be a search field, though and not leave the task of choosing whether to search for tags, comments, or file names to the user. However, it should be clear _what_ is being searched (at least in the docs, or better in a tooltip that pops up when hovering over the input field, like "Search image filenames, comments, and tags"). A really _good_ search would understand things like "kate beach" (two tags or comment substrings) "Greece 2002" (tag/comment + year) "07/2004 - 02/2005" (time span! allow several seperators, like [./-]) "last may" (time span, internationalized!) (this might get complicated) Also IMHO it is important to change the GUI in a way that it's clear the search results are *search* *results*, ie. the user has to clear the search input field before being able to see all albums again. Maybe changing the window title and album title is enough, or the parent album (instead of "My albums"). Or switch to a new sidebar tab called "Search results", or "Last search" when searching and show the results there. The calendar could be done the same way: Something like Kicker's calendar popup in the sidebar, but with month/year and day/month view (two detail levels). Clicking on a day or month will show all pics from that day/month. Just like the tags. To comment #7: Yes, live search rocks :-) What needs to be done? Any plumbing that a beginner can do? I'd like to help out. The example tags should be changed to something that people actually use, though. IMHO the default tags should be something like Family, Vacation, Business, Nature, and Friends. I was confused at first because I expected I had to _specify_ some "People", "Locations" and "Events" before being able to use them as tags. Thanks, Jens :-)
> Yes, the live search is good. IMHO it should "just" be a search field, > though and not leave the task of choosing whether to search for tags, > comments, or file names to the user. No. It should look also in things like comments embedded in files but this is slow, so user should be able to turn it off (even disabled by default), but it should be possible. > A really _good_ search would understand things like > > "kate beach" (two tags or comment substrings) > "Greece 2002" (tag/comment + year) Not sure here. 2002 can be also tag, album name etc. > "07/2004 - 02/2005" (time span! allow several seperators, like [./-]) Look for date only if [0-9./-] is in search field. > "last may" (time span, internationalized!) (this might get > complicated) Yes. > > Also IMHO it is important to change the GUI in a way that it's clear the > search results are *search* *results*, ie. the user has to clear the > search input field before being able to see all albums again. Maybe > changing the window title and album title is enough, or the parent album > (instead of "My albums"). Or switch to a new sidebar tab called "Search > results", or "Last search" when searching and show the results there. Don't exaggerate. That would differentiate digiKam from other KDE apps using this widget. Just text in serch field should be enough. > > The example tags should be changed to something that people actually > use, though. IMHO the default tags should be something like Family, > Vacation, Business, Nature, and Friends. I was confused at first because Here I agree. Good propositions.
Am Sonntag, 27. März 2005 21:54 schrieb Mikolaj Machowski: > > Yes, the live search is good. IMHO it should "just" be a search field, > > though and not leave the task of choosing whether to search for tags, > > comments, or file names to the user. > > No. It should look also in things like comments embedded in files but > this is slow, so user should be able to turn it off (even disabled by > default), but it should be possible. Yes, absolutely. > > A really _good_ search would understand things like > > > > "kate beach" (two tags or comment substrings) > > "Greece 2002" (tag/comment + year) > > Not sure here. 2002 can be also tag, album name etc. Both, then, but 'OR'ed :-) > > "07/2004 - 02/2005" (time span! allow several seperators, like [./-]) > Look for date only if [0-9./-] is in search field. Good idea. > > "last may" (time span, internationalized!) (this might get > > complicated) > Yes. > > Also IMHO it is important to change the GUI in a way that it's clear > > the search results are *search* *results*, ie. the user has to clear > > the search input field before being able to see all albums again. > > Maybe changing the window title and album title is enough, or the > > parent album (instead of "My albums"). Or switch to a new sidebar tab > > called "Search results", or "Last search" when searching and show the > > results there. > > Don't exaggerate. That would differentiate digiKam from other KDE apps > using this widget. Just text in serch field should be enough. Yes, IMHO it's a bit confusing in other KDE apps too. But consistency is important, you're right. Oh yes: Please don't make the search field *too big*. About 5cm width on the screen should be enough, ie. part of the main toolbar if possible. Not like ark or some other apps, which have a complete second toolbar not mergeable with the first. > > The example tags should be changed to something that people actually > > use, though. IMHO the default tags should be something like Family, > > Vacation, Business, Nature, and Friends. I was confused at first > > because > Here I agree. Good propositions. Thanks! :-)
> > > A really _good_ search would understand things like > > > > > > "kate beach" (two tags or comment substrings) > > > "Greece 2002" (tag/comment + year) > > > > Not sure here. 2002 can be also tag, album name etc. > > Both, then, but 'OR'ed :-) This still can create ambigious results. Maybe we are thinking about something different: I would like to make 'live search' working only on current album/tag view. In this case most images will be from the same time or not very long span. For looking for photos across albums there should be full blown search dialog (a la KMail or KFind). > Oh yes: Please don't make the search field *too big*. About 5cm width on > the screen should be enough, ie. part of the main toolbar if possible. > Not like ark or some other apps, which have a complete second toolbar > not mergeable with the first. Not second full-size toolbar but bar embedded in album view. Maybe with some checkboxes, combos alongside inputfield (case sensitive checkbox, type of data combo, maybe even two calendar widgets for date?).
Am Dienstag, 29. März 2005 12:11 schrieb Mikolaj Machowski: > > > > A really _good_ search would understand things like > > > > "kate beach" (two tags or comment substrings) > > > > "Greece 2002" (tag/comment + year) > > > > > > Not sure here. 2002 can be also tag, album name etc. > > > > Both, then, but 'OR'ed :-) > This still can create ambigious results. True. I'm trying to keep the interface as simple as possible. > Maybe we are thinking about something different: I would like to make > 'live search' working only on current album/tag view. In this case most > images will be from the same time or not very long span. For looking for > photos across albums there should be full blown search dialog (a la > KMail or KFind). Oh. No, I thought the live search would show all matching pics in the current album *and* on the left side, show only albums that contain matching pics. iPhoto and other apps do it that way (well, iPhoto doesn't quite - its quicksearch shows *all* matching pictures in one big window, and does not seperate by album). I have pictures of my girlfriend all over the place and I'd want to be able to search for them this way, too. In this way the live search should behave just like the tag filter, only that it doesn't _only_ search for tags. > > Oh yes: Please don't make the search field *too big*. About 5cm width > > on the screen should be enough, ie. part of the main toolbar if > Not second full-size toolbar but bar embedded in album view. Maybe with > some checkboxes, combos alongside inputfield (case sensitive checkbox, > type of data combo, maybe even two calendar widgets for date?). However, that would differ too much from the other apps which use this interface, and IMHO it would be too complicated as well :-) If necessary, forget about the date span in quick search (only put it in a full blown search). The quick search should always be case insensitive (IMHO), no need for a checkbox, and it should always search as many things as is feasible (file name, maybe album name, tags, digiKam comments). I also think searching for digiKam comments should only be in the full search window, if it's supposed to be optional and needs an additional checkbox, otherwise the live search bar would quickly get overloaded with options.
> > Maybe we are thinking about something different: I would like to make > > 'live search' working only on current album/tag view. In this case > > most images will be from the same time or not very long span. For > > looking for photos across albums there should be full blown search > > dialog (a la KMail or KFind). > > Oh. No, I thought the live search would show all matching pics in the > current album *and* on the left side, show only albums that contain > matching pics. iPhoto and other apps do it that way (well, iPhoto > doesn't quite - its quicksearch shows *all* matching pictures in one big > window, and does not seperate by album). This is full search - quite different from other KDE apps. > > I have pictures of my girlfriend all over the place and I'd want to be > able to search for them this way, too. In this way the live search > should behave just like the tag filter, only that it doesn't _only_ > search for tags. Looking for photos of your GF should be done by tag. Just tag her photos with her name and if you want to see her just select tag. > > However, that would differ too much from the other apps which use this > interface, and IMHO it would be too complicated as well :-) There is possibilitity of 'extended' search bar in Konqueror with some widgets. > If necessary, forget about the date span in quick search (only put it in > a full blown search). OK. > > The quick search should always be case insensitive (IMHO), no need for a > checkbox, and it should always search as many things as is feasible > (file name, maybe album name, tags, digiKam comments). > > I also think searching for digiKam comments should only be in the full > search window, if it's supposed to be optional and needs an additional > checkbox, otherwise the live search bar would quickly get overloaded > with options. No. digiKam comments contrary to exif comments - embedded in picture are fast and with meaningless digital camera names often the only way to recognize picture. By default look for: - name - digiKam comment - tag - album name - album comment - collection name (?) Extended search (maybe full blown or by option, combobox): - exif comment field - special widget(?) for exif comments: that was mentioned few times on digiKam lists - there is program to filter photos by lens, aperture etc.
Am Mittwoch, 30. März 2005 09:53 schrieb Mikolaj Machowski: > > Oh. No, I thought the live search would show all matching pics in the > > current album *and* on the left side, show only albums that contain > > matching pics. iPhoto and other apps do it that way (well, iPhoto > > doesn't quite - its quicksearch shows *all* matching pictures in one > > big window, and does not seperate by album). > > This is full search - quite different from other KDE apps. Well, the filter bars in Ark and amaroK also searches your whole collection. Actually, amarok has two filter bars, one for the playlist and one for the whole collection. I'm saying "filter bars" because that's what they do - they don't strictly *search*, they filter. > > should behave just like the tag filter, only that it doesn't _only_ > > search for tags. > Looking for photos of your GF should be done by tag. Just tag her photos > with her name and if you want to see her just select tag. well, but what if I have an album about her birthday and because I know all the pics in that album are about her anyway, I just tagged those with other keywords? Does the tag filter also filter by *album* tag? > > However, that would differ too much from the other apps which use this > > interface, and IMHO it would be too complicated as well :-) > There is possibilitity of 'extended' search bar in Konqueror with some > widgets. Hm. > > I also think searching for digiKam comments should only be in the full > > search window, if it's supposed to be optional and needs an additional > > checkbox, otherwise the live search bar would quickly get overloaded > > with options. > > No. digiKam comments contrary to exif comments - embedded in picture > are fast and with meaningless digital camera names often the only way to > recognize picture. By default look for: Sorry, I meant EXIF comments, of course. > - name > - digiKam comment > - tag > - album name > - album comment > - collection name (?) Yup. BTW, I haven't figured out what to use collections for. ;) > Extended search (maybe full blown or by option, combobox): > - exif comment field > - special widget(?) for exif comments: that was mentioned few times on > digiKam lists - there is program to filter photos by lens, aperture > etc. Hey, that would be something new. "Show me all the pictures that were done using a flash." "Show me all blurred pictures (i.e exposure time > 1/15s, for example)." We could do another sidebar for that and just enter some search criteria. I'll try to do some mockup screenshots of what I'm thinking about this evening.
Here's my mockup screenshot. This also illustrates what I currently don't like about the thumbnail text - it is not always close to the image itself. (see other bug :-) Created an attachment (id=10436) digikam-mockup.png
Your mockup looks really nice, but I'm not sure if it scales well if there are more than just a few tags. For example, I've got a tag "Paris" with _a lot_ of subtags (Eiffel Tower, etc.). And that's only one top-level tag... Using tags (and thus digikam) could become impossible for me if the existing hierarchy of tags would be removed. Could you please explain how you'd handle such a large number of tags? How would the "Show All" button work?
Am Mittwoch, 30. März 2005 23:30 schrieb Gilles Schintgen: > Your mockup looks really nice, but I'm not sure if it scales > well if there are more than just a few tags. For example, I've got a tag > "Paris" with _a lot_ of subtags (Eiffel Tower, etc.). And that's only > one top-level tag... Using tags (and thus digikam) could become > impossible for me if the existing hierarchy of tags would be removed. OK. I wasn't planning on such a huge number of tags. (I have ~8000 photos and ~20 tags and I'm fine with them.) The current arrangement makes it impossible to use a large number of tags just because one tag takes so much screen space because of the huge icons. And IMHO one should be able to browse the tags independantly of the albums. Maybe a tree based view with checkboxes for the tags is also feasible (without icons, or at most 16x16 icons). See attached .UI file. I can't get checkboxes beside the tree elements with KDE Designer, but there should be one for each possible tag. :) The disadvantage of a tree view is that it needs a lot of _vertical_ space but we have more _horizontal_ space available in the sidebar because the album names tend to be long, unless you use *really long* tag names (which is rather improbable). Another disadvantage is that you *need* to categorize your sub-tags. If you have tags "vacations" and "business trips", you might need a tag "Paris" in both of them. If you search for "tag=Paris", which of those should be found? Both? Then why not just create one tag called "Paris" in the first place? The dilemma does not exist with flat tag structures (where you could just select "Paris" + "Vacations" to see only your pleasure trips to Paris). > Could you please explain how you'd handle such a large number of tags? If the flat button paradigm stays, I'd just create more buttons (maybe three rows, dependant on the width of the sidebar) and use flat names like "Paris", "Eiffel Tower" etc. for tags. If I have pictures of the Eiffel Tower I can mark them as Vacation + Paris + Eiffel Tower, and if I have business trips to Paris I can mark them as Business + Paris + Eiffel Tower, and I can seach for all business trips, all Paris trips (for whatever reason) and all Eiffel Tower pictures (maybe you have a scanned postcard that is in neither?). I don't think the multiple-level tag paradigm is strictly necessary. It creates a sense of order, but it does not make the actual tagging easier, and it makes searching potentially more complicated. And if we make more use of the implicit tags that the EXIF info provides, then we won't really need so many custom tags. For example, if you want to see the Eiffel Tower, you usually remember when -approximately- you were there. Put a calendar widget in there, like iPhoto does* and filter for the appropriate year! Or filter for the EXIF name of the camera you took the pics with. I mean, there are people sorting out 50,000 photos with iPhoto (which uses flat tags), and they only have ~20-30 tags, and it seems to work pretty well. I'm still trying not to crowd digiKam's interface too much. ;) (( * see screenshots on http://www.apple.com/ilife/iphoto/ iPhoto has a calendar widget that works like the tags widget: click a day, or month, or year (depending on the display), and only pics from that d/m/Y are displayed. Additionally, you can only click on dates that actually *have* photos, others are greyed out. I like this. )) > How would the "Show All" button work? Either: Uncheck all tags (so that nothing is filtered), and show all pictures. Or: Check all tags (so that all pics are shown), and then change itself to "Show none" (so it's easy to uncheck all, and check only *one*, to do filtering). I don't know what is more convenient and intuitive: - Have none of the tag buttons/checkboxes activated by default, but show all pics by default, and if the users checks one tag, show only the pics that have this tag, or - have *all* tags checked by default (which would be more logical and consistent with the view but which no other photo app I've seen does), and remove pics when tags are unchecked. From a usability point of view I'd go for the first, although strictly speaking it's not as logical. PS: Does it make sense to check out CVS now, to see what's happening, or is digiKam not in a useable state anyway? Created an attachment (id=10452) digikam-tags.ui
One thing I find extremely useful with hierarchical tags is that there is a simple way to see photos that are tagged with the current tag or more specific ones. Say I took a trip to France, so I introduce a tag "France", but I have been to many places, e.g., "Paris" (which is a sub-tag of "France"). Now I get find all photos from that trip by just clicking on (or otherwise searching for) "France" without the need to tag every image from Paris with "Paris" and "France". I can just tag Paris with "Paris" and let digikam do the rest. This becomes a huge time saver if you have deeper tag hierarchies.
If, and only if, the app automatically applies all "parent" tags to pictures who have been tagged with e.g. "paris", then this makes sense. digiKam does not do that, though (just checked)! Only then you have the old problem between "Business trips" / "France" and "Vacation" / "France" and "Scanned Postcards" / "France" again (needing to specify tags multiple times just to make digiKam auto-apply the correct parent tags), which does not really make things easier. Tagging might also be easier if one could use the "tag" sidebar to actually _apply_ tags. I.e. if I have no pics selected, and activate tags, then the main view would filter the correct pics. But if I have some pics selected, then I can *change* the tags by checking/unchecking them in the tag sidebar. This might e.g. be achieved by two radio buttons "(o) Apply tags ( ) Filter by tags" at the top of the sidebar module, where the first is only activated when pics are selected. But that's just an idea. I don't like the idea that you have half a dozen ways to edit your pictures. It needs to be consistent otherwise it overloads the GUI and the menus and everybody is confused.
> > Your mockup looks really nice, but I'm not sure if it scales > > well if there are more than just a few tags. For example, I've got a tag > > "Paris" with _a lot_ of subtags (Eiffel Tower, etc.). And that's only > > one top-level tag... Using tags (and thus digikam) could become > > impossible for me if the existing hierarchy of tags would be removed. > > OK. I wasn't planning on such a huge number of tags. (I have ~8000 photos > and ~20 tags and I'm fine with them.) The current arrangement makes it > impossible to use a large number of tags just because one tag takes so > much screen space because of the huge icons. And IMHO one should be able > to browse the tags independantly of the albums. Good point, but that's exactly were the tree structure comes in: tags can be collapsed! I've got a few hundred thousand files (including system of course) on my PC, yet the hierarchical organization makes it manageable. > Maybe a tree based view with checkboxes for the tags is also feasible > (without icons, or at most 16x16 icons). See attached .UI file. I can't > get checkboxes beside the tree elements with KDE Designer, but there > should be one for each possible tag. :) > > The disadvantage of a tree view is that it needs a lot of _vertical_ space > but we have more _horizontal_ space available in the sidebar because the > album names tend to be long, unless you use *really long* tag names (which > is rather improbable). I'd really appreciate a treeview with checkboxes. That would be great! Wouldn't it be possible to let the user place these views (album and tags)? For example, the default would be to have the albums view on top of the tags, but the user could simply drag the tags view to the left (or right) of the albums view. An advantage of such a treeview would be that it doesn't involve unnecessary complexity, because using 20 top level tags would be quite natural. So it wouldn't be more complicated to use than the proposed toggle buttons. > > Another disadvantage is that you *need* to categorize your sub-tags. If you > have tags "vacations" and "business trips", you might need a tag "Paris" > in both of them. If you search for "tag=Paris", which of those should be > found? Both? Then why not just create one tag called "Paris" in the first > place? > The dilemma does not exist with flat tag structures (where you could just > select "Paris" + "Vacations" to see only your pleasure trips to Paris). This dilemma is exactly the essence of this bug report. After all, it's title is "make searching for multiple tags possible". IMO there's a bit of confusion concerning two different aspects: The first one is how to organize tags (hierarchical or flat), and the second one is searching for a combination of tags. These two are completely independent and the second one is what this bug is all about. One way to solve it would be to eliminate the hierarchy and go for a flat structure with toggle buttons. But, from my point of view, this would lead to a loss of flexibility. > > > Could you please explain how you'd handle such a large number of tags? > > If the flat button paradigm stays, I'd just create more buttons (maybe > three rows, dependant on the width of the sidebar) and use flat names like > "Paris", "Eiffel Tower" etc. for tags. If I have pictures of the Eiffel > Tower I can mark them as Vacation + Paris + Eiffel Tower, and if I have > business trips to Paris I can mark them as Business + Paris + Eiffel > Tower, and I can seach for all business trips, all Paris trips (for > whatever reason) and all Eiffel Tower pictures (maybe you have a scanned > postcard that is in neither?). That's exactly the aspect of combining different tags when searching, which is independent of the actual organization of the tags. In your example you consider "Eiffel Tower" to be a valid tag. That's also my oppinion. But Paris is _a lot_ more that just the Eiffel Tower, and thus this logic immediately leads to a multitude of tags, just for Paris! And that's where the hierarchy becomes necessary. > And if we make more use of the implicit tags that the EXIF info provides, > then we won't really need so many custom tags. For example, if you want to > see the Eiffel Tower, you usually remember when -approximately- you were > there. Put a calendar widget in there, like iPhoto does* and filter for > the appropriate year! Or filter for the EXIF name of the camera you took > the pics with. A calendar filter would be cool :-) > > I mean, there are people sorting out 50,000 photos with iPhoto (which uses > flat tags), and they only have ~20-30 tags, and it seems to work pretty > well. Of course it's possible, but a flat structure is inherently less flexible than a flat one. > I'm still trying not to crowd digiKam's interface too much. ;) That's always appreciated! > > How would the "Show All" button work? OK, thanks for explaining. I thought that the other tags were hidden somewhere and "Show All" would show all the tags, not the photos... To sum up my opinion: filtering on a combination (AND/OR) of tags would be a vast improvement, but eliminating the tag hierarchy would be detrimental to digikam's flexibility.
> If, and only if, the app automatically applies all > "parent" tags to pictures who have been tagged with e.g. "paris", then this > makes sense. digiKam does not do that, though (just checked)! Settings/Configure digiKam.../Albums/Show items in sub-tags > Tagging might also be easier if one could use the "tag" sidebar to actually > _apply_ tags. I.e. if I have no pics selected, and activate tags, then the > main view would filter the correct pics. But if I have some pics selected, > then I can *change* the tags by checking/unchecking them in the tag > sidebar. This might e.g. be achieved by two radio buttons > "(o) Apply tags ( ) Filter by tags" at the top of the sidebar module, > where the first is only activated when pics are selected. IMHO, this is not strictly necessary. Currently it's possible to drag the pictures on a tag or to drag the tag on the pictures. Either way it's quite simple. Of course, your approach would make it easier (and faster) to apply multiple tags to pictures.
> Maybe a tree based view with checkboxes for the tags is also feasible > (without icons, or at most 16x16 icons). See attached .UI file. I can't > get checkboxes beside the tree elements with KDE Designer, but there > should be one for each possible tag. :) Would it be difficult to modify the existing combined album and tag view to allow selecting multiple tags (with Ctrl and Shift)? If so, this would be an easy and elegant way to AND different tags. This would probably solve much of the existing problem. (The view should still be split up, but that's Bug 91540.)
> > This is full search - quite different from other KDE apps. > > Well, the filter bars in Ark and amaroK also searches your whole > collection. Actually, amarok has two filter bars, one for the playlist > and one for the whole collection. KMail and JuK are filtering only current view. I see this as more logical. Another solution is to provide quasi-tag-album which shows all photos and search inside it (or checkbox in search bar). > > > > should behave just like the tag filter, only that it doesn't _only_ > > > search for tags. > > > > Looking for photos of your GF should be done by tag. Just tag her > > photos with her name and if you want to see her just select tag. > > well, but what if I have an album about her birthday and because I know > all the pics in that album are about her anyway, I just tagged those > with other keywords? This is a problem. Album management and tag managment doesn't mix well. You should: a) tag everything with her name b) put every folder with her in one collection and digiKam should create quasi-tag marking all images in all albums in that collection with that tag automatically available in tag hierarchy. > Does the tag filter also filter by *album* tag? > No, and IMO should. Another radical idea: scrap albums and collections. Give users only tags with possibility to export to physical folder outside collection. Inside collection put everything in one folder. > > - collection name (?) > > Yup. BTW, I haven't figured out what to use collections for. ;) > I am treating them as tags for albums.
> Maybe a tree based view with checkboxes for the tags is also feasible > (without icons, or at most 16x16 icons). See attached .UI file. I can't > get checkboxes beside the tree elements with KDE Designer, but there > should be one for each possible tag. :) I would go for something slightly different. Flat list but with whole tag path and three options: AND OR NOT Tag-path Icon (x) ( ) ( ) Paris Icon ( ) ( ) ( ) Paris/Eiffel Icon ( ) ( ) (x) Paris/Louvre With these settings it will show all photos from Paris (including Eiffel) but without Louvre. Not sure about widget: checkboxes would be more natural but shouldn't allow for more than one choice. I don't know if radios can accept lack of choice. This can be crowded with many tags and should be some way to collapse sections. > > I don't think the multiple-level tag paradigm is strictly necessary. It > creates a sense of order, but it does not make the actual tagging > easier, and it makes searching potentially more complicated. Multilevel tags are very useful and are allowing for separating of images with tags of the same name but with different upper level. For me it is important. > > iPhoto has a calendar widget that works like the tags widget: click a > day, or month, or year (depending on the display), and only pics from > that d/m/Y are displayed. Additionally, you can only click on dates that > actually *have* photos, others are greyed out. I like this. Looks nice and KDE has very good calendar widget. > - Have none of the tag buttons/checkboxes activated by default, but show > all pics by default, and if the users checks one tag, show only the pics > that have this tag, or This one is better. > > PS: Does it make sense to check out CVS now, to see what's happening, or > is digiKam not in a useable state anyway? Is in very good state. Just work now is in other area :) Few comments on your mockup (10436): - lack of clear button for live search - full search should be saparate dialog. It will give more space . - I would split tags and searching for tabs into two areas.
> AND OR NOT Tag-path > Icon (x) ( ) ( ) Paris > Icon ( ) ( ) ( ) Paris/Eiffel > Icon ( ) ( ) (x) Paris/Louvre What would it mean if multiple ANDs and ORs are checked? After all, as soon as ANDs and ORs are mixed, order and precedence will play a role.
Am Donnerstag, 31. März 2005 19:39 schrieb Gilles Schintgen: > > AND OR NOT Tag-path > > Icon (x) ( ) ( ) Paris > > Icon ( ) ( ) ( ) Paris/Eiffel > > Icon ( ) ( ) (x) Paris/Louvre > What would it mean if multiple ANDs and ORs are checked? After all, as > soon as ANDs and ORs are mixed, order and precedence will play a role. I agree, and IMHO this gets too complicated and too crowded. I liked kimdaba, until the point where I had to read *documentation* to be able to use the damn search dialog. IMHO, that means the UI is counter-intuitive, and it should not be.
Am Donnerstag, 31. März 2005 16:15 schrieb Gilles Schintgen: > Good point, but that's exactly were the tree structure comes in: tags > can be collapsed! I've got a few hundred thousand files (including > system of course) on my PC, yet the hierarchical organization makes it > manageable. Yes, but to make this comparison consistent you'd need "symbolic links" for tags (Vacation/Paris = Business/Paris = Postcards/Paris ..) :-) > I'd really appreciate a treeview with checkboxes. That would be great! I think it would make sense, but I'd be OK with a flat view as well. What I find more important is to be able to *also* filter albums by tags. E.g. I would like to see only the albums in the album tree, that contain pictures with tags that match my tag selection. For example I check "vacation" and "family", I want to see *all* albums where I was on vacation with my family, because they are all sitting around the PC and want to see a slideshow *now* dammit :-) > Wouldn't it be possible to let the user place these views (album and Yes, one could either do it either like Konqueror (sidebar module) or like K3b (freely arrangeable). > An advantage of such a treeview would be that it doesn't involve > unnecessary complexity, because using 20 top level tags would be quite > natural. So it wouldn't be more complicated to use than the proposed > toggle buttons. True. IF it stays just as easy to actually toggle the tag filtering. > > Another disadvantage is that you *need* to categorize your sub-tags. > > The dilemma does not exist with flat tag structures (where you could > This dilemma is exactly the essence of this bug report. After all, it's > title is "make searching for multiple tags possible". Yes. :-) > IMO there's a bit of confusion concerning two different aspects: > The first one is how to organize tags (hierarchical or flat), and the > second one is searching for a combination of tags. These two are The tree structure, if it is supposed to ease tagging, should then automatically apply parent tags to each sibling, *and* allow double sub-tags (ie. both "Paris" in "Vacations" and "Business" top-level tags). Then your advantage holds, that all of the Eiffel Tower will automagically be found if one searches for Paris. > That's exactly the aspect of combining different tags when searching, > which is independent of the actual organization of the tags. True. > In your example you consider "Eiffel Tower" to be a valid tag. That's > also my oppinion. But Paris is _a lot_ more that just the Eiffel Tower, > and thus this logic immediately leads to a multitude of tags, just for > Paris! And that's where the hierarchy becomes necessary. But if you include all of Eiffel Tower in Paris, how do you categorize the postcard showing the Eiffel Tower you got from somebody in London? :-p > > And if we make more use of the implicit tags that the EXIF info > A calendar filter would be cool :-) Oh yeah, it would. :) > > I mean, there are people sorting out 50,000 photos with iPhoto (which > > uses flat tags), and they only have ~20-30 tags, and it seems to work > > pretty well. > Of course it's possible, but a flat structure is inherently less > flexible than a flat one. ITYM "than a tree based one". But that only holds true as long as the tree based one does not try to be father of all trades to everybody (and overkills itself with too many boxes and buttons). > > I'm still trying not to crowd digiKam's interface too much. ;) > That's always appreciated! Thanks. :-) Thus the configurable windows, you can hide or remove the windows you don't need. Like K3b (I never use K3b's file manager, I just drop things from Konqueror) > > > How would the "Show All" button work? > > OK, thanks for explaining. I thought that the other tags were hidden > somewhere and "Show All" would show all the tags, not the photos... No, I don't think that would make sense. > To sum up my opinion: filtering on a combination (AND/OR) of tags would > be a vast improvement, but eliminating the tag hierarchy would be > detrimental to digikam's flexibility. I'd be OK with a tag tree, as long as it's not default (I still think the default tags should be something like "Vacation", "Business", "Nature", "Panoramas", "Friends", and "Family"), see my earlier posts. That way, you can start tagging at once, and don't have to create sub-tags first.
Am Donnerstag, 31. März 2005 17:07 schrieb Gilles Schintgen: > Would it be difficult to modify the existing combined album and tag view > to allow selecting multiple tags (with Ctrl and Shift)? If so, this > would be an easy and elegant way to AND different tags. This would > probably solve much of the existing problem. I would not vote for this. I think you should be able to mark multiple tags without EMACS (escape-meta-alt-control-shift). :-)
On Saturday 02 April 2005 13:38, Jens B.Benecke wrote: > Yes, but to make this comparison consistent you'd need "symbolic links" for > tags (Vacation/Paris = Business/Paris = Postcards/Paris ..) :-) I think in that case I would not introduce subtags of Postcards (or Vacation or Business). Instead I would just keep Places/Paris as the only "Paris". I agree with you that in these cases a flatter hierarchy would be appropriate, but that's not a reason to eliminate the tree structure. In any case, wouldn't it be more appropriate to use different album collections for Vacations, Business Trips, etc. instead of tags? Well, I don't know. > What I find more important is to be able to *also* filter albums by tags. > E.g. I would like to see only the albums in the album tree, that contain > pictures with tags that match my tag selection. That's true. > Yes, one could either do it either like Konqueror (sidebar module) or like > K3b (freely arrangeable). K3b's interface would be an excellent model. > > > An advantage of such a treeview would be that it doesn't involve > > unnecessary complexity, because using 20 top level tags would be quite > > natural. So it wouldn't be more complicated to use than the proposed > > toggle buttons. > > True. IF it stays just as easy to actually toggle the tag filtering. Checkboxes are easy. :-) Of course, there must also be some buttons to clear all the checkboxes. Alternatively CTRL could be used (just as in nearly each list were multiple items can be selected). Or something like selectionMode Multi for KListBox could be used, but that would perhaps "feel" somewhat strange. In any case, I'd be strongly in favour of an interface that's very close to the current one, with the sole difference being that multiple tags can be activated (i.e. ANDed) simultaneously. > > IMO there's a bit of confusion concerning two different aspects: > > The first one is how to organize tags (hierarchical or flat), and the > > second one is searching for a combination of tags. These two are > > The tree structure, if it is supposed to ease tagging, should then > automatically apply parent tags to each sibling, *and* allow double > sub-tags (ie. both "Paris" in "Vacations" and "Business" top-level tags). > Then your advantage holds, that all of the Eiffel Tower will automagically > be found if one searches for Paris. No, I'm not quite sure if child tags should be automatically assigned, too. After all, I could decide that the "Paris" tag is only assigned to pictures that are neither related to the Eiffel Tower, nor the Panthéon, etc. In fact, the behaviour concerning child tags _is_ already customizable: Settings/Configure digiKam.../Albums/Show items in sub-tags This option does not automatically assign child tags, it's better: it allows to _choose_ whether pictures should be considered to be tagged with parent tags. A further advantage (apart from more finegrained control) of this option is that it keeps the assigned tags at a minimum. > But if you include all of Eiffel Tower in Paris, how do you categorize the > postcard showing the Eiffel Tower you got from somebody in London? :-p I put it in the "Postcard" album and assign it the tags "Paris/Eiffel Tower", "London" and the tag of the friend that sent me the card. (You may be perhaps be surprised about the "London" tag, but the card has a relation to that city, and I consider tags to be mostly just that: an indication that a picture is related to something.) (BTW, who the hell would send a postcard showing the Eiffel Tower, while being in London?! ;-)) > > > I mean, there are people sorting out 50,000 photos with iPhoto (which > > > uses flat tags), and they only have ~20-30 tags, and it seems to work > > > pretty well. > > > > Of course it's possible, but a flat structure is inherently less > > flexible than a flat one. > > ITYM "than a tree based one". Oops :-) > But that only holds true as long as the tree > based one does not try to be father of all trades to everybody (and > overkills itself with too many boxes and buttons). A tree with no subtags is just a list, so it shouldn't be more complicated than that, in case somebody doesn't need (or want) subtags. > > OK, thanks for explaining. I thought that the other tags were hidden > > somewhere and "Show All" would show all the tags, not the photos... > > No, I don't think that would make sense. Me neither, that's why I asked. ;-) > I'd be OK with a tag tree, as long as it's not default (I still think the > default tags should be something like "Vacation", "Business", "Nature", > "Panoramas", "Friends", and "Family"), see my earlier posts. I agree with that. I assume that by "not default" you mean that the standard tag structure that digikam creates at first startup has no subtags. But, it should in fact be a tree structure, so that the user can immediately add subtags if he wants. (Without first enabling some configuration option or the like) > That way, you can start tagging at once, and don't have to create sub-tags > first. True.
On Saturday 02 April 2005 13:38, Jens B.Benecke wrote: > I would not vote for this. I think you should be able to mark multiple tags > without EMACS (escape-meta-alt-control-shift). :-) It's relatively standard to select multiple items with CTRL, so I don't have a problem with that. The advantage would be that, at first glance, the UI wouldn't change, yet it would be fundamentally more powerful. Checkboxes have the minor disadvantage (especially with notebook touchpads) that you must click on a relatively small widget, whereas selecting multiple list items is quite easy and fast. A third possibility would be to use something like selectionMode Multi for KListBox (as I already mentioned). But in fact, that's only a detail that's relatively unimportant to me.
Hi, maybe have a look at KPhotobook. They did multiple tag selection *and* editing (but again with huge icons.. ugh) and we might want to copy some of their ideas. :-) http://kphotobook.berlios.de/ Jens
On Thursday 07 April 2005 10:06, Jens B.Benecke wrote: > maybe have a look at KPhotobook. They did multiple tag selection *and* > editing (but again with huge icons.. ugh) and we might want to copy some of > their ideas. :-) Hmm, the tag tree seems interesting (except for explicitly drawing the connections of the top level tags to the root tag). I'm only looking at the screenshots, so I don't know what that "Value" property is, but I sure like the icons to switch between AND and OR for filtering. (I'm guessing this correctly, aren't I?) But what does the "Behavior" setting in the screenshot http://kphotobook.berlios.de/screenshots/configure_tagtree.html do? Is it simply the default or am I misunderstanding something? What I don't like is the absence of checkboxes for parent tags. It could then be left to the user to choose (in the configure dialog) whether checking a parent checkbox should also mark the child tags or not. The general idea behind this tag tree is exactly what I'd like to see in digikam, since it gives much flexibility without encumbering the UI. It'd be interesting to know if something like this is being worked on for 0.8.
Am Donnerstag, 7. April 2005 16:42 schrieb Gilles Schintgen: > Hmm, the tag tree seems interesting (except for explicitly drawing the > connections of the top level tags to the root tag). That's missing, yes. But I like the idea of using tristate buttons for tagging *and* filtering. The AND/OR icons are a good idea, however they are not really intuitive to understand (I'd suggest using different icons). I like the idea of being able to show multiple albums(=folders) at once as well, using checkboxes in the album/folder tree. Plus, the EXIF info is (IMHO) easier to understand, but the top level "JPEG Exif Data" is not really useful, IMHO it would be better to group the EXIF info, for example like Camera Make, Model, Software, ExifVersion, ... Camera settings Exposure time, FNumber, ISO, Shutter, Aperture, Light source, Flash, Focal Length, Sensor, digi zoom, Contrast, Sharpness, ... Date DateTime, DateTimeOriginal, DateTimeDigitized Image properties X/Y resolution / unit, Pixel X/Y dimension, Orientation, Compression, Compressed Bits Per Pixel, ... or something like that. > I'm only looking at the screenshots, so I don't know what that "Value" > property is, but I sure like the icons to switch between AND and OR for > filtering. (I'm guessing this correctly, aren't I?) No. You can *set* tags if you mark images with the "value" checkbox. And you can *filter* for tags if you mark no images with the "filter" checkbox. Both are tristate checkboxes, so they can be used both at the same time. > But what does the "Behavior" setting in the screenshot > http://kphotobook.berlios.de/screenshots/configure_tagtree.html > do? Is it simply the default or am I misunderstanding something? Yup. > What I don't like is the absence of checkboxes for parent tags. It could > then be left to the user to choose (in the configure dialog) whether > checking a parent checkbox should also mark the child tags or not. Yes. True. > The general idea behind this tag tree is exactly what I'd like to see in > digikam, since it gives much flexibility without encumbering the UI. Absolutely! :-) > It'd be interesting to know if something like this is being worked on > for 0.8. I don't know but maybe it's even feasible to use some code from kphotobook. That's what Open Source is all about, after all :-)
On Friday 08 April 2005 11:14, Jens B.Benecke wrote: > > Hmm, the tag tree seems interesting (except for explicitly drawing the > > connections of the top level tags to the root tag). > That's missing, yes. Just to make things clearer: I don't consider these connections to be missing, I like it that way. (It looks identical to a simple list if no subtags are defined.) > The AND/OR icons are a good idea, however they > are not really intuitive to understand (I'd suggest using different > icons). I've found them quite intuitive, but that's perhaps because of my math background. > I like the idea of being able to show multiple albums(=folders) at once as > well, using checkboxes in the album/folder tree. Yes :-) > Plus, the EXIF info is > (IMHO) easier to understand, but the top level "JPEG Exif Data" is not > really useful, IMHO it would be better to group the EXIF info, for example > like > > Camera > Make, Model, Software, ExifVersion, ... > Camera settings > Exposure time, FNumber, ISO, Shutter, Aperture, > Light source, Flash, Focal Length, Sensor, > digi zoom, Contrast, Sharpness, ... > Date > DateTime, DateTimeOriginal, DateTimeDigitized > Image properties > X/Y resolution / unit, Pixel X/Y dimension, > Orientation, Compression, Compressed Bits Per Pixel, ... > > or something like that. Hmm, that's not on the screenshots, but this proposal is quite interesting. This reorganization would be very welcome in the current "View Exif Information Dialog". Could you file this as a new wish? Thanks. > > I'm only looking at the screenshots, so I don't know what that "Value" > > property is, but I sure like the icons to switch between AND and OR for > > filtering. (I'm guessing this correctly, aren't I?) > > No. You can *set* tags if you mark images with the "value" checkbox. Cool, now I get it. The more I think about it, the more I like it.
Am Freitag, 8. April 2005 13:27 schrieb Gilles Schintgen: > > > Hmm, the tag tree seems interesting (except for explicitly drawing > > > the connections of the top level tags to the root tag). > > > > That's missing, yes. > > Just to make things clearer: I don't consider these connections to be > missing, I like it that way. (It looks identical to a simple list if no > subtags are defined.) Yes, me too - I don't like having tree lines at the left of the widget if there is only one "root" element anyway. It just wastes space on the screen. That's my main gripe with Kopete as well. ;) > > The AND/OR icons are a good idea, however they > > are not really intuitive to understand (I'd suggest using different > > icons). > I've found them quite intuitive, but that's perhaps because of my math > background. Yes, I *do* like AND/OR buttons but I wouldn't be able to tell they *are* AND/OR buttons by looking at the icons. :-) > > I like the idea of being able to show multiple albums(=folders) at > > once as well, using checkboxes in the album/folder tree. > Yes :-) What would also be great: saving tag combinations as "virtual / dynamic / intelligent (whatever) albums". Create a new "dynamic album" with something like Tag "Quality / Great" is set and EXIF info "Flash used" equals "yes" and EXIF info "Orientation" does not equal "Landscape" and Date is greater than 2004-02-05 and Date is smaller than 2005-01-01 and *save* this search criteria. So you can create a dynamic album with favorite portraits of your grandma which were done with a flash last year. However, this would probably conflict with also filtering the album display by tags. > > really useful, IMHO it would be better to group the EXIF info, for > > example like > Hmm, that's not on the screenshots, but this proposal is quite > interesting. This reorganization would be very welcome in the current > "View Exif Information Dialog". Could you file this as a new wish? Done. See Bug 103489 :-) > > No. You can *set* tags if you mark images with the "value" checkbox. > > Cool, now I get it. The more I think about it, the more I like it. The point is (I think) that you only need one interface for multiple possible actions, and that you don't need to fiddle around with context menus (which are far too crowded in Digikam anyway, even if you disable some plugins). Maybe the plugins can be moved into a "Plugins ... >" submenu in the image context menu? Or selectively disabled in the context menu (but not in the main menu)?
On Friday 08 April 2005 17:36, Jens B.Benecke wrote: > > > The AND/OR icons are a good idea, however they > > > are not really intuitive to understand (I'd suggest using different > > > icons). > > > > I've found them quite intuitive, but that's perhaps because of my math > > background. > > Yes, I *do* like AND/OR buttons but I wouldn't be able to tell they *are* > AND/OR buttons by looking at the icons. :-) Sorry for the confusion. I wanted to say that I'm finding the _icons_ to be intuitive. ("Them" referred to the icons, not the buttons and their functionality.) > Done. See Bug 103489 :-) voted :-)
I feel that there should definitely be a way to search for multiple tags by typing in a text box. For example please see www.flickr.com I often wonder if flickr was based on Digikam. It would also be desireable to have the ability to include comments and or EXIF data in these searches. This would require full text searches of the comments. Since searching the EXIF data would be very slow, unless EXIF data was cached in the database, this should be an optional search. Perhaps a checkbox under the search text box. Think of it like this... Tens of thousands of pictures with each picture completely described using tags(a tag for everything and everyone in the picture) and each picture having a comment. The idea would be that you should be able to instantly locate all pictures that contain mouse, cheese, wine, table, crackers, daytime, indoors. I think that Digikam is awesome and does a great job of organizing the pictures but, when there are lots of pictures and lots of tags, it can be difficult to locate a particular picture. Thank you for a great program!
I have a great need for selecting on multiple tags. The way Paint Shop Photo Album does things works fine for me. Theo
What's wrong with just having a simple, checkbox-driven dialog like the one to add tags to a picture? Select Tools->Search from the menu, up pops a dialog with checkboxes in my tag tree, I select one or more of the checkboxes and it searches for pictures with all the tags (using 'AND'). Show the results by having an extra set of icons in the left pane (under the 'Albums' and 'Tags') called 'Searches'. Sounds a lot easier then redesigning the whole GUI as proposed above, just reuse the elements and ideas from other parts of the interface.
This is implemented and will be available in digiKam 0.8.
While in 0.9.3 I can select multiple tags, I cannot select a way to combine them using logical operators. So quick filtering using multiple (ANDed) tags is still not possible... (or is it?) /Simon
Simon, if you right-click with the mouse, you get a menu, where the last point is "Matching condition" with the choice "Or between tags" and "And between Tags". Hope this is what you are looking for... Best, Arnd
Not reproducible with 7.0.0-beta1