| Summary: | SCHEMA : add album filter settings saved to database | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Jan Ziehm <janziehm> |
| Component: | Database-Schema | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | wishlist | CC: | anna, caulier.gilles, chentaocredungtao, iwannaberich, jdemeulle.photo, julien.t43+kde, kde-bugs, kde_bugs, marcel.wiesweg, philippe.roubach, qrczakoff, th0ma7 |
| Priority: | HI | ||
| Version: | 0.9.3 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Saving Filters UI mockup | ||
|
Description
Jan Ziehm
2008-02-26 23:54:59 UTC
Marcel, this entry is relevant of a new setting from DB. this is dedicaced to KDE4 of course... Are you agree to add a new DB field to store icon view filter settings in DB ? Gilles Marcel, Are you seen my comment #1? Gilles Caulier If we store this in the DB, it means the setting is "global", i.e. if there should be multiple users per DB some day, the setting would apply for all of them. I am not sure if this quality applies to such settings; if you think so, we can store it in the DB (in the settings table?) In the other case, we can store this in the usual KConfig settings just as well. To me this sounds more like a per-user, view option, nothing which should go into the data-base. On the other hand this would mean to store such a list of albums with their settings in the configuration file. Is this a feasible approach? Good question Marcel... But storing filter setting by album will take place on config file especially with huge collection. Also, loading this settings will take a while at startup... Mik, Gerhard, Arnd, Fabien, your viewpoint is welcome here. Gilles > Mik,
This is definitely "per user" setting so not place in base as Marcel
said. It it means performance hit - scrap it. Sorry but this setting can
be done quickly in interface so such trade off is a big no, no.
OTOH this is reasonable wish. Maybe mark it as LATER - if there will be
made space by performance gains in other areas implement it?
*** Bug 216276 has been marked as a duplicate of this bug. *** *** Bug 148996 has been marked as a duplicate of this bug. *** *** Bug 334671 has been marked as a duplicate of this bug. *** *** Bug 297289 has been marked as a duplicate of this bug. *** *** Bug 312683 has been marked as a duplicate of this bug. *** *** Bug 350373 has been marked as a duplicate of this bug. *** Ah, sorry for the duplicate. I actually searched for "save filter" and nothing came up, odd. Anyway, is it really necessary to save it "per album"? I guess just a quick and easy way to save and load filter settings will get the job done in a similar manner? Copy-Pasta of my suggestion: At the very top of the filters sidebar could be a text-input for a name, next to it a save button. Below a dropdown list with all saved filters, the default display could re d "load a saved filter" or "no saved filters". When loading one, the name should appear in the name input field above, so changes can be saved quickly or variations can be saved with only adding a letter/number to the original name. This way there is not too much space wasted. Well, this means a two-click operation every time one want's to load an album with a filter... Sorry, I have no idea about programming, but maybe this is also a better solution in case there are performance issues with the per-album-setting: instead of saving all filter settings per album, just save a reference to a saved filter... Created attachment 93652 [details]
Saving Filters UI mockup
Saving filters and setting a filter per album, from a pure UI perspective. I think something like this would be quick and easy to use.
Calibre (written in PyQt) has this feature implemented. Perhaps mockups and implementation ideas could be taken from there. I am also very interested in this feature. +1 It sure would be great to have this feature *** Bug 492165 has been marked as a duplicate of this bug. *** |