digiKam › digikam-devel

[Bug 117287] New: search albums on read only album path

Classic

List

Threaded

8 messages Options

Domenico Salvagnin

[Bug 117287] New: search albums on read only album path

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.kde.org/show_bug.cgi?id=117287
Summary: search albums on read only album path
Product: digikam
Version: 0.8.0
Platform: Slackware Packages
OS/Version: Linux
Status: UNCONFIRMED
Severity: wishlist
Priority: NOR
Component: general
AssignedTo: digikam-devel kde org
ReportedBy: domenico.salvagnin tin it

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"));
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Bugzilla from tomalbers@kde.nl

[Bug 117287] search albums on read only album path

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.kde.org/show_bug.cgi?id=117287

------- Additional Comments From tomalbers kde nl 2005-11-30 10:45 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Gilles Caulier

[Bug 117287] search albums on read only album path

In reply to this post by Domenico Salvagnin

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.kde.org/show_bug.cgi?id=117287

------- Additional Comments From caulier.gilles free fr 2005-11-30 10:48 -------
I'm agree with you Tom. Performance issues is an important point...

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Bugzilla from ach@mpe.mpg.de

[Bug 117287] search albums on read only album path

In reply to this post by Domenico Salvagnin

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.kde.org/show_bug.cgi?id=117287

------- Additional Comments From ach mpe mpg de 2005-11-30 11:37 -------
#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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Bugzilla from tomalbers@kde.nl

[Bug 117287] search albums on read only album path

In reply to this post by Domenico Salvagnin

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.kde.org/show_bug.cgi?id=117287

------- Additional Comments From tomalbers kde nl 2005-11-30 12:28 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Domenico Salvagnin

[Bug 117287] search albums on read only album path

In reply to this post by Domenico Salvagnin

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.kde.org/show_bug.cgi?id=117287

------- Additional Comments From domenico.salvagnin tin it 2005-11-30 14:18 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Gilles Caulier

[Digikam-devel] [Bug 117287] search albums on read only album path

In reply to this post by Domenico Salvagnin

Gilles Caulier-4

[Bug 117287] search albums on read only album path

In reply to this post by Domenico Salvagnin

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.kde.org/show_bug.cgi?id=117287
caulier.gilles gmail com changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED

------- Additional Comments From caulier.gilles gmail com 2008-06-24 22:16 -------
Searching in read only repository is now implemented in digiKam for KDE4.

I close this file now.

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel