New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opening files doesn't work on Arch Linux / KDE #135

Closed
Tunous opened this Issue Apr 1, 2017 · 29 comments

Comments

Projects
None yet
4 participants
@Tunous

Tunous commented Apr 1, 2017

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.

@mherrmann mherrmann changed the title from Opening files doesn't work to Opening files doesn't work on Arch Linux / KDE Apr 2, 2017

@kek91

This comment has been minimized.

Collaborator

kek91 commented Apr 6, 2017

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

This comment has been minimized.

Contributor

mherrmann commented Apr 7, 2017

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

@kek91

This comment has been minimized.

Collaborator

kek91 commented Apr 7, 2017

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

This comment has been minimized.

Contributor

mherrmann commented Apr 7, 2017

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

This comment has been minimized.

Tunous commented Apr 7, 2017

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

This comment has been minimized.

Contributor

mherrmann commented Apr 7, 2017

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

This comment has been minimized.

Tunous commented Apr 7, 2017

xdg-open works like this.

@Tunous

This comment has been minimized.

Tunous commented Apr 7, 2017

#!/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

This comment has been minimized.

Contributor

mherrmann commented Apr 7, 2017

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

This comment has been minimized.

Tunous commented Apr 7, 2017

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

This comment has been minimized.

Contributor

mherrmann commented Apr 7, 2017

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

This comment has been minimized.

Tunous commented Apr 7, 2017

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

@mherrmann

This comment has been minimized.

Contributor

mherrmann commented Apr 7, 2017

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

This comment has been minimized.

Tunous commented Apr 7, 2017

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

This comment has been minimized.

Tunous commented Apr 7, 2017

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

This comment has been minimized.

Tunous commented Apr 7, 2017

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

@mherrmann

This comment has been minimized.

Contributor

mherrmann commented Apr 7, 2017

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

This comment has been minimized.

Tunous commented Apr 7, 2017

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

This comment has been minimized.

Contributor

mherrmann commented Apr 7, 2017

Awesome, thanks.

@Tunous

This comment has been minimized.

Tunous commented Apr 7, 2017

Tested with XFCE and everything worked correctly.

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

@kek91

This comment has been minimized.

Collaborator

kek91 commented Apr 10, 2017

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

This comment has been minimized.

Tunous commented Apr 10, 2017

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

This comment has been minimized.

Collaborator

kek91 commented Apr 11, 2017

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

This comment has been minimized.

Contributor

mherrmann commented Apr 11, 2017

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

@kek91

This comment has been minimized.

Collaborator

kek91 commented Apr 11, 2017

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

This comment has been minimized.

4goodapp commented Apr 23, 2017

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

This comment has been minimized.

Contributor

mherrmann commented Apr 24, 2017

I'll take a look, thanks.

@mherrmann

This comment has been minimized.

Contributor

mherrmann commented May 1, 2017

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

This comment has been minimized.

Contributor

mherrmann commented May 9, 2017

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

@mherrmann mherrmann closed this May 9, 2017

@mherrmann mherrmann removed the in progress label May 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment