New Tool: Tags Manager

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

New Tool: Tags Manager

Veaceslav Munteanu-2
Hello,

my name is Veaceslav and I will work on implementing a Tag Manager for digiKam as part of Google Summer of Code program.

Here is my proposal:


if you use tags a lot and find an important option that should be added, please let me know.

Also, all your suggestions are really appreciated. It will help me to build a useful tool.

Don't leave you suggestions until it's too late and lots of things must be rewritten.


Cheers,

Veaceslav

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Elle Stone
Keep nepomuk optional for Linux too! Not all of us run KDE desktops!

From your proposal:

"digiKam’s nepomuk interface is currently broken due to major changes
into Nepomuk Api and it’s currently not in use. Nepomuk sync options
are relevant and will allow digiKam to better integrate with KDE
Desktop. Other platforms such as Windows or Mac OS, doesn’t offer
support for nepomuk, and this features should be disabled when
compiling with corresponding CMake flag. Nepomuk interface was written
in 2009 when Nepomuk was at early stages of development and Sparql
queries were the only way of getting tags."

I run Linux but I don't run a KDE desktop. I don't need digiKam to
integrate with the KDE desktop. I only have installed the minimal KDE
installed to actually run digiKam and krita (these are the ONLY kde
apps that I run).

I dislike nepomuk intensely and don't want it installed on my
computer. If that is what it would take, I would actually consider
switching to Windows to avoid nepomuk. I wouldn't actually do it, but
I'd seriously consider it.

Many people run digiKam because it is the best photo management
software available. Many of these people run Linux. Many of them don't
use the KDE desktop and hence have no need for nepomuk. Even some KDE
users routinely disable nepomuk as soon as they install KDE.

So PLEASE keep nepomuk optional even for Linux users, and even for KDE
Linux users.

Kind regards,
Elle Stone

--
http://ninedegreesbelow.com - articles on open source digital photography
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Daniel Bauer-2


Am 25.06.2013 16:05, schrieb Elle Stone:

> So PLEASE keep nepomuk optional even for Linux users, and even for KDE
> Linux users.

Yes, please.
I use KDE but no nepomuk, will never use it...

Daniel

--
Daniel Bauer photographer Basel Barcelona
professional photography: http://www.daniel-bauer.com
google+: https://plus.google.com/109534388657020287386
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Veaceslav Munteanu-2
In reply to this post by Elle Stone
Actually digiKam contains code to communicate with nepomuk, but it's deprecated and need to be rewritten. 
I think I'll keep Nepomuk optional and will add an option to disable nepomuk sync even for users who have nepomuk installed, if devs won't mind.

And yes, I also run a minimal KDE with nepomuk and whole akonadi thing disabled.


On Tue, Jun 25, 2013 at 5:05 PM, Elle Stone <[hidden email]> wrote:
Keep nepomuk optional for Linux too! Not all of us run KDE desktops!

From your proposal:

"digiKam’s nepomuk interface is currently broken due to major changes
into Nepomuk Api and it’s currently not in use. Nepomuk sync options
are relevant and will allow digiKam to better integrate with KDE
Desktop. Other platforms such as Windows or Mac OS, doesn’t offer
support for nepomuk, and this features should be disabled when
compiling with corresponding CMake flag. Nepomuk interface was written
in 2009 when Nepomuk was at early stages of development and Sparql
queries were the only way of getting tags."

I run Linux but I don't run a KDE desktop. I don't need digiKam to
integrate with the KDE desktop. I only have installed the minimal KDE
installed to actually run digiKam and krita (these are the ONLY kde
apps that I run).

I dislike nepomuk intensely and don't want it installed on my
computer. If that is what it would take, I would actually consider
switching to Windows to avoid nepomuk. I wouldn't actually do it, but
I'd seriously consider it.

Many people run digiKam because it is the best photo management
software available. Many of these people run Linux. Many of them don't
use the KDE desktop and hence have no need for nepomuk. Even some KDE
users routinely disable nepomuk as soon as they install KDE.

So PLEASE keep nepomuk optional even for Linux users, and even for KDE
Linux users.

Kind regards,
Elle Stone

--
http://ninedegreesbelow.com - articles on open source digital photography
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Gilles Caulier-4
Hi all,

As Veaceslav said, Nepomuk have been implemented and will still optional.

As main code is already here, but have been broken due to API changes
from Nepomuk, this interface have been disabled.

The goal of Nepomuk job in this project is to re-activate this
interface, as Nepomuk recieve a copy of tags from digiKam DB.

In all case digiKam DB will never be moved to Nepomuk (:=)))...

Best

Gilles Caulier

2013/6/25 Veaceslav Munteanu <[hidden email]>:

> Actually digiKam contains code to communicate with nepomuk, but it's
> deprecated and need to be rewritten.
> I think I'll keep Nepomuk optional and will add an option to disable nepomuk
> sync even for users who have nepomuk installed, if devs won't mind.
>
> And yes, I also run a minimal KDE with nepomuk and whole akonadi thing
> disabled.
>
>
> On Tue, Jun 25, 2013 at 5:05 PM, Elle Stone <[hidden email]> wrote:
>>
>> Keep nepomuk optional for Linux too! Not all of us run KDE desktops!
>>
>> From your proposal:
>>
>> "digiKam’s nepomuk interface is currently broken due to major changes
>> into Nepomuk Api and it’s currently not in use. Nepomuk sync options
>> are relevant and will allow digiKam to better integrate with KDE
>> Desktop. Other platforms such as Windows or Mac OS, doesn’t offer
>> support for nepomuk, and this features should be disabled when
>> compiling with corresponding CMake flag. Nepomuk interface was written
>> in 2009 when Nepomuk was at early stages of development and Sparql
>> queries were the only way of getting tags."
>>
>> I run Linux but I don't run a KDE desktop. I don't need digiKam to
>> integrate with the KDE desktop. I only have installed the minimal KDE
>> installed to actually run digiKam and krita (these are the ONLY kde
>> apps that I run).
>>
>> I dislike nepomuk intensely and don't want it installed on my
>> computer. If that is what it would take, I would actually consider
>> switching to Windows to avoid nepomuk. I wouldn't actually do it, but
>> I'd seriously consider it.
>>
>> Many people run digiKam because it is the best photo management
>> software available. Many of these people run Linux. Many of them don't
>> use the KDE desktop and hence have no need for nepomuk. Even some KDE
>> users routinely disable nepomuk as soon as they install KDE.
>>
>> So PLEASE keep nepomuk optional even for Linux users, and even for KDE
>> Linux users.
>>
>> Kind regards,
>> Elle Stone
>>
>> --
>> http://ninedegreesbelow.com - articles on open source digital photography
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
>
>
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Elle Stone
In reply to this post by Veaceslav Munteanu-2
>I think I'll keep Nepomuk optional and will add an option to disable nepomuk sync
>even for users who have nepomuk installed, if devs won't mind.

Thanks! Sincerely and heartily thank you! If the devs do mind, let us
know so we can try to persuade them otherwise!

In the meantime, regarding tagging in general, has someone given you a
list of (or have you searched for) the relevant bug reports, feature
requests and perhaps relevant recent user threads? Such as this
thread? http://digikam.1695700.n4.nabble.com/How-to-remove-quot-left-behind-quot-tag-tree-td4660139.html

Regarding synchronizing the database and what's written to files:
One feature that I would like very much is having the tags written to
the database and the image or xmp files (I only write to xmp sidecar
files), but have the "write to sidecar (or image)" action not happen
automatically, but only as desired, such as at the end of a tagging
session. It might be nice to have an option to automatically offer to
write to file before closing digiKam.

At present I disable writing to the sidecar files until I'm finished
tagging (because writing to the database is so much faster), then
re-enable writing to write the tags to the files just before I close
digiKam (because I don't trust only having the database hold the
information). These extra "disable-enable-disable" steps are fiddly
and easy to forget.

Also, is better image searching/filtering by tags on your agenda?

Elle


--
http://ninedegreesbelow.com - articles on open source digital photography
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Veaceslav Munteanu-2
Thank you Elle, for giving me the link. I have some bugzilla entries, but with limited information. That's why I decided to post on this mailing list, maybe users can provide me with more info.

For now, I'm working on implementing the user interface(mock-ups from my proposal, if you want to change something tell me as soon as possible) and after this will see what policies to apply to maintain info in database and metadata coherent.

I will contact you if any questions will arise :)


