Theoretically another option is to remove "smb" from the list of
protocols listed in X-KDE-Protocols in the desktop files for these
programs, which will force KIO to do the local download routine. This
effectively implements #6 without needing to involve the distros, but
still suffers from the issues of long wait time and no user notification
about what's going on (though we can improve that last one in KIO if
need be).
I tried this out, modifying VLC's desktop file locally and running `sudo
update-desktop-database, but VLC still tried to open files on Samba
shares by URL, not with a local path. Anyone know what might be up with
this?
Nate Graham
On 10/25/2017 07:19 PM, Nate Graham wrote:
Looks like the MPV folks have already rejected that approach:
https://github.com/mpv-player/mpv/issues/1512#issuecomment-77504217
They say it should be up to the system to provide them with an
accessible path.
So if the VLC folks say something similar (which I suspect is going to
happen), then we're back to the original set of options.
Nate
On 10/25/2017 05:49 PM, Nate Graham wrote:
That's certainly another option, though I suspect they might say that
it's the system's responsibility to pass them an accessible path. For
VLC, I've filed https://trac.videolan.org/vlc/ticket/18982
I will do the same for MPV and MPlayer.
Nate Graham
On 10/25/2017 05:12 PM, Christoph Feck wrote:
On 26.10.2017 00:47, Nate Graham wrote:
It seems that our users don't have a good way to play videos on
password-protected Samba shares:
https://bugs.kde.org/show_bug.cgi?id=355328
Why aren't VLC etc. ask for passwords on protected links? They
could/should use KWallet indirectly via the dozen cross-platform
key-store libraries that we have, e.g. libqtkeychain.
Christoph Feck
