[digikam] [Bug 347937] New: Collections added to "Removable Media" don't stay there

[René J.V. Bertin]

https://bugs.kde.org/show_bug.cgi?id=347937

            Bug ID: 347937
           Summary: Collections added to "Removable Media" don't stay
                    there
           Product: digikam
           Version: 4.10.0
          Platform: MacPorts Packages
                OS: OS X
            Status: UNCONFIRMED
          Severity: major
          Priority: NOR
         Component: setup
          Assignee: [hidden email]
          Reporter: [hidden email]

Adding collections to the "Removable Media" category on OS X works as a
"backdoor" to adding them to the "Local Collections" category.

Reproducible: Always

Steps to Reproduce:
1. Open the Preferences dialog, and go to the Collections panel
2. Use the "Add Collection" button next to the "Removable Media" category to
add a folder to that category
3. Close the Preferences dialog
4. Reopen the Preferences dialog and go back to the Collections panel

Actual Results:  
The collection (album) just added shows up in the "Local Collections" category.

Expected Results:  
The collection (album) just added shows up in the "Removable Collections"
category.

I have not attempted to verify, but I have a hunch the same would happen with
the "Network Shares" category. This is based on my assumption that this bug has
something to do with the way OS X mounts everything under /Volumes as opposed
to how Linux organises things.

I'm labelling this a Major issue as basically it disables all support for
removable media.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=347937

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Collections added to        |Collections added as
                   |"Removable Media" don't     |"Removable Media" change as
                   |stay there                  |"Local Collections"
                 CC|                            |[hidden email]

--- Comment #1 from Gilles Caulier <[hidden email]> ---
I think it's more relevant of Solid do not work well under OSX. In fact Solid
API is used here to register collection in DB...

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[René J.V. Bertin]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #2 from RJVB <[hidden email]> ---
Hmm, if you can point me to where/how this is done in digikam's sources, I can
have a look at Solid.

But I don't really see the point in providing the categories through the
settings dialog if afterwards you're only going to use an external library to
determine whether a collection is local, on a removable or on a network share.
Why not store the information how a collection was added and use it as an
additional property (or to override whatever Solid tells you on OS X and
potentially other platforms where Solid dysfunctions)?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=347937

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #3 from Gilles Caulier <[hidden email]> ---
Marcel,

Can you clarify/guide RJVB according with previous comment.

Thanks in advance

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[René J.V. Bertin]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #4 from RJVB <[hidden email]> ---
(In reply to RJVB from comment #2)
> Hmm, if you can point me to where/how this is done in digikam's sources, I
> can have a look at Solid.

I can try to see what goes wrong in Solid when I know how it is being used by
digiKam.

> share. Why not store the information how a collection was added and use it
> as an additional property (or to override whatever Solid tells you on OS X
> and potentially other platforms where Solid dysfunctions)?

Collections are added as `Local`, `Removable` or `Network`, and treated
accordingly. Apparently this property isn't stored; instead you rely on Solid
to keep track of which collections are on local, removable or network storage.
If Solid isn't reliable in telling you if a collection directory is on local,
removable or network storage, you should store that property with the other,
non-hardware related properties (like the collection name).

This would probably also make it easier to work with temporary collections,
"scratch" folders that are on local storage but not always present. The same
could apply to collections on "fancy" filesystems: I have no idea how Solid
would recognise a ZFS pool or dataset for instance.

There's an underlying question of principles here: should you use technology to
second-guess the user, or should you just take it for given when s/he tells you
"this collection is on removable media, treat it as such"?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #5 from Marcel Wiesweg <[hidden email]> ---
Most of the relevant code is in libs/database/collectionmanager.cpp
You can find the UI part in utilities/setup/setupcollectionview.cpp

Network shares are indeed treated differently, they are stored by mount path.
Solid does not care for network shares, nor did any other system library in KDE
or Qt ar the time. I guess it's still the same.

The fact that there's an extra button to add removable media is due to UI
design decisions, we need an extra button for network collections and there's
no good way to have a common button for normal storage volumes.
Apart from that, to digikam there is no real difference if you remove your USB
stick or screw out your harddisk, in either case the storage volume is not
available. There are two flags in Solid::StorageDrive, isHotpluggable() and
isRemovable(), which determine the "removable" property.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[René J.V. Bertin]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #6 from RJVB <[hidden email]> ---
Thanks, I'll have a look.

Right now, I'm getting errors about all collections on non-mounted removables
when I start digikam. Are you saying that would still be the case if it knew
those missing collections were on removables instead of considering them to be
on fixed storage?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #7 from Marcel Wiesweg <[hidden email]> ---
What kind of errors do you get? Normally, the collection should silently be
marked as not available. It's not an error if a removable drive is removed.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[René J.V. Bertin]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #8 from RJVB <[hidden email]> ---
I agree it's not an error, but as I described above, on OS X:

1) collections on removable storage are classified among the ones on a fixed
harddisk
2) as a result, an error is printed that they're not available when that's the
case, because digikam doesn't know it's not an error because of the removable
nature of their support.

