| Summary: | search albums on read only album path | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Domenico Salvagnin <domenico.salvagnin> |
| Component: | Searches-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version: | 0.8.0 | ||
| Target Milestone: | --- | ||
| Platform: | Slackware | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 0.10.0 | |
| Sentry Crash Report: | |||
I would vote against this change. Running digiKam in a read only environment is like putting a steam locomotive on a track no longer than 100 meters, when the fun starts, it is over (please dont quote this). By accepting this patch we would indicate we support digiKam running in such environment, which is not the case, and is not reasonable to expect from an image management application. Just my viewpoint. I'm agree with you Tom. Performance issues is an important point... Gilles #1 Tom: o Allowing my younger familie members write access to my photo library is definitely no good idea. (or for a group at work) o Using a softlink was fine with 0.7.* but with 0.8 tagging and searching does not work because they can't access my db This is now really like Tom described, 90 % of digikam power lost :( o keeping n copies of the images would be a brain dead solution It's clear that with readonly library one can't use only readonly features, but in this case I only want to grant the others readonly so I don't care that they can't modify. And digikam with readonly features is still much more powerful than using konqueror, gwenview or whatever. #2 Gilles: It's not clear to me why this patch should influence performance of digikam Domenico offered to work on the implementation. If there are other places that needs checking for readonly stuff, can the developers point them out? [E.g. missing is a command line switch so one create a desktop icon with digikam --library-path /readonly/photo/collection] Maybe it's really a nightmare to properly support. But Domenico seems to have skill, time and energy to work on it. I vote for the feature [ can't comment of the patch quality :( ] Achim Achim Bohnet schreef: > o Allowing my younger familie members write access to my photo > library is definitely no good idea. (or for a group at work) There you could use showfoto I guess. > o Using a softlink was fine with 0.7.* but with 0.8 tagging > and searching does not work because they can't access my db > This is now really like Tom described, 90 % of digikam power > lost :( Exactly the point. If you would agree to this patch, we agree to receive other bugreports for read-only library paths, we should accept more patches in this area and we are obliged to maintain all that code. I think we should not follow that track. But again, that is my humble opinion, I'm not the digiKam maintainer. > o keeping n copies of the images would be a brain dead solution It would give your children the possibility to play with all those plugins we provide ;-) For excmple they can remove the red eyes of the horse you are going to buy them ;-) > It's clear that with readonly library one can't use only readonly > features, but in this case I only want to grant the others readonly > so I don't care that they can't modify. Right. So the consequence is that you can not save the search. It would be a bit weird to allow that and not save the tags temporary, so you can make a html gallery, right? > And digikam with readonly features is still much more powerful than > using konqueror, gwenview or whatever. > #2 Gilles: > > It's not clear to me why this patch should influence performance of > digikam My neither ;-) Thanks for the thoughts Achim, it will help decide what to do. First of all, thanks for your opinions. Now let me explain better the point. I agree that if you do _not_ want to support a read only library path, you should _not_ accept this patch, for the reasons exposed by Tom Albers. The question here is: are you going/willing to support read only library path? IMHO, you should. digikam is presented as a image manager with importing and organizing capabilities. Of course, after all the work spent organizing your collection of images, the best thing to can do is to make searches on it, like on a database. The new tagging/searching facility follows this direction. So why prevent a user with read only access to a db from making search queries on it? Another example is as folows: suppose you have organized (tagged, commented...) a collection of images and you have saved the whole thing on a CD: wouldn't be nice if digikam could open the CD and allows to make searches on it? I agree that if you really want to support a read only library path, a 4-line-patch is insufficient: the whole design must be aware of this scenario, but it seems to me a worthwhile effort. Btw, I _can_ help with the coding. Domenico Searching in read only repository is now implemented in digiKam for KDE4. I close this file now. Gilles Caulier |
Version: 0.8.0 (using KDE KDE 3.4.2) Installed from: Slackware Packages As explained in #114682, I need to use digikam on a read only library path. In this scenario searches are quite unusable, since it is not possible to add a search album. I've developed a 4-line-patch that solves the problem, which allows the creation of temporary search albums not stored in the db. This is the patch (svn diff output) --- albummanager.cpp (revision 484166) +++ albummanager.cpp (working copy) @@ -75,6 +75,9 @@ DAlbum *rootDAlbum; SAlbum *rootSAlbum; + // manage temporary search albums + int max_temp_salbum_id; + bool changed; PAlbumDict pAlbumDict; @@ -110,6 +113,9 @@ d->rootDAlbum = 0; d->rootSAlbum = 0; + // temporary search albums in the range 8000-9999 + d->max_temp_salbum_id = 8000; + d->itemHandler = 0; d->currentAlbum = 0; @@ -1110,7 +1116,11 @@ int id = d->db->addSearch(url.queryItem("name"), url); if (id == -1) - return 0; + { + // cannot insert search on db: will be a temporary album + id = d->max_temp_salbum_id; + d->max_temp_salbum_id++; + } SAlbum* album = new SAlbum(id, url, simple, false); album->setTitle(url.queryItem("name"));