Opening files doesn't work on Arch Linux / KDE

[Tunous]

When I press Enter on any file other than a directory or binary executable file nothing happens.

System: Arch Linux Desktop Environment: KDE 5.9.4 Fman version: 0.3.8

Not sure if there is any other information I could provide.

[kek91]

Just wanted to mention it works fine in Gnome environment. If I get the chance I'll fire up a VM tomorrow to check MATE and LXDE as well

[mherrmann]

Thanks Kim :) Will be interesting to see what you find.

[kek91]

Actually I'm wrong, it affects Gnome (3) as well, but not for all file types. For instance, I can open images with no problems (and it doesnt have execute chmod, only read), but pressing Enter on other files such as .txt, .json, .css does nothing.

Issue is not present in Unity at least, works fine for all files there seemingly.

Edit:

No issue in XFCE environment (Xubuntu)

[mherrmann]

Interesting. As one can see in the Core plugin, it uses QDesktopServices.openUrl to open files. Apparently this doesn't always work. I can see in the docs for the function that it returns true or false depending on whether it was successful. Probably fman should check that return value and perform some appropriate action if it failed.

[Tunous]

Looks like something else is wrong. I made the following modification to the core plugin's _open command:

if use_qt:
    result = QDesktopServices.openUrl(QUrl.fromLocalFile(file_path))
    show_alert('Result: %s' % result)

and whenever I press Enter on any file it shows a dialog saying "Result: True" but the file doesn't open.

[mherrmann]

I see. I guess it's a problem with QDesktopServices.openUrl then.

Can you think of a shell command (say) for opening arbitrary files with their associated application on your system (eg Arch)?

[Tunous]

xdg-open works like this.

[Tunous]

#!/usr/bin/python3

import sys
from PyQt5.QtCore import QUrl
from PyQt5.QtWidgets import QApplication
from PyQt5.QtGui import QDesktopServices

if __name__ == '__main__':
    app = QApplication(sys.argv)

    result = QDesktopServices.openUrl(QUrl.fromLocalFile('/opt/fman/Plugins/Core/core/commands.py'))
    print(result)

    sys.exit()

In this simple test application openUrl does work correctly.

[mherrmann]

Heh, interesting. Probably it's because of this then?

if PLATFORM == 'Linux':
    use_qt = False
    try:
        Popen(
            [file_path], stdin=DEVNULL, stdout=DEVNULL, stderr=DEVNULL
        )
    except (OSError, ValueError):
        use_qt = True

The file you tried to open, does it have execution rights set?

[Tunous]

Nope, that's not the cause. The file I tried to open doesn't have execution rights. If I try to open files with execution rights then they are executed correctly.

[mherrmann]

I see. So from your previous comment, this means that openUrl doesn't work in fman but does work when you run in the separate script you posted above. I could have seen this earlier, sorry.

My suspicion is that it's because of some shared libraries that are loaded / not loaded by fman vs. your /usr/bin/python3. Do you think that would be a reasonable explanation?

[Tunous]

Perhaps, I don't really program in python so I don't know much about this.

[mherrmann]

No problem. Does it work if you use the following definition of _open?

from os import access, X_OK

def _open(pane, file_path):
    file_path = realpath(file_path)
    if isdir(file_path):
        pane.set_path(file_path)
    else:
        if PLATFORM == 'Linux':
            if access(file_path, X_OK):
                _execute_silently(file_path)
            else:
                try:
                    ret = _execute_silently('xdg-open', file_path).wait()
                    if ret:
                        raise OSError()
                except (OSError, ValueError):
                    QDesktopServices.openUrl(QUrl.fromLocalFile(file_path))
        else:
            QDesktopServices.openUrl(QUrl.fromLocalFile(file_path))

def _execute_silently(*args):
    return Popen(args, stdin=DEVNULL, stdout=DEVNULL, stderr=DEVNULL)

It still "doesn't do anything" when there is no associated application for a file type. But I'm hoping that it will at least work for your other files.

[Tunous]

No change for regular files but got this error for some of executable files.

Command 'Open' raised exception.

