I really wish, this wish would be fulfilled..
It is very annoying if you have an image and want to view the album of that image, but can't easily get there...

I  missed the easy jump from tags to album feature too.

At least for the 'goto album' one may also think about making
the Album header(s) in the thumbnail view clickable.

Achim

BTW - I Collection view and Album view should be merged. At the
moment there is confusion when creating new albums where they go.

For example when creating new album in Collection view it usually goes
as subalbum of clicked album but it is placed in other collection
(unclassified). Sorting this out is troublesome. Maybe make rule that
all subalbums belong to collection of master album. I think this is
quite sane assumption.

*** This bug has been confirmed by popular vote. ***

After a search or filtering by tag we presently get the list of thumbs
separated by folders. A very simple way of switching to the
corresponding folder would be to make the folder name a hyperlink 
which brings one to the corresponding folder.

This would not work, if all resulting images are shown jointly,
i.e. without folder-separation and e.g. sorted by date, 
as discussed in another B.K.O.
For this  something as proposed in #1 would be needed.

Another related point: one could even make elements displayed below
the thumb clickable: clicking on a tag brings one to all images with that tag etc. etc. (but maybe this belongs to the featurities department ;-)

Just one more tiny addition:

for the right-click "Goto Album" it would be nice
if then the album is displayed with this image as active image.

Created attachment 21556 [details]
provide goto album/date in the icon view

This patch (many thanks to Gilles for his help!)
provides a new entry
to the right-mouse-click menu in the album
view to go to the folder of a given
image (when in tags/searches or date view)
or to the images of the same date
(when in folder/searches or tags view).

There is one important issue:
when the destination view contains many images, 
it may happen that the current image (ie. the one from which
the goto is invoked) is not marked as current.


To me the reason seems that
in void AlbumIconView::refreshIcon(AlbumIconItem* item)
this 
 AlbumIconItem* icon = findItem(d->itemUrlToFind.url());
is called too early before the particular
item is available in the list.

What are possible solutions?
- should one retry a couple of times (with a short delay?)
  (but for how long - this might be system dependent)
- is there a signal when all items are listed?
  However this could lead to unnecessary waiting times
  if the image is already available.

The relevant sections in the code are
marked by FIXME.

Created attachment 21695 [details]
goto album and date added to right pop-up menu

Marcel pointed out the solution the remaining problem 
(for long result lists the correct item was not made visible).
At last it seems to work!

Please test thoroughly, it would be great if this could go into 0.9.3 ;-).

Agree to include it in 0.9.3...

Mik, 

if you have few moment, can you test this patch and report if all work fine for you.

I will review it later. I have others stuff on my TODO list to solve before.

Gilles

For me works perfectly in each case. Few comments:

1. Critical: "Go To", not "Goto"
2. Wish: Is it possible to add "Tag" target with submenu if many tags
   applied to image?
3. Bug?: Often I'd like to return to previous view, regardless of its
   type (Search, Date, Tag, Album) but after moving with "Go to" I am
   going to some strange place.

Apart from 1. nothing is really bad. Attaching Go To patch.


Created an attachment (id=21698)
goto.diff

Excelent Mik. Thanks !

Arnd, your viewpoint for 2/ and 3/ ?

Gilles

I should probably elaborate: "strange place" means that it is definitely 
not former view. I couldn't track any rule in what it is. Sometimes it 
is album, sometimes date, sometimes something different.

Tag going feature would be nice but it is definitely not showstopper. 
Also in future it will become common wish so it is probably best to 
include it from beginning (if possible). After few hours of sleep I 
don't think submenu is good thing. List of applied tags shouldn't be 
very long and could be integrated into "Go To" menu, maybe after 
separator.

----------------------------------------------------

Created attachment 21701 [details]
also allow goto tag

Mikolaj, thanks a lot for testing!

1/ Of course you are right! Still I think that "Go to" would be even better.
OK?
   (Actually the same in the menu below: "Open With" -> "Open with")
2/ I had a look at it, implemented apart from one problem, 
    see my technical question below.
   (However, I think adding a submenu is technically simpler, well,
    let's first get the functionality working)
3/ I tried a couple of cases, but it seems to work fine here.
   So presumably I am using a different ordering. 
   Could you describe a sequence in which this happens
   (Actually, I was about to ask, what is the "strange place", 
    i.e. a different folder or a wrong image, but then your previous
    message arrived.)
    Hmm, so this needs further debugging find out a reproducible
    scheme for this issue...

   However, what I do observe is that when going to a Date view,
   there is an empty entry in the history for the Back/Forward
   entries. Note that this also happens without the patch.
   I.e., this is a different bug ;-).

I also just realized, that goto was even possible when more
than one item is selected. In this case I disable the goto menu. OK?

