counting pictures in search results

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

counting pictures in search results

Bugzilla from gandalf.lechner@esi.ac.at
Hi,

I just tested the new feature counting images in albums and tags from the svn
version of digikam. I find it very helpful and it works mostly fine, but I
observed that it does not (yet?) count the results of stored searches
("virtual albums"). Would be nice if we could have a count there, too.

Also the option to display all subalbums/subtags of a selected album/tag is
very convenient. In the resulting list of images, the thumbnails are listed
according to the albums they are stored in, and the different albums are
separated by these blue bars. This is helpful sometimes, but sometimes (when
your search or tag selection results only in very few images per album), it
creates clumsy looking and unnecessarily long lists. I would therefore
suggest to have an option to either display the album separators in such a
case or not. This would also give the user the opportunity to create virtual
albums which behave more closely to real albums.

Best regards,

Gandalf

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: counting pictures in search results

Gerhard Kulzer-3
Am Saturday 05 January 2008 schrieb Gandalf Lechner:
> Hi,
>
> I just tested the new feature counting images in albums and tags from the
> svn version of digikam. I find it very helpful and it works mostly fine,
> but I observed that it does not (yet?) count the results of stored searches
> ("virtual albums"). Would be nice if we could have a count there, too.

We had that already implemented Gandalf, but it turns out that due to the
complexity the searches can take on, it resulted in too high a load on the
computer. Even with my 3.2GHz Core 2 Duo it would take 8 seconds to
recalculate the numbers every time you changed something. We therefore had to
abandon the inclusion of searches.

Gerhard

> Also the option to display all subalbums/subtags of a selected album/tag is
> very convenient. In the resulting list of images, the thumbnails are listed
> according to the albums they are stored in, and the different albums are
> separated by these blue bars. This is helpful sometimes, but sometimes
> (when your search or tag selection results only in very few images per
> album), it creates clumsy looking and unnecessarily long lists. I would
> therefore suggest to have an option to either display the album separators
> in such a case or not. This would also give the user the opportunity to
> create virtual albums which behave more closely to real albums.

At least you can drag&drop images across those bars now :-)

> Best regards,
>
> Gandalf
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users



--
><((((º> ¸.·´¯`·... ><((((º> ¸.·´¯`·...¸ ><((((º>
http://www.gerhard.fr

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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: counting pictures in search results

Arnd Baecker
On Sat, 5 Jan 2008, Gerhard Kulzer wrote:

> Am Saturday 05 January 2008 schrieb Gandalf Lechner:
> > Hi,
> >
> > I just tested the new feature counting images in albums and tags from the
> > svn version of digikam. I find it very helpful and it works mostly fine,
> > but I observed that it does not (yet?) count the results of stored searches
> > ("virtual albums"). Would be nice if we could have a count there, too.
>
> We had that already implemented Gandalf, but it turns out that due to the
> complexity the searches can take on, it resulted in too high a load on the
> computer. Even with my 3.2GHz Core 2 Duo it would take 8 seconds to
> recalculate the numbers every time you changed something. We therefore had to
> abandon the inclusion of searches.

Maybe one could (optionally) calculate that number
triggered by a mouse-over?
If this is done in the background this might not
slow-down things to much...

Best, Arnd
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users