On Tue, Jun 25, 2013 at 6:16 PM, Elle Stone <[hidden email]> wrote:
>I think I'll keep Nepomuk optional and will add an option to disable nepomuk sync
>even for users who have nepomuk installed, if devs won't mind.

Thanks! Sincerely and heartily thank you! If the devs do mind, let us
know so we can try to persuade them otherwise!

In the meantime, regarding tagging in general, has someone given you a
list of (or have you searched for) the relevant bug reports, feature
requests and perhaps relevant recent user threads? Such as this
thread? http://digikam.1695700.n4.nabble.com/How-to-remove-quot-left-behind-quot-tag-tree-td4660139.html

Regarding synchronizing the database and what's written to files:
One feature that I would like very much is having the tags written to
the database and the image or xmp files (I only write to xmp sidecar
files), but have the "write to sidecar (or image)" action not happen
automatically, but only as desired, such as at the end of a tagging
session. It might be nice to have an option to automatically offer to
write to file before closing digiKam.

At present I disable writing to the sidecar files until I'm finished
tagging (because writing to the database is so much faster), then
re-enable writing to write the tags to the files just before I close
digiKam (because I don't trust only having the database hold the
information). These extra "disable-enable-disable" steps are fiddly
and easy to forget.

Also, is better image searching/filtering by tags on your agenda?

Elle


--
http://ninedegreesbelow.com - articles on open source digital photography
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Andrew Goodbody-3
In reply to this post by Veaceslav Munteanu-2
Hi Veaceslav,

Bug 268688 https://bugs.kde.org/show_bug.cgi?id=268688 that is mentioned
in the thread that Elle linked to contains a number of conflicting
wishes. The part of your proposal that seems to address any of those
wishes is where you offer to 'Write tags from database to image' and
remove obsolete tags. I see this as a heavy handed maintenance operation
that will not really fix the underlying issue.
The way I would like the bug I would like to see resolved (that got
merged into 268688) is when a change is made to the tags hierarchy (ie
move or delete a tag) that will render images with applied metadata out
of sync, to be offered 3 options or to have one of them selected in
preferences:
1) apply change only to database
2) add change to a queue to be actioned later when it will update
affected images
3) apply change immediately to database and all affected images.
Also please note that I am talking about applying a 'change' - this is
not the same as syncing the database to the image metadata.

Also I would like to see https://bugs.kde.org/show_bug.cgi?id=309598 
resolved. And there should be a bug or wishlist somewhere about copying
tags from one image to others.

Good luck and all the best,
Andrew

On 25/06/13 11:18, Veaceslav Munteanu wrote:

> Hello,
>
> my name is Veaceslav and I will work on implementing a Tag Manager for
> digiKam as part of Google Summer of Code program.
>
> Here is my proposal:
>
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/slavuttici/35001
>
> if you use tags a lot and find an important option that should be added,
> please let me know.
>
> Also, all your suggestions are really appreciated. It will help me to
> build a useful tool.
>
> Don't leave you suggestions until it's too late and lots of things must
> be rewritten.
>
>
> Cheers,
>
> Veaceslav
>
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Veaceslav Munteanu-2

There is a reason why database and image metadata shouldn't be out of sync...

If I'm not mistaken, image collection scan read metadata from images and update database. Image scan can be triggered by your changes on local filesystem and you will have all your data from database overwritten.

My first idea was to operate all changes on database only. After you're finished, use sync options for either undo all changes by reading from image or save all changes to image by triggering write to image metadata and delete obsolete tags.

Still need to read all suggestions, maybe I missed something. Until then, I'm working on user interface.

On Jun 25, 2013 9:20 PM, "Andrew Goodbody" <[hidden email]> wrote:
Hi Veaceslav,

Bug 268688 https://bugs.kde.org/show_bug.cgi?id=268688 that is mentioned in the thread that Elle linked to contains a number of conflicting wishes. The part of your proposal that seems to address any of those wishes is where you offer to 'Write tags from database to image' and remove obsolete tags. I see this as a heavy handed maintenance operation that will not really fix the underlying issue.
The way I would like the bug I would like to see resolved (that got merged into 268688) is when a change is made to the tags hierarchy (ie move or delete a tag) that will render images with applied metadata out of sync, to be offered 3 options or to have one of them selected in preferences:
1) apply change only to database
2) add change to a queue to be actioned later when it will update affected images
3) apply change immediately to database and all affected images.
Also please note that I am talking about applying a 'change' - this is not the same as syncing the database to the image metadata.

Also I would like to see https://bugs.kde.org/show_bug.cgi?id=309598 resolved. And there should be a bug or wishlist somewhere about copying tags from one image to others.

Good luck and all the best,
Andrew

On 25/06/13 11:18, Veaceslav Munteanu wrote:
Hello,

my name is Veaceslav and I will work on implementing a Tag Manager for
digiKam as part of Google Summer of Code program.

Here is my proposal:

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/slavuttici/35001

if you use tags a lot and find an important option that should be added,
please let me know.

Also, all your suggestions are really appreciated. It will help me to
build a useful tool.

Don't leave you suggestions until it's too late and lots of things must
be rewritten.


Cheers,

Veaceslav


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


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

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Andrew Goodbody-3
On 25/06/13 20:00, Veaceslav Munteanu wrote:
> There is a reason why database and image metadata shouldn't be out of
> sync...

While this may be true in an ideal world unfortunately there are
scenarios that are somewhat reasonable for having them out of sync.
eg I have some photos sent to me by a friend that has some tags applied
to it. I do not want to remove those tags nor do I wish to import them
into my database but I do wish to add my own tags.

> If I'm not mistaken, image collection scan read metadata from images and
> update database. Image scan can be triggered by your changes on local
> filesystem and you will have all your data from database overwritten.
>
> My first idea was to operate all changes on database only. After you're
> finished, use sync options for either undo all changes by reading from
> image or save all changes to image by triggering write to image metadata
> and delete obsolete tags.

A sync operation is going to be very slow on any reasonably large
collection of photos unless you are going to maintain a list of affected
photos.

> Still need to read all suggestions, maybe I missed something. Until
> then, I'm working on user interface.

Andrew
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Elle Stone
Hmm, a couple of times now Veaceslav has asked for input regarding the
tagging user interface, and we all keep responding with comments about
the problem of database and image/xmp-sidecar synchronization.

So in response to the question of user interface:

I like the existing user interface as regards creating new tags and
adding tags to images.

 "- Expand Tag Tree -  All tag tree’s children will become visible
instead of expanding all parent nodes. This option is a must for a big
tag tree, because clicking each parent can be frustrating,"

Assuming I understand what you are saying, although having the option
of expanding all subtags with one click would be a nice touch, some of
my tag trees are deep enough that having everything expand by default
(no option to disable) would then require scrolling down to get to the
desired tag.

There is a user interface option that I would really like (although
perhaps it's already an option and I just don't know how to do it).
When I'm tagging images, often I also want to add a comment. But the
comment pane and new tag pane are tabbed, so only one at a time shows.
I would like to be able to put the user comment pane above the tag
pane, so both show at the same time, instead of having to click the
Description and Tags tabs to switch back and forth.

