Version: 0.8.2-rc1 (using KDE 3.5.2, Debian Package 4:3.5.2-2+b1 (testing/unstable)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.16-1-486 In some circumstances, I'd like to view all the pictures of an album with its subalbums in the same panel. Together with the "tags filter", this is indeed some kind of search facility. I'd see that as a "Menu-bar -> View -> [ ] view subfolder" menu entry.
I suggest an variation on this. I would like the option of collapsing albums from a given level downwards. In other words, if I have the album structure shown below ... Album 1 subfolder A subfolder B Album 2 subfolder C subfolder D I would like to collapse the subfolders so that I see photos in all subfolders displayed as: Album1 Album2 Or I would like to collapse to the album level so that I see all photos from both albums and all subfolders displayed together.
Matthieu, for 0.9.1, i have implemented a new native slideshow on digiKam core (not a kipi-plugins) witch support reccursive album parsing. This is not really like you want, but it's can help you. Gilles Caulier
*** Bug 136902 has been marked as a duplicate of this bug. ***
It seems to work for tags in 0.9.1, but it would be nice if it would also work for albums. I oven have a folder structure like this: 2007 Christmas Location1 Location2 It would be nice to see all Christmas pictures of 2007 by just clicking on the album 'Christmas'...
*** Bug 147407 has been marked as a duplicate of this bug. ***
*** Bug 149101 has been marked as a duplicate of this bug. ***
*** Bug 149983 has been marked as a duplicate of this bug. ***
Created attachment 22098 [details] recursive view for albums This patch provides the functionality to recursively list sub-albums. Please test. (In digikamtags.cpp there is also a query which would only list tags, but not sub-tags. This is commented out in the patch.). If both work fine, this should be made configurable. Presumably the best place is a new enty in the View menu: Display -> [ ] Sub-Albums [ ] Sub-Tags (Suggestions for a better description are welcome!)
Why would one want to disable this feature? Even if you don't use/need this feature, I do not see any reason why somebody would prefer to have an empty window instead.
Thanks for the patch Arnd. Can I try it on the 0.9.x svn branch? Or is it for the qt4 version? If it works in 0.9.x then I'll try it later to give you some feeback. I understand what Frederik says, for me it's a more natural behavior. But I understand that some people would disagree. I think that to keep it optional is nice, but turned on by default. I would be even even nicer if it could be an option per album, in the album properties, at least in the parent albums. That would allow a very flexible configuration.
Antonio, KDE3 branch. I backport later all patches in KDE4 (:=))) Gilles
Thanks Gilles. Well, I've applied the patch, recompiled and tried it. It seems to work very good. The subalbums are displayed in a very clear way. Normal operations like editing a picture, filter with the tags (from the side panel) work as expected. It's a nice patch Arnd, thank you ;-).
Thanks Antonio for your feedback. Mik, I would to have your viewpoint about this patch, and especially about this comment from Antonio (#10): >I understand what Frederik says, for me it's a more natural behavior. But I >understand that some people would disagree. I think that to keep it optional is >nice, but turned on by default. I would be even even nicer if it could be an >option per album, in the album properties, at least in the parent albums. That >would allow a very flexible configuration. The pending question is about to have a setup for this feature... Gilles
Patch works OK. Also think this should be default behaviour.
Marcel, I would to have your viewpoint about this patch too, especially for KDE4 port. Code patched come from KIOSlave. I would to be sure than all can be done without any problem with new Database schema. Thanks in advance Gilles
Mik, Thanks for the review. I'm agree for the default behaviour... but i think we need a new option from setup to change it. Right ? Gilles
I think configurability would be really good. Moreover, this should be quickly changeable without going into the configuration menu, but directly in the View-menu. The same is true for tags: sometimes one would quickly change between just seeing those images which directly match a tag or those for which a parent tag is set. (This functionality is commented out in digikamtags.cpp). Then there is another important issue, which seems more difficult to address: having a merged view of all sub-albums. This is discussed in Bug 134389: WISH: Sort images by date - even when spanning albums http://bugs.kde.org/show_bug.cgi?id=134389 (see also Bug 116606: wish: I want to see again all my pictures having a tag in a flat view, not separated by albums http://bugs.kde.org/show_bug.cgi?id=116606 )
To arnd, #17. right, this will be usefull to change behaviours directly on pop-up menus. It's fine for you Mik ? Gilles
> I'm agree for the default behaviour... but i think we need a new option > from setup to change it. Right ? I am not sure. But if it has to be configurable it should be done from one of setup dialogs to not clutter menus.
1:1 in opinions, developer wins ;) Let it be in menus. Still think it should go into main configuration. Especially when in future there will be possibility to merge subalbums in one virtual folder. This should be all configurable. IMO it would be easier to manage all combinations when they would be put in one place, not dispersed between various menus.
Mikolaj, I don't distinguish between between developers or users opinions (I consider myself more of a user ...); of course in the end someone has to write the code, which might lead to one instead of the other solution ;-). Still, it is important to do things "right", so let me explain my reasons for having a menu entry in a bit more detail: When it comes to the configurability of features/appearance it is in my opinion important to distinguish between settings which are a) only changed very infrequently b) changed more often. Those which are changed more often should be quickly accessible via menus and not hidden in the configuration dialogue. Showing (or not showing) sub-albums and sub-tags is for me definitively an example of a setting, which I would really change frequently. E.g., consider an event, where some friends also took images. One way of organizing images is Event/IMG_????.jpg (own images) Event/Friend1/img_????.png Event/YouKnowWho/img_????.cr2 Depending on what I want to show, I would like to display all images, including those in the sub-folders, or just my images. Therefore I would prefer to have a quick way of changing this.
Mik, I'm agree with Arn. Look like it's the same behaviour with Tag pop-up menu from Caption & Tags side bar. You have a settings to "Toogle Auto" tags selection. Also, in Tags Filter sidebar pop-up menu, you have a "Matching Condition" settings. Gilles
Created attachment 22104 [details] screenshot of the place where suggested to put the button for switching As I saw this kind of UI on other software and I find it great: Just click a little button at the bottom of the folder list to switch between recursive and non-recursive behaviour. This does not forbid putting this feature also in a menu.
Sebastien, This position will not respect the layout between the status bar and the album folderview. Also, in current implementation, there are new filters on status bar : - rating filter - type mime filter - text filter (under construction on my computer - see B.K.O file #110136) A fresh screenshot here : http://digikam3rdparty.free.fr/Screenshots/searchbarconcept.png A better place for a button is on the top of folder view, on the right of sidebar tab title where you can already seen "My Albums". Also, like Arnd said previously, we can do the same for tags view. Gilles
For the KDE4 branch, the patch applies at a different place (libs/database/imagelister.cpp) and will be shorter, it's fine for me, I can port it. The config option (regardless what you decide on where and how) can probably be ported straightforward to KDE4, I would want to have this information in AlbumLister::openAlbum() so it can be passed to the IO job. For tags, there is no real change there, or did I miss something? Tags are listed recursively already. Note that the wish "merge all in one view, no categories" addresses a different level, that is a problem of the icon view class.
> For tags, there is no real change there, or did I miss something? Tags are listed recursively already. In the commented out code in digikamtags.cpp one has the opposite variant of just showing images precisely matching a tag. This gives both for tags and for folders the options of either showing them recursively or not.
OK, I accept arguments. Unfortunately I have to report bug. Let's create three albums on the same level, not nested: Paris, Paris 2005, Paris 2007. If I choose "Paris" I see pictures from all three albums.
Created attachment 22110 [details] corrected patch Thanks a lot for finding that bug (good test case!). The attached patch should solve it.
There is maybe one issue with that solution: it uses "/" in the path separator. According to the Qt docs this is ok, if "/" is throughout the code. Another option would be: urlWithTrailingSlash = QDir::cleanDirPath(kurl.path(1)); however, the previous line does not work, because cleanDirPath removes the trailing / again ... This following one works (for me), but there must have been a reason to use url = QDir::cleanDirPath(kurl.path()); instead of url = kurl.path() ?? urlWithTrailingSlash = kurl.path(1); To me this sounds like the best approach (but this is in ignornance of why cleanDirPath would be relevant here).
Second patch works for me.
Found another problem. At least for me this is strange behaviour: We have tree: Balbum Aalbum Calbum In all three are images. When you click on Balbum you will see contents of all three albums as requested. But they will be sorted in order: Aalbum Balbum Calbum Seeing structure of files I would expect to see order: Balbum Aalbum Calbum Hmm, it goes more messy with deep structure. Would it be easier to find album when sorted alphabetically according to their name, or sorted alphabetically by branch? I think this is worth some discussion
Created attachment 22133 [details] major revision of the patch withfull GUI integration Now the option for the recursive view of albums/tags is also integrated in the GUI (thanks a lot to Gilles for a nice patch ping-pong). Please test thorougly and report any issues!
To all in this room, This is URGENT. If you want to see this great feature implemented in 0.9.3 final release, please test. i18n freeze is not yet done, but if we can finalize this patch before that, we cannot integrate it in svn... We have delayed a little i18n freeze for that, but we cannot re-iterate this to infine. Release plan must be respected (:=))) Thanks in advance for your help Gilles
if we can finalize this patch before that ==> if we cannot finalize this patch before that (:=)) Gilles
I'm applying the patch now and recompiling, I'll let you know how it works for me as soon as possible.
Antonio, Go to View menu from Album gui. there is 2 new option to toogle on/off settings to display recursive albums or tags folders contents... Look these screenshot : http://digikam3rdparty.free.fr/Screenshots/subalbumsandsubtagssupport.png Gilles
Trying to apply patch but: patching file digikam/albumsettings.cpp Hunk #2 FAILED at 179. 1 out of 6 hunks FAILED -- saving rejects to file digikam/albumsettings.cpp.rej mikolaj@localhost extragear/graphics/digikam $ svn info digikam/albumsettings.cpp Version: 739339 OK. Checked albumsettings.cpp.rej. This is just stuff about default formats. Nothing crucial for this patch. Compiling.
Created attachment 22138 [details] corrected patch not sure why this got screwed...
Well, it's ready. I had a little problem applying the patch (after updating the svn), in particular for the file digikam/albumsettings.cpp. The rejected piece is: cat digikam/albumsettings.cpp.rej *************** *** 177,183 **** "*.png *.gif *.bmp *.xpm *.ppm *.pnm *.xcf *.pcx"; d->defaultMovieFilefilter = "*.mpeg *.mpg *.mpo *.mpe " // MPEG - "*.avi *.mov *.wmf *.asf *.mp4"; d->defaultAudioFilefilter = "*.ogg *.mp3 *.wma *.wav"; --- 179,185 ---- "*.png *.gif *.bmp *.xpm *.ppm *.pnm *.xcf *.pcx"; d->defaultMovieFilefilter = "*.mpeg *.mpg *.mpo *.mpe " // MPEG + "*.avi *.mov *.wmf *.asf *.mp4"; d->defaultAudioFilefilter = "*.ogg *.mp3 *.wma *.wav"; As you see something really minour, caused because the latest svn version includes the addition of '*.3gp' in the movie filters, so the lines are: d->defaultMovieFilefilter = "*.mpeg *.mpg *.mpo *.mpe " // MPEG "*.avi *.mov *.wmf *.asf *.mp4 *.3gp"; Well, that was the only patching problem, I checked manually that the rest was OK. Now the testing. I found the two toggle buttons that you have mentioned. When turning on "Include Album Sub-Tree", it displayes correctly the subalbums. They're correctly listed when sorting by date of by name. The option that I think that doesn't work is the one about the Include Tag Sub-Tree. I have the albums: Album1 +SubAlbum1 And the Tags: Tag1 +SubTag1 In Album1 I apply SubTag1 to one image. In SubAlbum1 I apply SubTag1 to one image and Tag1 to another. Experiment 1: - I click in SubAlbum1 to display its images. I turn on the "Include Tag Sub-Tree" and I keep disabled the "Include Album Sub-Tree" option. - I select Tag1. Result: Only one image is displayed, the one tagged with Tag1, but no the other one with SubTag1. Expected: Two images listed, one tagged with Tag1 and another with SubTag1. Experiment 2: - I click on the same album (SubAlbum1) - I select the two tags. Result: All tagged images are displayed. Experiment 3: - I click on Album1. - I select SubTag1. - I turn on the two toggle buttons. Result: The two tagged images with SubTag1 are listed. Experiment 4: - I click on Album1. - I select Tag1. - I turn on the two toggle buttons. Result: Only one image is displayed, the one tagged with Tag1. Expected: Three images, the one tagged with Tag1 and the two ones tagged with SubTag1. So, there are some problems displaying recursively the sub tags. But for the sub albums, without using tags, everything works nicely.
I suppose that my patching problem is the one that Mikolaj described and fixed by Arnd.
Works OK. On my system it wasn't turned on default. Not sure if this is case of existing configuration files. It should be turned on by default.
Mik, I'm not agree, the deafult behaviours must be the same than old version (i think) this is not really a problem : settings is saved between digiKam session... Gilles
Antonio, Mikolaj, thanks a lot for testing! For the tags sub-tree the default should be activated (because that corresponds to the previous behaviour). I will change that in the final iteration of the patch. Antonio, when you write "I select Tag1.", do you mean you select that tag in the tags-filter in the right sidebar? The recursive display of tags (more precisely: of images which are associated with a tag) only applies to selecting tags in the left side-bar.
Arnd, yes, exactly, on the right sidebar. I didn't know that it only was applied to the left one. I can try again this evening with the left side bar if you need it.
Mik, Gerhard, The new actions from View menu don't have a default shortcuts. It can be nice to have one. Any suggestions ? Gilles
*** This bug has been confirmed by popular vote. ***
SVN commit 740197 by abaecker: New feature: Recursive display of sub-albums and sub-tags, which can be selected by the user. CCBUGS: 128231 TODO:KDE4PORT M +2 -1 NEWS M +22 -2 digikam/albumlister.cpp M +3 -0 digikam/albumlister.h M +6 -3 digikam/albummanager.cpp M +31 -0 digikam/albumsettings.cpp M +6 -0 digikam/albumsettings.h M +41 -0 digikam/digikamapp.cpp M +3 -0 digikam/digikamapp.h M +4 -0 digikam/digikamappprivate.h M +3 -1 digikam/digikamui.rc M +2 -0 digikam/dio.cpp M +1 -0 digikam/welcomepageview.cpp M +112 -59 kioslave/digikamalbums.cpp M +4 -0 kioslave/digikamdates.cpp M +4 -0 kioslave/digikamsearch.cpp M +30 -10 kioslave/digikamtags.cpp M +3 -1 utilities/batch/imageinfojob.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=740197
Gilles, Personally I don't think that things would be changed very often. IMO better thing would be auxiliary menu/tool bar (a la FotoStation and AFAIR IMatch) at the top of album view with album gui options: sorting, sub-(tags|albums). Maybe move filtering there in future or exactly reverse: put those mini-menus in status bar. here is the screenshot: http://mac.softpedia.com/screenshots/10-489_1.png
I propose Ctrl+B as a short-cut. Contrary to Mikolaj I will use it often. This is mainly due to my organizing the albums with subdirs JPG and RAW, as configured in the camera CUI. But I would suggest (even more so if there's a short-cut) to reduce the menu to 1 entry that works both on tags and albums. Otherwise we'd need two short-cuts
SVN commit 741557 by mwiesweg: Forward-port the backend part of Arnd's recursive listing patch CCBUGS: 128231 M +66 -34 imagelister.cpp M +13 -5 imagelister.h WebSVN link: http://websvn.kde.org/?view=rev&revision=741557
SVN commit 741558 by mwiesweg: Forward port the frontend part of Arnd's recursive listing patch CCBUGS: 128231 M +30 -17 digikam/albumlister.cpp M +4 -0 digikam/albumlister.h M +6 -3 digikam/albummanager.cpp M +31 -1 digikam/albumsettings.cpp M +6 -0 digikam/albumsettings.h M +28 -0 digikam/digikamapp.cpp M +3 -0 digikam/digikamapp.h M +4 -0 digikam/digikamappprivate.h M +3 -1 digikam/digikamui.rc M +5 -1 kioslave/digikamalbums.cpp M +3 -0 kioslave/digikamtags.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=741558
About the recursive view of albums and recursive view of tags: Somehow I have the feeling that the interface is not done as intuitive as it could be. Namely, for the list of albums (left side-bar), and recursive view activated, consider a) - Album 1 - Subalbum A - Subalbum B clicking on Album1 will show the contents of Album 1 and Subalbum A and B. Visually, wouldn't it make sense, to also mark Subalbum A and Subalbum B as selected? b) For the collapsed situation + Album 1 clicking on Album1, wouldn't it make sense to always display the contenta of Album 1 and Subalbum A and B, even if the recursive view is not active? The same approach would also apply to the selection of tags. Somehow this would mean to move this from a way the view works to the way in which the selection is done. Note that this is to some extent also related to http://bugs.kde.org/show_bug.cgi?id=140743 http://bugs.kde.org/show_bug.cgi?id=144337 http://bugs.kde.org/show_bug.cgi?id=126871
Arnd Baecker a écrit : [bugs.kde.org quoted mail] If you to this, you have to be sure you will still be able to select easily subalbumA after Having selected Album1. (sometimes it is difficult to select an item that belong to a group already selected) > b) For the collapsed situation > + Album 1 > clicking on Album1, wouldn't it make sense to always display > the contenta of Album 1 and Subalbum A and B, even if the recursive view > is not active? > The same approach would also apply to the selection of tags. > > Somehow this would mean to move this from a way the view works > to the way in which the selection is done. > Note that this is to some extent also related to > http://bugs.kde.org/show_bug.cgi?id=140743 > http://bugs.kde.org/show_bug.cgi?id=144337 > http://bugs.kde.org/show_bug.cgi?id=126871 > > >
Created attachment 22364 [details] Enable Go To, if the destination album is different When the recursive album view is activated, it should be possible to go to the album (to which an image belongs), if it is different from the currently selected album.
Arnd, Your patch only support PAlbum... But TAlbum support also reccursive mode, and goto operation can be done in this case... Gilles
Yes, but currently the "Go To Tags" is only disabled, if there are no tags at all. So this is a bit different (more complicated?), because essentially the currently selected Tag has to be taken out of the list of displayed tags. Is this worth the effort?
There are still a few bugs, with current svn (kde3 branch rev 745513) When this is enabled ("include album sub tree" is clicked). - If I move a picture to a sub folder using drag and drop then the view is not updated. - If I move a picture form a subfolder to another brother subfolder then the view is not updated. - If I try to move a picture from a subfolder to itself it is possible and says file already exist. I think this should be impossible. - Wish : I would be nice to be able to move pictures from subfolders to subfolders by drag and drop inside the album view. Anyway it is nice work ! thanks all.
See also http://bugs.kde.org/show_bug.cgi?id=142774#c6 We should fix this before 0.9.3. Moreover, for large result lists there are various performance issues (in particular in connection with the new quick filters, even when in the end only 5 images match, responsiveness can be very slow. This is most obvious when using a slightly slower machine ;-).
Created attachment 22379 [details] Enable Go To, if the destination album is different version 2 Simplified patch...
SVN commit 745584 by cgilles: digiKam from KDE3 branch : invalidate items from album lister when drag & drop is used between icon view and album folder view to move files. CCBUGS: 128231 M +24 -12 albumfolderview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=745584
SVN commit 745587 by cgilles: digiKam from KDE3 branch : 0.9.3-rc1 will be released tomorow by Gerhard : apply patch from Arnd to Enable Go To, if the destination album is different. CCBUGS: 128231 M +5 -1 albumiconview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=745587
Hi, I'm trying for the 1st time the "Go To" feature and I found some issues... 1) "Go To" is only available thru the context menu, not in the main menu 2) In Album (or Date) view, if you "Go To"/Tag/Tagname, nothing happens It should switch to the Tag view (it works fine for Date). 3) In Tag view, if you "Go To"/Album, the album is showed in the main window, but the sidebar still show the Tags ! Here, it should switch to the Album. The same problem occurs in the Date view. All tests made using latest svn version.
Weird, 2) and 3) used to work, I just checked with a digikam version labeld 0.9.3-beta3 (which most likely was compiled from svn, so it could be anything >0.9.3-beta2 and <=0.9.3.beta3. With current svn I can confirm 2) and 3); grumble ....
Created attachment 22638 [details] make goto work again. Gilles found the origin of the problem: because of the added search boxes in the left-side-bar, all *FolderView had to be changed to *Box (apart from the dateFolderView). Remaining issue: the history does not work. See the discussion in the FIXME of the patch.
SVN commit 751121 by cgilles: apply patch from Arnd to restore GOto feature from digikamview. still TODO : check album history mechanism CCBUGS: 128231 M +6 -6 digikamview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=751121
SVN commit 751122 by cgilles: backport commit # 751121 from KDE3 branch. CCBUGS: 128231 M +6 -6 digikamview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=751122
SVN commit 751127 by cgilles: And now restore Album history mechanism in digikamview. Arnd, please check if all is fine for you... CCBUGS: 128231 M +29 -8 digikamview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=751127
SVN commit 751128 by cgilles: backport commit #751127 from KDE3 branch CCBUGS: 128231 M +29 -8 digikamview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=751128
To Fabien #62: > 1) "Go To" is only available thru the context menu, not in the main menu Impossible to fix it before 0.9.3 ==> i18n need to be changed. Please make a new B.K.O file. We will fix it for 0.9.4 >2) In Album (or Date) view, if you "Go To"/Tag/Tagname, nothing happens >It should switch to the Tag view (it works fine for Date). Fixed in svn. >3) In Tag view, if you "Go To"/Album, the album is showed in the main window, >but the sidebar still show the Tags ! Here, it should switch to the Album. >The same problem occurs in the Date view. Fixed in svn Gilles
To Arnd #68 : About See also http://bugs.kde.org/show_bug.cgi?id=142774#c6 We will use B.K.O file 142774 to fix it. It's time to close this file. It's become difficult to follow report. Please make new one on the right component if necessary... Gilles
Gilles, just for completeness: I just checked current svn and everything seems to be ok!
Thanks Arnd Gilles