Traceback (most recent call last):
  File "fman/impl/plugins/plugin.py", line 90, in _run_in_thread
  File "/opt/fman/Plugins/Core/core/commands.py", line 128, in __call__
    _open(self.pane, file_under_cursor)
  File "/opt/fman/Plugins/Core/core/commands.py", line 143, in _open
    _execute_silently(file_path)
  File "/opt/fman/Plugins/Core/core/commands.py", line 155, in _execute_silently
    return Popen(args, stdin=DEVNULL, stdout=DEVNULL, stderr=DEVNULL)
  File "subprocess.py", line 676, in __init__
  File "subprocess.py", line 1282, in _execute_child
OSError: [Errno 8] Exec format error

[Tunous]

ret = _execute_silently('xdg-open', file_path).wait()

ret here is set to 4 which looking at the man page of xdg-open means "The action failed."

[Tunous]

I found out that if I run fman as sudo then it opens all files in browser...

[mherrmann]

This is getting weirder and weirder. I feel like it's very specific to your system. Maybe you can find an implementation of _open that works for you. It's difficult for me to come up with ideas at a distance.

[Tunous]

I'll try to figure something out. I'll also test it on different desktop environments to see if it's specific only to KDE or not.

[mherrmann]

Awesome, thanks.

[Tunous]

Tested with XFCE and everything worked correctly.

@kek91 can you check whether it's broken on KDE for you too?

[kek91]

Finally got around to try out KDE and (I'm sorry to say (for you)) it works great here. Running standard Debian 8.5 with no modifications and KDE (v 4.14.2). I can open all kinds of files (without +x permission) by pressing ENTER in fman.

This vm is pretty outdated so I'm gonna start all the pending updating now and see if it still works afterwards. Could be a newer KDE update, but if not I guess it's not related to KDE after all. I'll edit this post when the updates are done

Edit: 300 pending updates has now been installed. KDE is still version 4.14.2 and fman still works. Something weird happened now though so I can't check for updates anymore (error The method driver /usr/lib/apt/methods/https could not be found.), so I'm not sure if it actually did an apt-update before or if those 300 updates were discovered earlier. A reboot didn't fix the missing driver bug either so I'll ignore it for now since the VM is not in use.

Anyway, fman works fine on KDE 4.14.2, Debian 8.5, Linux kernel 3.16.0-4

[Tunous]

That's for KDE 4.14.2. I'm on KDE 5.9.4. I believe that they've rewritten it between versions 4 and 5 so there can be differences.

[kek91]

Oh am I that outdated :-) Well I got an excuse to test KDE Neon and I confirm the issue is present here as well, but it's worse than I thought because I can't open any files at all, no matter what permission I have.

I just tried to open files with ENTER and Open from the command palette but nothing happens. Tried several file types, first without execute permission and then with (yes I restarted fman after applying permissions just incase)

• .jpg
• .html
• .php
• .txt
• .deb

System details:

KDE neon 5.9 64-bit
KDE Plasma v5.9.4
KDE Framework v5.32.0
Qt v5.7.1
Kernel v4.8.0-41

[mherrmann]

Okay! So do I understand correctly that it's a problem with KDE 5?

[kek91]

Gnome (v3.14.1) too, but apparantly only for ASCII files (i.e. txt, md, js, css, json).

All other file types seem to work (zip archive, jpeg image, html (utf8 unicode text *) and normal binaries)

So to confirm my suspicion I used iconv to change the .html file encoding from utf8 to ascii and guess what, it still works in fman... so much for that theory. But out of the ~10 files I tested, I could open everything except ascii files (except for the newly created ascii html file)

[4goodapp]

Hello, I just, re-install fman and notice the same problem. Even click or souble have no effect. It didn't open any file with enter. I've tried to open fman with sudo and Surprise, folders have different icons ( the ones on Dolphin), and files open with enter BUT, They're not open with the default apps.

The fuzzy search with Ctrl+p need lot of improvement but, I guess I'll have to open another issue for that one.

[mherrmann]

I'll take a look, thanks.

[mherrmann]

I just tried fman on the most recent Arch / KDE build and can reproduce the problem. It is caused by fman shipping (and using) its own copies of Qt 5.6 .so libraries, which are incompatible with the 5.7/5.8 copies already present in recent KDE. I was able to solve the problem by deleting all libQt5*.so.* files from the install location, /opt/fman. This way, fman uses the system libraries, which work. I believe the solution (for Arch) will be to not have fman ship Qt itself, but declare it as a dependency for Arch's package manager (pacman). This will be done as part of #55.

[mherrmann]

A dedicated build of fman for Arch Linux was just released. In my tests, it resolves the issue :)