The only time I get very frustrated with the interface is when I want
to do a search that involves "this tag and not that tag". The search
(right panel) and filter (left panel) interfaces are both a bit
frustrating (I've never really figured out how to use the search
interface), and slooowww when trying to invert using the filter (which
never works anyway, so I've given up).

Elle

--
http://ninedegreesbelow.com - articles on open source digital photography
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Elle Stone
In reply to this post by Andrew Goodbody-3
On 6/25/13, Andrew Goodbody <[hidden email]> wrote:

> On 25/06/13 20:00, Veaceslav Munteanu wrote:
>> There is a reason why database and image metadata shouldn't be out of
>> sync...
>
> While this may be true in an ideal world unfortunately there are
> scenarios that are somewhat reasonable for having them out of sync.
> eg I have some photos sent to me by a friend that has some tags applied
> to it. I do not want to remove those tags nor do I wish to import them
> into my database but I do wish to add my own tags.
>

That's an excellent example of when and why you'd want the database
tags and image tags out of sync. In an ideal world digiKam would be
able to handle "always in sync" and and also "not always in sync". Has
anyone ever used a photo-management software that had this kind of
functionality implemented? If so, how did the user interface work? How
were the options phrased?

>
> A sync operation is going to be very slow on any reasonably large
> collection of photos unless you are going to maintain a list of affected
> photos.
>

This is true. That's why I disable writing to the images until I'm
done tagging for the session, then go back and enable writing to the
images and write them all at once (a slow process). Maintaining a list
of modified images sounds like a nice idea - would that of itself slow
things down?
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Jean-François Rabasse-2

On Tue, 25 Jun 2013, Elle Stone wrote:

> The only time I get very frustrated with the interface is when I want
> to do a search that involves "this tag and not that tag". The search
> (right panel) and filter (left panel) interfaces are both a bit
> frustrating (I've never really figured out how to use the search
> interface), and slooowww when trying to invert using the filter (which
> never works anyway, so I've given up).

Hello,

I happen to do the same kind of search and for this I use the color labels
as temporary markers. (I don't use them otherwise, so...)

1. Left panel, tags folder, select "that tag" (the unwanted one).

2. Ctrl-A to select all images then, right panel, tags edition, apply a
color label, say red.

3. Back to left panel, select "this tag".

4. Right panel, filter folder, select Color label : none,
all "that tag" (colored red) disappear and the final is
"this tag but not that tag".

Of course, this makes sense only if you don't use color labels in a
permanent way in your images collections. Probably, for most users,
pick labels or color labels are not definitive metadata and can be
used as useful temporary tools.

Regards,

Jean-François
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: How to keep digiKam from deleting image files

Jean-François Rabasse-2
In reply to this post by Elle Stone

On Mon, 24 Jun 2013, Elle Stone wrote:

> My point is all these images that were deleted by digiKam were
> read-only. I thought that protected the images from accidental
> deletion. A lot of people thing the same thing! IT DOESN'T.
> This is how Linux file permissions work.

A lot of people think the same thing, and also a lot of
developers.:-) Unix files access rights aim to protect users
data against other users, not against themselves. From the
moment you own, a file, a directory, you can do what you wish
with it, it's your stuff.

A correct file deletion implementation should first check file
status (the stat() or lstat() system calls) and if and only if
the write permission is set for the current user/owner should
effectively delete the file (the unlink() system call).

But very few software implementations are written that way and
respect files permissions. The only correct software I know,
from that point of view, is the GNU Linux 'rm' command. If you
try to remove one of your read-only protected file, the program
will check and ask you confirmation for removal. (Also with the
'rm -f' option, you specify force removal and ignore file
permissions.)

> Alas this issue obtains with any image management software,
> unless that software has the ability to disable the delete
> option. Anyone know of such a software?

Not only images management software, the Dolphin files browser
does the same. Most applications don't deal with low level
system functions and rather use environment libraries. E.g.
Digikam, Dolphin, and probably all KDE based applications,
don't delete files themselves but use a KDE library function,
KIO::del() And, too bad, this function is not correctly
implemented, ignores files permissions and issue a brutal system
unlink(). (Same behaviour as 'rm -f')

The wise philosophy would be to consider that from the moment
you use any data management (edition capable) software,
your data arrive into risky-land and you should be paranoiac.

And your suggestion (ability to disable delete option in a
software) is fine but won't protect you against other problems
or bugs. (Recently, Volker Henn reported images destructions
while doing batch rotations ! )

So, no way but always working with backups under hand,
and backups created before starting working. Thus, restoring a
previous state of a file will still remain possible.

Regards,

Jean-François



PS: a bit off-topic but there's a rock solid Unix way to protect
data, using read-only filesystems. It's kernel based implemented
and when a disk device is mounted read-only in your directories
tree, it's impossible to write, modify, delete anything,
even under the 'root' account.

Typical usage is to have images collections on an external USB
drive, mounted in the local drive tree, e.g. /usb/albums

Initial mount of the USB device :
     mount -o ro /dev/your-usb-device /usb/albums
Remounting in read-write mode, when needed :
     mount -o remount,rw /usb/albums
Remounting in read-only mode after modifications :
     mount -o remount,ro,noload /usb/albums

(The noload option is to be used with journalised filesystems as
ext3 or ext4.)

Also, one must su to root to run mount commands. This gives an
extra security level because it's not possible to remount
read-write from a keyboard typo.

Read-only mount is really secure; you the user, any application,
even root, won't be able to do any change. The major constraint
is to prevent fine control onto individual items. With files
permissions it's possible to set one or two files in read-only
mode. With a read-only filesystem it's all or nothing.

Security or flexibility...

As for me, this is the way I work. Having lost files in the past
made me a bit paranoiac:-)

My workflow looks like :

1. Copy new images from SD card to local drive, into a folder.

2. Do another copy from SD card into a folder on a USB drive,
temporarily in read-write mode, then switch back to read-only.
(Having two copies of the images, the SD card can be wiped for
next use.)

3. Work (images edition, metadata, etc.) on the local drive.

4. At some occasions, e.g. after a working session, remount the
USB drive read-write and do a sync from local folder, then back
to read-only mode.

The current state of USB collections is secured read-only.
And this allows all kind of tasks that don't need modifications,
folders browsing, copying images, doing searches, uploading to
web albums, etc., and images are protected from keyboard mistakes
or applications issues.
The risky state, read-write, occurs only at some rare occasions.

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

hajo
In reply to this post by Veaceslav Munteanu-2
Hi Veaceslav,

Good to hear that you help bring Digikam forward :)