Now the technical question for Gilles concerning /2:

I use TagsPopupMenu::REMOVE for this purpose:

TagsPopupMenu* gotoTagsPopup = new TagsPopupMenu(selectedImageIDs, 1000,
TagsPopupMenu::REMOVE);
int gotoTagId = gotoMenu.insertItem(i18n("Tag"), gotoTagsPopup);

connect(gotoTagsPopup, SIGNAL(signalTagActivated(int)),
				   this, SLOT(slotGotoTag(int)));

In the new routine 
  void AlbumIconView::slotGotoTag(int tagID)
I would like to 
  emit signalGotoTagAndItem(tagID, iconItem);
but I don't have the iconItem at hand.

Is there a simple way to pass the iconItem through via the connect?

Another important point: 
In slotGotoTag I need the 
  void selectItem(int id);
from tagfolderview.cpp, however it is defined in protected.
Is it ok to move it into public, or
should a different approach be used?
(It seems to work though ...;-)

Thanks, Arnd

> 1/ Of course you are right! Still I think that "Go to" would be even
> better.
> OK?


No. It is KDE convention to use caps in that situation.

> 2/ I had a look at it, implemented apart from one problem,
>     see my technical question below.
>    (However, I think adding a submenu is technically simpler, well,
>     let's first get the functionality working)


I have no doubts it is technically easier but from usability point of 
view submenu is bad.

> 3/ I tried a couple of cases, but it seems to work fine here.
>    So presumably I am using a different ordering.


I will make more tests in the evening.

>    However, what I do observe is that when going to a Date view,
>    there is an empty entry in the history for the Back/Forward
>    entries. Note that this also happens without the patch.
>    I.e., this is a different bug ;-).


Also noticed this and was preparing bug report :)
 
> I also just realized, that goto was even possible when more
> than one item is selected. In this case I disable the goto menu.


OK

----------------------------------------------------
Tolo - muszkieter z Dywizjonu 303. 
Historia Tola 

Created attachment 21709 [details]
goto patch, origin of empty dates in history found

The origin of the empty entries in the history for date folders is
that in album.cpp the title was not defined. With 
the following change at least a reasonable title is displayed.

DAlbum::DAlbum(const QDate& date, bool root)
      : Album(Album::DATE, root ? 0 : ++m_uniqueID, root),
	      m_date(date)
{
    // Set the name of the album
    // FIXME - could there be an internationalization issue here?
    QString date_title = date.toString("ddd MMM d yyyy");
    setTitle(date_title);
}


However, I am not sure, whether this is ok for internationalization issues.
Also the format might be subject to discussion, in particular,
if only a month is selected, and not an individual day/week.
(Not sure if this can be detected...)

Arnd, #15

KDE API can help to format date as string :

KDE3 : 

QString str = KGlobal::locale()->formatDateTime(dateTime, true, true);

KDE4 : 

QString str = KGlobal::locale()->formatDateTime(dateTime, KLocale::ShortDate, true);

Gilles

Created attachment 21710 [details]
better date formatting

Mikolaj, it would be great, if you could have a test with the updated
version. Also, I am not sure whether the history problem
also exists normally (i.e. without the patch) when changing album views....

Tested it and problem with history and changing album views doesn't
without your patch. BTW I played more with this feature and this is
really great! If you and Gilles cannot reproduce this I think you can
risk and include it in 9.3 .

> Tested it and problem with history and changing album views doesn't
> without your patch.


Sorry, just to understand it correctly: are you saying
a) there is no problem when changing album views
   (date, tag, physical album) when the patch is not applied.
   Only if the patch is applied, problems arise already
   for changing albums (even without using the "Go To" functionality)
b) there are problems with the history when using the
   goto functionality (i.e. when the patch is applied and using "Go To")
?

Thanks for testing!

Arnd

From Gerahrd, out B.K.O (directly on ML:

I tested it too before I make the tarballs. I played around with it (improved
date formating patch applied) and found no problem whatsoever.

I think we should include it into 0.9.3, it is a great feature.

Gerhard

To all,

I'm waiting than :

- Arnd, include fix from Gerhard in this room,

- Mik, test the new patch,

- Arnd finalize the patch accordinly...

An after i do a full review to be applied to svn by Arnd. Of course i will backport on trunk just after.

It' not urgent to apply it on 0.9.3-beta1. The patch must be finalized properly before to be public. We can delay publish on beta2 : i prefer a code finely finalized (:=)))

Gilles

Gilles, Mikolaj: there is no patch by Gerhard.

So we are already at the next step: Mikolaj, if you have time,
could you give the new one a try (also with the goto tags 
functionality).

Thanks a lot, Arnd

Sorry, I was imprecise and make some more tests  (with and without
latest patch).

There are some problems with history even without goto patch. I am not
able to reproduce them each time (maybe it depends on some special
settings of particular albums?) and cannot construct example but they
exists. With goto patch they are  much more visible but only when using
goto functionality. When using normal history it behaves like without
goto patch. To sum up:

1. Without goto patch: almost invisible problems.
2. With goto patch, normal history: almost invisible problems.
3. With goto patch, after using "Go To": general screw up.

My opinion is: if no one apart from me is able to reproduce this bug:
apply it to 0.9.3 . In worst case we will have more reports, and it will
be possible to catch some common ground.

Hi Mikolaj,

thanks a lot for testing!

The fact that there is no clear pattern might have to
do with different lengths of the result lists
(i.e. because images are listed in packages of 200), but
this is just a speculation.

Also, Gerhard mentioned yesterday on the IRC:
"""There is a small problem with history: when you 'go to' album or tags
from either oher view then the last access page of the new view is
inserted as previous page"""

I will try to find the place where things get screwed ...

Arnd

Created attachment 21740 [details]
slightly more polished patch

I looked around a bit through the code, but I did not understand
why/when the previous item is inserted into the album history when
going eg. from date view to album view.Somehow one gets the feeling
that it does not happen always (but it is difficult to track down,
because one has to write down the albums one is actually visiting on a sheet
of paper and compare with the history, so that one does not get completely
confused).

Gilles, maybe you will immediately see the orign of the problem if
you have review the patch (sorry, it's a long one ...)

Arnd,

Long or not, it will need to study your patch (:=))) So, i will do it, but let's me finalize my big Xmp patch for KDE4 branch...

Gilles

Looks like problems when jumping between albums and tags vanished. Also
first few jumps to date view are working. Only with more complex
history paths things are messed.

I just found this entry about problems with the history,
  http://bugs.kde.org/show_bug.cgi?id=148596
so it seems that it is not (or at least not exclusively ;-)
my patch causing it ...

Created attachment 21950 [details]
new patch version reviewed

Few coding style polish + icons add on pop-up menu.

Arnd, 

1/ Note than we will certainly need the same "Go To" sub menu in Image menu
from Album Gui...

2/ I will check indeep your TODO in DigikamView::slotGotoTagAndItem(), after
than your patch is commited in svn.

Gilles

SVN commit 731105 by abaecker:

New entry of the right-mouse-click menu in the album view to go 
to the folder of a given image (when in tags/searches or date view)
or to the images of the same date (when in folder/searches or tags view). 

CCBUGS: 96894
TODO:KDE4PORT



 M  +3 -2      NEWS  
 M  +3 -0      digikam/album.cpp  
 M  +11 -0     digikam/albumfolderview.cpp  
 M  +2 -0      digikam/albumfolderview.h  
 M  +113 -12   digikam/albumiconview.cpp  
 M  +11 -1     digikam/albumiconview.h  
 M  +24 -0     digikam/datefolderview.cpp  
 M  +3 -1      digikam/datefolderview.h  
 M  +80 -7     digikam/digikamview.cpp  
 M  +9 -2      digikam/digikamview.h  
 M  +7 -0      digikam/iconview.cpp  
 M  +2 -0      digikam/iconview.h  
 M  +3 -3      digikam/tagfolderview.h  
 M  +1 -0      digikam/welcomepageview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=731105

SVN commit 731198 by cgilles:

digiKAm from trunk (KDE4) : backport commit #731105 from KDE3 branch:

New entry of the right-mouse-click menu in the album view to go
to the folder of a given image (when in tags/searches or date view)
or to the images of the same date (when in folder/searches or tags view).

BUG: 96894



 M  +3 -0      album.cpp  
 M  +11 -0     albumfolderview.cpp  
 M  +2 -0      albumfolderview.h  
 M  +112 -14   albumiconview.cpp  
 M  +11 -0     albumiconview.h  
 M  +40 -5     datefolderview.cpp  
 M  +3 -1      datefolderview.h  
 M  +84 -8     digikamview.cpp  
 M  +9 -0      digikamview.h  
 M  +5 -0      iconview.cpp  
 M  +4 -0      iconview.h  
 M  +2 -2      tagfolderview.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=731198

I appreciate the fix for this bug, but I think it could be improved by making this behaviour default when switching views.

So when I select an image in Tag view, and I switch to Album view, I would like the Album view to keep the same image selected. I'm not sure how/if this would work with multiple image selection, but when one image is selected, I expect the image thumbnail to stay visible when I switch views.

Should I open a new wish?

/Simon

Simon, yes, please open a new wish. This one is closed and has already
a lot of comments. Thanks a lot, Arnd