[Digikam-devel] #images in album/tag list

Hi!

I would like to add number of images to album and tag names as requested in
bug [1].

1. Number of images would be added to album/tag name
Example (similar to folders in Kmail for unread messages):
  My Albums
     Test (14)
     Another (1234)

2. I would add this only to My Albums and My Tags
Not sure if this really makes sense for Tag Filters (sidebar).

3. Make it configurable
Since we have images/tags in DB, I will just perform additional "select
count()" statements to retreive appropriate numbers. This may have some
performance penalty for large collections, so it make sense to have it
optional. I plan to add these two options to "Miscelaneous" config:
- Show number of images after Album name
- Show number of images after Tag name

Any other concerns with proposed implementation?
I think similar might be useful for Dates too, but may be added later if
requested by users...

Regards,
Luka

[1] http://bugs.kde.org/show_bug.cgi?id=96388
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Dnia niedziela 28 styczeń 2007, Luka Renko napisał:
> Hi!
>
> I would like to add number of images to album and tag names as requested
> in bug [1].

Great!

> Any other concerns with proposed implementation?

The only question which comes to mind: what default? Turn on or off.
I am usually for on.

m.

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

[Gilles Caulier-2]

Le Samedi 27 Janvier 2007 23:54, Luka Renko a écrit :

> Hi!
>
> I would like to add number of images to album and tag names as requested in
> bug [1].
>
> 1. Number of images would be added to album/tag name
> Example (similar to folders in Kmail for unread messages):
>   My Albums
>      Test (14)
>      Another (1234)
>
> 2. I would add this only to My Albums and My Tags
> Not sure if this really makes sense for Tag Filters (sidebar).

well, if we provide this options, to be homogenous, all views where albums
view are visible (virtual  or physical album) must show these informations.
This include :

- album tree view,
- date tree view
- search tree view
- tags filtrer tree view
- tags tree view from left side bar
- tags tree view on Comments & Tags

Some of piece can be set on/off independetly, but not sure.

Warning, to have study this way in the past, i have delayed it because it's
can be take a while to do, especially to do all regression test.

In fact, i'm not sure if this is the right way to do it for 0.9.1-beta1.

This is depand of free time available for you. Take a care (:=)))

>
> 3. Make it configurable
> Since we have images/tags in DB, I will just perform additional "select
> count()" statements to retreive appropriate numbers.
> This may have some
> performance penalty for large collections

no, because something like this already exist in curent implementation. Look
on header of Album icons view. You have this information (:=)))

> , so it make sense to have it
> optional.

sure

> I plan to add these two options to "Miscelaneous" config:
> - Show number of images after Album name
> - Show number of images after Tag name

yes

>
> Any other concerns with proposed implementation?
> I think similar might be useful for Dates too, but may be added later if
> requested by users...

just my preview remarks.

A nice week end

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

On Sunday 28. of January 2007 10:11:52 Caulier Gilles wrote:

> Le Samedi 27 Janvier 2007 23:54, Luka Renko a écrit :
> > 2. I would add this only to My Albums and My Tags
> > Not sure if this really makes sense for Tag Filters (sidebar).
>
> well, if we provide this options, to be homogenous, all views where albums
> view are visible (virtual  or physical album) must show these informations.
> This include :
>
> - album tree view,
> - date tree view
> - search tree view
> - tags filtrer tree view
> - tags tree view from left side bar
> - tags tree view on Comments & Tags
>
> Some of piece can be set on/off independetly, but not sure.

Are search and date "albums" also stored in DB? In that case it should not be
problem to implement it, otherwise we would need to count (slow...).

I am fine with left side bar, however I am not sure if it would add a lot of
value to the right side bar (Comments & Tags) as those operate on current
selection/view only. Having count displayed in name makes sense where this
info might lead you to the right location to find right photos, so for me it
makes sense for tree-views which are used for navigation (click on name
brings you the photos) and not for displays where clicking would assign the
tag (like Comments & Tag). On the other hand, it makes sense to have the
number presented in "Tag Filters" right hand sidebar: but it would need to
present number of images with specific tag in current view and not all
images - otherwise this would be misleading and user might click on "Paris
(123)" and would expect 123 images, but would see none.
 
> Warning, to have study this way in the past, i have delayed it because it's
> can be take a while to do, especially to do all regression test.
>
> In fact, i'm not sure if this is the right way to do it for 0.9.1-beta1.
>
> This is depand of free time available for you. Take a care (:=)))

Yes, 0.9.1 is probably to agressive goal for complete solution. I will just do
it and will see when we can get it in. No urgency. ;-)

> > 3. Make it configurable
> > Since we have images/tags in DB, I will just perform additional "select
> > count()" statements to retreive appropriate numbers.
> > This may have some
> > performance penalty for large collections
>
> no, because something like this already exist in curent implementation.
> Look on header of Album icons view. You have this information (:=)))

I have looked in that code, but AFAIR, it uses count() of images in the
widget, therefore it does not need to query database. For new feature, we do
not have this info yet (afaik).

I will probably do this in phases anyway as I would like to receive
review/feedback before final big patch:
1. Albums
2. Tags
3. Dates
4. Searches
5. Tag Filter

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

[Marcel Wiesweg]

> > - album tree view,
> > - date tree view
> > - search tree view
> > - tags filtrer tree view
> > - tags tree view from left side bar
> > - tags tree view on Comments & Tags
> >
> > Some of piece can be set on/off independetly, but not sure.
>
> Are search and date "albums" also stored in DB? In that case it should not
> be problem to implement it, otherwise we would need to count (slow...).

First place to look at is AlbumManager::scanPAlbums, scanTAlbums, scanDAlbums,
scanSAlbums.

For Physical and Tag albums, everything is done from AlbumManager and AlbumDB.
The information can be included in the AlbumInfo/TagInfo structure returned
from AlbumDB::scanAlbums/scanTags, and can be cached in the corresponding
Album objects.

Updating:
When a file is added, the KDirWatch will call DIO::scan, which lets the
ioslave scan and then calls AlbumManager::refresh, which call scanPAlbums.
So here is a possible place to update the count of existing albums (around
line 375?)

For tags, you could use the signals from ImagesAttributesWatch. For the first
signal you have to find out the tags of the imageId. Then you will need to
add a count function to the AlbumDB to retrieve the number of images.


Date albums are loaded in the AlbumManager with the digikamdates ioslave, with
folder==yes. You can see that as the date is stored as a string, all images
have to be read from db anyway, and the count can be retrieved.
I think for updating, the same applies as for physical albums.

Search albums are different. As far as I see looking quickly through the
source, the searches are executed only when the album has been selected (by
AlbumLister, and the digikamsearch ioslave). So retrieving the count here
would require to execute each search, and updating would be a nightmare too.

> I have looked in that code, but AFAIR, it uses count() of images in the
> widget, therefore it does not need to query database. For new feature, we
> do not have this info yet (afaik).
>
> I will probably do this in phases anyway as I would like to receive
> review/feedback before final big patch:
> 1. Albums
> 2. Tags
> 3. Dates
> 4. Searches
> 5. Tag Filter

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