There are a few things I was previously missing with DigiKam -- maybe because of my ignorance but probably for lack in the software:

1. Copy/Paste of Tags. Often I want a photo to have exactly the same tags as another, previously tagged photo. The way I "copy" the tags now is to highlight both and then search my way through the tag tree. That is really inconvenient, especially if the tree is deep. So a plain "copy/paste" would be real helpful.
2. Automatic application of tags to all photos in a group. I group raws and their jpegs together (whereas they really should just be different versions, but that's a different issue). If I then tag (or rate, or color flag, or or or) I always have to pay attention that I apply these changes to all photos in the group. I think that should be the default without me having to care about it.
3. Recently used tags list: When I work in one album, chances are that the tags are similar. Since I have a large tags tree I have to scroll a lot. I guess that could be significantly shortened if I had a list of the, say 10 (configurable, by dragging a window larger/smaller?), recently applied tags.

Greetings,
Hajo
-- 
Composed on my tablet. Apologies for typos.

On 25 Jun 2013, at 19:18, "Veaceslav Munteanu" <[hidden email]> wrote:

Hello,

my name is Veaceslav and I will work on implementing a Tag Manager for digiKam as part of Google Summer of Code program.

Here is my proposal:


if you use tags a lot and find an important option that should be added, please let me know.

Also, all your suggestions are really appreciated. It will help me to build a useful tool.

Don't leave you suggestions until it's too late and lots of things must be rewritten.


Cheers,

Veaceslav
<inline.txt>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Simon Cropper-3
In reply to this post by Elle Stone
On 26/06/13 06:33, Elle Stone wrote:
> Assuming I understand what you are saying, although having the option
> of expanding all subtags with one click would be a nice touch, some of
> my tag trees are deep enough that having everything expand by default
> (no option to disable) would then require scrolling down to get to the
> desired tag.

I use digikam for tagging and my tag list is also quite big and deep.

There are times when I am working on particular photos and wish to tag
people and other times where I wish to tag plant or animal attributes.

Being able to 'filter tags' so you only see those you are working on
would be very useful. Also being able to order tags so you can set up a
logical hierarchy would also be good. This would definitely improve my
workflow.

How I see the filtering is having various parent nodes tagged -- yes, a
tag on a tag :) -- with a particular category. These categories could
then be applied by checking a tick box on the side. So if I am working
on tagging plant/flora photos, I check the "plant/flora" category and
only those tags relevant to plants are visible.

--
Cheers Simon

    Simon Cropper - Open Content Creator

    Free and Open Source Software Workflow Guides
    ------------------------------------------------------------
    Introduction               http://www.fossworkflowguides.com
    GIS Packages           http://www.fossworkflowguides.com/gis
    bash / Python    http://www.fossworkflowguides.com/scripting
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Simon Cropper-3
In reply to this post by hajo
On 26/06/13 09:45, HaJo Schatz wrote:

> Hi Veaceslav,
>
> Good to hear that you help bring Digikam forward :)
>
> There are a few things I was previously missing with DigiKam -- maybe
> because of my ignorance but probably for lack in the software:
>
> 1. Copy/Paste of Tags. Often I want a photo to have exactly the same
> tags as another, previously tagged photo. The way I "copy" the tags now
> is to highlight both and then search my way through the tag tree. That
> is really inconvenient, especially if the tree is deep. So a plain
> "copy/paste" would be real helpful.

