Bug 91372

Summary: make searching for multiple tags possible
Product: [Applications] digikam Reporter: Michał Kosmulski <michal>
Component: Searches-AdvancedAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: wishlist CC: caulier.gilles
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Slackware   
OS: Linux   
Latest Commit: Version Fixed In: 7.0.0
Sentry Crash Report:
Attachments: screenshot with proposed arrangement of picture tags
digikam-mockup.png
digikam-tags.ui

Description Michał Kosmulski 2004-10-15 09:41:39 UTC
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.
Comment 1 beirne 2004-12-28 14:08:49 UTC
*** This bug has been confirmed by popular vote. ***
Comment 2 Jens 2005-03-25 20:44:35 UTC
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
Comment 3 Mikolaj Machowski 2005-03-26 01:32:47 UTC
Check kimdaba interface.
Comment 4 Jens 2005-03-26 11:40:50 UTC
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
Comment 5 Marcel Wiesweg 2005-03-26 13:01:14 UTC
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.
Comment 6 Mikolaj Machowski 2005-03-26 17:49:20 UTC
> 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.`
Comment 7 Mikolaj Machowski 2005-03-26 17:49:41 UTC
> 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.
Comment 8 Jens 2005-03-26 23:52:17 UTC
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 :-)
Comment 9 Mikolaj Machowski 2005-03-27 21:54:18 UTC
> 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.
Comment 10 Jens 2005-03-29 00:32:45 UTC
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! :-)
Comment 11 Mikolaj Machowski 2005-03-29 12:11:26 UTC
> > > 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?).
Comment 12 Jens 2005-03-29 13:32:24 UTC
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.
Comment 13 Mikolaj Machowski 2005-03-30 09:53:00 UTC
> > 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.
Comment 14 Jens 2005-03-30 10:21:34 UTC
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.
Comment 15 Jens 2005-03-30 23:08:23 UTC
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
Comment 16 Gilles Schintgen 2005-03-30 23:29:54 UTC
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?
Comment 17 Jens 2005-03-31 14:47:14 UTC
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
Comment 18 Sebastian 2005-03-31 14:54:56 UTC
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.
Comment 19 Jens 2005-03-31 15:05:26 UTC
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.
Comment 20 Gilles Schintgen 2005-03-31 16:15:29 UTC
> > 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.
Comment 21 Gilles Schintgen 2005-03-31 16:24:09 UTC
> 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.
Comment 22 Gilles Schintgen 2005-03-31 17:07:27 UTC
> 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.)
Comment 23 Mikolaj Machowski 2005-03-31 19:15:39 UTC
> > 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.
Comment 24 Mikolaj Machowski 2005-03-31 19:15:39 UTC
> 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.
Comment 25 Gilles Schintgen 2005-03-31 19:39:11 UTC
>      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.
Comment 26 Jens 2005-04-02 13:37:56 UTC
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.
Comment 27 Jens 2005-04-02 13:38:16 UTC
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.
Comment 28 Jens 2005-04-02 13:38:36 UTC
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). :-)
Comment 29 Gilles Schintgen 2005-04-02 15:05:51 UTC
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.
Comment 30 Gilles Schintgen 2005-04-02 15:15:12 UTC
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.
Comment 31 Jens 2005-04-07 10:06:30 UTC
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
Comment 32 Gilles Schintgen 2005-04-07 16:42:49 UTC
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.
Comment 33 Jens 2005-04-08 11:14:42 UTC
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 :-)
Comment 34 Gilles Schintgen 2005-04-08 13:27:45 UTC
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.
Comment 35 Jens 2005-04-08 17:36:36 UTC
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)?
Comment 36 Gilles Schintgen 2005-04-08 18:48:29 UTC
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 :-)
Comment 37 Peter 2005-05-07 23:56:20 UTC
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!
Comment 38 Theo Groen 2005-05-09 20:48:26 UTC
I have a great need for selecting on multiple tags. The way Paint Shop Photo Album does things works fine for me.

Theo
Comment 39 Neddie 2005-06-13 23:13:08 UTC
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.
Comment 40 Tom Albers 2005-06-21 19:12:08 UTC
This is implemented and will be available in digiKam 0.8.
Comment 41 Simon Oosthoek 2008-03-13 13:40:41 UTC
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
Comment 42 Arnd Baecker 2008-03-13 13:57:56 UTC
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
Comment 43 caulier.gilles 2019-12-28 06:16:18 UTC
Not reproducible with 7.0.0-beta1