|Summary:||wish: search history list|
|Product:||kphotoalbum||Reporter:||Risto H. Kurppa <risto>|
|Component:||general||Assignee:||KPhotoAlbum Bugs <kpabugs>|
|Severity:||wishlist||CC:||bko, blackie, johannes|
|Latest Commit:||Version Fixed In:|
Description Risto H. Kurppa 2007-10-26 10:41:46 UTC
Version: svn (using KDE KDE 3.5.8) OS: Linux Having a list of previous search strings would be very useful: Use case: Having done some complex search you browse your photos, see something interesting there and decide to make a new search to see the images 'around' that interesting image (same folder, same people or so..). You do your changes there - but now when you want to get back to the original view you need to type in all the search criteria again. OK, I know there's the back button, but it's slow, say you go three or five steps away from the original view.. So in two words: search history I'd think it should not be too difficult to create: the strings are there, the thing is to save them somewhere and show (in the search dialog?). It could be saved in a temp file for one session only or also say 'last 15 queries' saved permanently.
Comment 1 Jesper Pedersen 2009-07-10 17:42:08 UTC
Here is a pretty cool junior job for someone who is ready for a slightly more complex junior job (it might take a few days). Here is my suggestion to it: From the users perspective the home page should have a "History item" which shows the last say 15 items. The items should be shown using the breadcrumbs (That is like at the bottom of the browser window). Here are some hints for the code: Step 1: Add a history item to the browser ----------------------------------------- Add the item for Browser/OverviewPage.cpp. You would need to adjust rowCount(), data(), and activateChild(). You may wish to make activateChild() do nothing for the first step. Step 2: Implementing a new page ------------------------------- For this you would need to implement a new page, which you instantiate in the OverviewPage::activateChild(). You do so by subclassing QAbstractListModel and BrowserPage much similar to the OverviewPage class itself. I'd suggest that you just use canned data for this step. Step 3: Making the new page work -------------------------------- For the new page to work, you would need to actually store the history somewhere in the data structures, and to update those data structures while browsing. The first question to consider will likely be, should the data be saved between sessions or not. I'd suggest not doing so initially, as that might be more work (however, for the "adding a favorites page" bug, we would need the code nevertheless). If you want to save the history in the database, then you would need to add methods to the DB interface (DB/ImageDB.h), which is implemented in XMLDB and SQLDB. I suggest that you keep the DB in mind, but goes for a local storage initially. In the data structure you would need to save the current search. If you go for storing the search in the DB, then you likely need to serialize it somehow). All the info about the current search is available in instances in DB/ImageSearchInfo.h When you have the data structure in place for this, your final task is to populate it during browsing. I think the easiest would be to hook into Browser::BrowserWidget::addAction (Browser/BrowserWidget.cpp). You would need a way to identify when the browser have made it to a "leaf", ie. you do not want a history looking like Jesper & Anne Helene & Noone Else & Mallorca Jesper & Anne Helene & Noone Else Jesper & Anne Helene Jesper But only want the topmost of those.