Yes I have the same problem.

> 2. Automatic application of tags to all photos in a group. I group raws
> and their jpegs together (whereas they really should just be different
> versions, but that's a different issue). If I then tag (or rate, or
> color flag, or or or) I always have to pay attention that I apply these
> changes to all photos in the group. I think that should be the default
> without me having to care about it.

This would be good. I have the original NEF file and derivative JPG/PNG
files in a group and always find I forget to tag each with the same
tags. I then have to resort to #1 above!

> 3. Recently used tags list: When I work in one album, chances are that
> the tags are similar. Since I have a large tags tree I have to scroll a
> lot. I guess that could be significantly shortened if I had a list of
> the, say 10 (configurable, by dragging a window larger/smaller?),
> recently applied tags.

This fits into my tag on tags or category of tags mentioned previously.
One tag would be dynamic, i.e. recently used, most commonly used, ...

>
> Greetings,
> Hajo
> --
> Composed on my tablet. Apologies for typos.
>
> On 25 Jun 2013, at 19:18, "Veaceslav Munteanu"
> <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>> Hello,
>>
>> my name is Veaceslav and I will work on implementing a Tag Manager for
>> digiKam as part of Google Summer of Code program.
>>
>> Here is my proposal:
>>
>> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/slavuttici/35001
>>
>> if you use tags a lot and find an important option that should be
>> added, please let me know.
>>
>> Also, all your suggestions are really appreciated. It will help me to
>> build a useful tool.
>>
>> Don't leave you suggestions until it's too late and lots of things
>> must be rewritten.
>>
>>
>> Cheers,
>>
>> Veaceslav
>> <inline.txt>
>
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>


--
Cheers Simon

    Simon Cropper - Open Content Creator

    Free and Open Source Software Workflow Guides
    ------------------------------------------------------------
    Introduction               http://www.fossworkflowguides.com
    GIS Packages           http://www.fossworkflowguides.com/gis
    bash / Python    http://www.fossworkflowguides.com/scripting
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Andrew Goodbody-3
In reply to this post by hajo
On 26/06/13 00:45, HaJo Schatz wrote:
> 3. Recently used tags list: When I work in one album, chances are that
> the tags are similar. Since I have a large tags tree I have to scroll a
> lot. I guess that could be significantly shortened if I had a list of
> the, say 10 (configurable, by dragging a window larger/smaller?),
> recently applied tags.

This exists already although not configurable. It is the small button
with the green down arrow at the bottom right of the tags pane on the right.
Unfortunately due to https://bugs.kde.org/show_bug.cgi?id=309598 it is
not actually as useful as it should be.

Andrew
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Andrew Goodbody-3
In reply to this post by Simon Cropper-3
On 26/06/13 02:13, Simon Cropper wrote:
> Being able to 'filter tags' so you only see those you are working on
> would be very useful. Also being able to order tags so you can set up a
> logical hierarchy would also be good. This would definitely improve my
> workflow.

Are you aware of the search box in the tags pane on the right? If you
have your tags in a hierarchy eg all your friends tags as sub-tags under
a tag 'friends' then when you want to tag your friends in a photo, type
'friends' into the search box. The 'friends' tag will be selected and
all sub-tags will show as well.

Andrew
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: New Tool: Tags Manager

Veaceslav Munteanu-2
Well,

I'm a little confused... please look at Tag Manager window mock-up. It's meant for managing tags (add, delete, edit properties, change hierarchy) and to write/sync changes... A lot of request are on image handling and I have no window here to display photos... 

Any request that need to select/add photos can't be added here... it's more like options for either context menu, or left sidebar.


On Wed, Jun 26, 2013 at 10:26 AM, Andrew Goodbody <[hidden email]> wrote:
On 26/06/13 02:13, Simon Cropper wrote:
Being able to 'filter tags' so you only see those you are working on
would be very useful. Also being able to order tags so you can set up a
logical hierarchy would also be good. This would definitely improve my
workflow.

Are you aware of the search box in the tags pane on the right? If you have your tags in a hierarchy eg all your friends tags as sub-tags under a tag 'friends' then when you want to tag your friends in a photo, type 'friends' into the search box. The 'friends' tag will be selected and all sub-tags will show as well.

Andrew

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


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