MTP, libgphoto2 & KFM

[Weng Xuetian]

Well, I'm just a unhappy mtp user and obviously doesn't represent the
opinion of others in kde.

I'd just like to state that the real issue is in mtp itself, having a
release method doesn't help to solve the real problem.

kio is different from gio, it's controlled per application, and any
application may start their own kioslave. kio itself indeed intend to
keep the kio slave live because it helps application to keep the
connection with it (e.g. sftp). Any kde file dialog may start a new
mtp kio slave.

As I said before, one possible solution is to move kde's mtp access
into a seprate process and expose some control interfaces on both dbus
and solid so it would be possible to release it from outside and also
solve the problem if there are two different kio mtp process started
by different process. Even now, accessing mtp device simultaneously
from dolphin and gwenview is not possible.

(CC orignal author of kio mtp, though not sure if he's still active)

On Tue, Dec 15, 2015 at 10:08 AM, Damon Lynch <damonlynch at gmail.com> wrote:
> My application frees control of the MTP device as soon as it can, unlike
> Dolphin / KIO. That's why the application can call on file browsers to open
> the MTP device at a certain folder location, and it works. (In Gnome, it can
> even instruct Gnome Files to highlight a particular file, but unfortunately
> that's impossible in Dolphin, which seems like a fairly serious usability
> bug to me).
>
> Regarding exclusive control of the MTP device, GIO has solved the problem
> already, as best it can be, by giving the user the ability to do a virtual
> "eject" of the application, i.e. instructing GIO to relinquish control of
> the device.
>
> That virtual eject is impossible to do in KDE's GUI or on the command line.
> It seems it's even impossible for me as a developer of an application
> outside of KDE to use code ask KIO to relinquish control.
>
> All KDE has to do is provide a virtual eject too, and expose it through the
> GUI and command line. That's the point I'm trying to make.
>
> Between the GIO and the current KDE approach, I know which design approach I
> strongly prefer. If the KDE community disagrees, sadly I will have no choice
> but to recommend to my users that some things will just be impossible to do
> if they run KDE.
>
>
>
>
>
>
> On Tue, Dec 15, 2015 at 10:53 PM, Weng Xuetian <wengxt at gmail.com> wrote:
>>
>> It is same for any other two applications who want to acess mtp at the
>> same time, you should actually blame mtp itself. For example, if a mtp
>> capable music player is already accessing mtp device via libmtp
>> directly, not gio or kio and another mtp capable file browser now
>> tries to read it and it would just fail. If user already opens the
>> application that you develops and now try to open it in dolphin via
>> KIO, it will also fail. Should we blame that your application breaks
>> kio's mtp? No, it is just the nature of mtp on linux system (maybe
>> also on windows, I don't know).
>>
>> If this problem cannot be handled by libmtp (which probably is the
>> case, otherwise it should be fixed already after all these years),
>> unless there is a centralized service that handles all mtp connection
>> in same process and all other process talks to it, it won't be solved.
>>
>> On Thu, Dec 10, 2015 at 3:47 AM, Damon Lynch <damonlynch at gmail.com> wrote:
>> >
>> > On Thu, Dec 10, 2015 at 3:00 AM, Weng Xuetian <wengxt at gmail.com> wrote:
>> >>
>> >> As far as I know, this is the limitation of libmtp. There is no
>> >> "mount" for mtp in kio, it's just a standalone kio process talking to
>> >> it. As you can see, even for gvfs it is possible that you need to
>> >> manually kill some process.
>> >>
>> >> http://sourceforge.net/p/libmtp/code/ci/master/tree/README#l165
>> >>
>> >> Kill the kio process of mtp might help to release the device.
>> >
>> >
>> >
>> > The point is that there is no way for the user to do this, either
>> > through
>> > the GUI or even the command line. The developer of a non-KDE app that
>> > wants
>> > to access the device that KIO has exclusive control over has to tell the
>> > KDE
>> > user "shut down any application that might have touched the MTP device".
>> >
>> > By contrast, Gnome provides a virtual unmount function, which they
>> > expose to
>> > the user through an eject/unmount button in Gnome Files, through the
>> > command
>> > line, and through the GIO API.
>
>
>
>
> --
> http://www.damonlynch.net