That's why I suggested that the easiest and most straightforward fix that would
work in all situations where Solid doesn't work reliably, would be to store the
isRemovable state provided by the user when s/he adds the collection, rather
than relying on Solid to reproduce it. Alternatively, remove the choice
completely and let isRemovable be determined by Solid even when the collection
is added. I don't know what it means that "there's no good way to have a common
button for normal storage volumes". Either you rely on Solid to guess the
nature of a volume (and you only need a separate button for networked
collections), or you rely on what the user indicates (and you need a button for
removable collections if you want to support that notion).

Again, I'm a proponent of listening to the user. If you support the notion of
removable collections (however small the difference with non-removable
collections) and let the user indicate which is what, you don't second-guess
this choice. You could ask confirmation if  Solid tells you otherwise on
platforms where this is reliable, and you could use subsequent changes as an
indication that a disk was for instance moved to an external enclosure (and ask
confirmation if this change should be recorded). But in my book, if the user
tells you to consider a collection as removable  (or non removable), you
conform as long as this instruction does not lead to conflicts or impossible
situations. But then I try to pay attention to the little details that annoy me
when using someone else's software :)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #9 from Marcel Wiesweg <[hidden email]> ---
In any way there is now no compatible fix to store the "isRemovable" bit.
I meant to say that the fact that there are three buttons is more or less
deliberate, in some other UI design there would be no separate buttons. It's
like two doors leading into the same room.

IMO, Solid should be fixed on OS X. We have a set of high-level platform
libraries and should in our applications not add complex workarounds for bugs
in the underlying library.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[René J.V. Bertin]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #10 from RJVB <[hidden email]> ---
What do you mean with "no compatible fix"? That everything about the defined
collections is stored in a fixed-format database which doesn't provide the
flexibility to add a parameter? I've wondered why the list of collections isn't
stored in a standard rc file too.

Solid is incomplete on OS X, and I got dissuaded from spending much time on it
IIRC. Not that that was hard to do: I'm not familiar with IOKit, and getting
more of it into Solid looks to be writing a considerable amount of doubly
navel-staring (pardon, introspective) code ...

Are you sure that Solid on Linux recognises all kinds of removable storage
correctly? How does it handle ZFS pools/datasets, for instance? For example, I
have datasets on my ZFS root pool that are not always mounted. They live on my
internal harddisk, though. Come to think of it, there isn't even need to
consider uncommon filesystems: one could keeps photo collections on partitions
of the internal disk that aren't always mounted; the MS Windows partition would
probably a good example.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #11 from Gilles Caulier <[hidden email]> ---
New digiKam 4.11.0 is available with official PKG installer for OSX.

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[René J.V. Bertin]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #12 from RJVB <[hidden email]> ---
Indeed, as can be expected from the exchange above.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #13 from Gilles Caulier <[hidden email]> ---
digiKam 4.12.0 is out.

https://www.digikam.org/node/741

Problem still reproducible ?

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[René J.V. Bertin]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #14 from RJVB <[hidden email]> ---
On my ToDo list for when temperatures drop !

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #15 from [hidden email] ---
digiKam 5.0.0-beta7 Installer for MacOSX is now available for testing...

https://drive.google.com/open?id=0B7yq-xFihT0_ZjlIazRPb1lRTEE

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #16 from [hidden email] ---
RJVB,

Do you seen my previous comment ?

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=347937

--- Comment #17 from RJVB <[hidden email]> ---
Yes, but I suppose the detection of removable vs. local devices is still done
via Solid? That library hasn't changed to my knowledge so I didn't run out to
check if this issue is still present ....

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=347937

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|setup                       |Database-Setup

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=347937

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Collections added as        |SETUP : Collections added
                   |"Removable Media" change as |as "Removable Media" change
                   |"Local Collections"         |as "Local Collections"

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel