search

yatima1460 / Drill

Search files without indexing, but fast crawling
https://drill.software/
GNU General Public License v2.0
268 stars 21 forks source link

AppImage: folders and some files don't open when double clicked #20

Open pizzadude opened 5 years ago

pizzadude commented 5 years ago

Linux distro Linux Mint 19.1 Cinnamon

Build Version 1.131

Describe the bug In Linux Mint 19.1 Cinnamon (which uses Nemo file manager) double clicking a directory does nothing, but opening files such as videos and pictures works. Opening .txt files does nothing also. In Mint, xed is the default text editor.

To Reproduce Steps to reproduce the behavior: Try to open a txt file or directory with default applications.

Expected behavior Double clicking a directory should open with nemo, opening a text file should open with xed.

yatima1460 commented 5 years ago

The only reason I can think why this happens is because by not having a default application set xdg-open will probably do nothing at all. Other possible reasons are if they have root-like permissions or strange characters in the path (unlikely)

But pretty sure it's because Mint uses its own xdg implementation hidden behind xdg-open, so if possible to fix this I would need to check if the file opening succeeded and then if not use other implementations like Mint's one

yatima1460 commented 5 years ago

Does the folder open if you type "xdg-open /full/path/to/folder"?

pizzadude commented 5 years ago

Yes, they open fine with xdg-open.

yatima1460 commented 5 years ago

Okay so we can exclude xdg-open implementations, I wonder if it's a permission problem or something else, in the next version I will try to implement a messagebox that pops up if the opening failed reporting the error, so you can report it here.

I will let you know when I've implemented the messagebox!

yatima1460 commented 5 years ago

Maybe I will start a VM with Mint too

pizzadude commented 5 years ago

Note that pictures and videos both open. My video player is SMPlayer and picture viewer is Nomacs, both sandboxed by firejail (symlinked to firejail in /usr/local/bin/) I didnt sandbox Nemo or Xed, which don't work.

pizzadude commented 5 years ago

BTW despite these problems thanks for making this program, its the fastest GUI file searching tool I've used.

yatima1460 commented 5 years ago

It seems distros based on Ubuntu have their own xdg-open too, maybe first trying that and then falling back to xdg-open in case it does not work would be a good idea 🤔

yatima1460 commented 5 years ago

@pizzadude

Booted Mint in a VM to check this, got this error:

image

Works on .deb, does not work in AppImage, I will contact the AppImage creator, it's either an AppImage problem or xed doing something badly.

I recommend you to use the .deb until this gets fixed by them.

yatima1460 commented 5 years ago

https://twitter.com/yatima1460/status/1129893672215023616

pizzadude commented 5 years ago

Thanks, the deb version works without issue when opening files and folders with xed and nemo. Also, you might want to change the name of the binary that goes into /usr/bin/ because drill is another program from a package that is available in the repositories, just in case other people have it installed so it doesn't conflict. Maybe change the /usr/bin/ binary to drill-gtk

yatima1460 commented 5 years ago

I don't know what to do with this, it truly seems an AppImage bug exporting the wrong environment variables

yatima1460 commented 5 years ago

@probonopd any news about this? Is it an AppImage bug or a Linux Mint bug? Meanwhile I added a warning notice on my website Thanks

yatima1460 commented 5 years ago

I'm starting to believe the real culprit here is Python, it seems if some environment variables are messed up, some Python software will not start

yatima1460 commented 5 years ago

Linux Mint is the only distro that gave me problems with AppImage The AppImage even works on Arch

probonopd commented 5 years ago

If an AppImage produces

then it is a bug in that AppImage and needs to be fixed by the creator of that AppImage (by bundling Python and all Python modules the application needs to run).

yatima1460 commented 5 years ago

@probonopd The problem is that when a user finds a txt file on Linux Mint and double clicks it on Drill I open the file using xdg-open filepath and I get that error because the default text editor on Linux Mint is written in Python

yatima1460 commented 5 years ago

So it seems like xdg-open still opens the Python software like it was in the AppImage and not outside?

That's where my knowledge about this ends

probonopd commented 5 years ago

Sorry, from your description I can't follow you. Can you describe, step-by-step, how to reproduce the issue using, e.g., linuxmint-19.1-cinnamon-64bit.iso?

yatima1460 commented 5 years ago

Search for a text file on Drill on Linux Mint and double click it. Nothing happens.

And the real error behind the scenes is: image (you could maybe see it if you run the AppImage from terminal, maybe not)

So the TL;DR is: using xdg-open path/to/textfile.txt on Linux Mint does not work because the default editor is written in Python and it seems the AppImage exports the wrong environment variables

pizzadude commented 5 years ago

It's a problem with directories also, not just text files.

Steps to reproduce: Install Linux Mint 19.1 Cinnamon Open Drill AppImage Search for a folder or text file Notice that it won't open

yatima1460 commented 5 years ago

xed is written in Python but I wonder why directories don't open too, nemo is written in C no? @pizzadude Can you reconfirm it on the latest AppImage?

https://github.com/yatima1460/Drill/releases/download/1.237/Drill-GTK-linux-x86_64-release-1.237.AppImage

pizzadude commented 5 years ago

@yatima1460 That appimage doesn't launch at all.


(AppImageLauncher:26782): GdkPixbuf-CRITICAL **: 19:13:42.216: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(AppImageLauncher:26782): GdkPixbuf-CRITICAL **: 19:13:42.216: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
/tmp/.mount_Drill-SiByZR/usr/bin//drill-search-gtk: line 2: /opt/drill-search-gtk/drill-search-gtk: No such file or directory
yatima1460 commented 5 years ago

The fact that only Linux Mint has problems really makes me think about the entire distro not following Linux standards.

pizzadude commented 5 years ago

I'm not too sure about that...

pizzadude commented 5 years ago

Anyways, the deb works fine. Speaking of that, I should update drill...

yatima1460 commented 5 years ago

Let me know if the latest 1.237 deb works fine, if it does it's probably a combination of Linux Mint not following standards + AppImage having a bug somewhere

yatima1460 commented 5 years ago

It can't be only an AppImage bug because the AppImage works everywhere but on Mint and it can't be only a Linux Mint bug because the .deb works perfectly everywhere and the AppImage is also created by just extracting and re-archiving the .deb basically. It's a combination of at least two things, and I hope Python is not the third.

pizzadude commented 5 years ago

You want to know something weird?

After I updated the deb to the latest version (I hadn't updated in about 25 days), the latest AppImage started launching.

For some reason, if I have the deb installed, and I launch the AppImage, the AppImage tries to launch the deb version... The executable name changed since last time I installed the deb version, so that's probably why the AppImage didn't launch. (But it's not the AppImage actually, it's the deb version launching through the AppImage)

pizzadude commented 5 years ago

And If I uninstall the deb, the AppImage can't launch at all.

/tmp/.mount_Drill-7zJMWP/usr/bin//drill-search-gtk: line 2: /opt/drill-search-gtk/drill-search-gtk: No such file or directory

Somethings definitely wrong with your AppImage. :P

Maybe it's because you hardcoded your path?

yatima1460 commented 5 years ago

No no, AppImages are basically like .ISO files, they mount themselves and consider the mount location as "/"

This is actually very useful, it seems that for obscure reasons the AppImage on Linux Mint actually "escapes" from the fake filesystem and tries to launch Drill from the real filesystem

pizzadude commented 5 years ago

All my other appimages work fine...

yatima1460 commented 5 years ago

Also it seems the opposite happens with txt files: it tries to launch xed inside the AppImage and not outside

pizzadude commented 5 years ago

Man, developing applications for Linux must be hard. :P

pizzadude commented 5 years ago

Also, I should note that the old AppImage from 25 days ago launched, but the new one doesn't launch at all because it tries to launch Drill from the actual filesystem.

yatima1460 commented 5 years ago

Man, developing applications for Linux must be hard. :P

Want to hear something funny? Linux Mint is the only distro giving me problems, even Arch that by many is considered the most exotic distro after Gentoo works perfectly with the AppImage

yatima1460 commented 5 years ago

All my other appimages work fine...

Can you find another AppImage that let you launch txt files?

Not open .txt files, but actually launch xed like Drill does for txt

But I have the suspicion I'm the first one doing it from an AppImage

pizzadude commented 5 years ago

The SoulSeekQt AppImage allows me to open the containing folder of downloaded media files, and that opens in nemo.

pizzadude commented 5 years ago

Also, it lets me open downloaded .txt files fine. (They open in xed)

yatima1460 commented 5 years ago

You picked up the only project that is not open source so I can't check how they do it :laughing:

pizzadude commented 5 years ago

I don't have any other appimages that I know of that can open txt files. :P

yatima1460 commented 5 years ago

I will try Linux Mint on a virtual machine and let you know

probonopd commented 5 years ago

Looks like the AppImage is seriously broken if it tries to open stuff from /opt:

/opt/drill-search-gt
yatima1460 commented 5 years ago

@probonopd found a part of the problem

Creating the AppImage using pkg2appimage with a local .deb file results in a broken AppImage

Previously creating the AppImage manually worked, so first part of the problem is with pkg2appimage

The second part is still the AppImage exporting the wrong variables and not being able to run xed with xdg-open

yatima1460 commented 5 years ago

you can check the recipe here:

https://github.com/yatima1460/Drill/blob/master/Tools/AppImage/Drill_GTK.yml

yatima1460 commented 5 years ago

@pizzadude can you test the new AppImage?

https://github.com/yatima1460/Drill/releases/download/1.239/Drill-GTK-linux-x86_64-release-1.239.AppImage

pizzadude commented 5 years ago

It launches, and I can search for stuff, but it has the same problem opening text files and folders as before. However, I noticed something. If I have xed already open, and try to open a text file, the text file opens. If xed is not open, it doesn't work and I get the encodings error.

pizzadude commented 5 years ago

If you can't fix this that's okay with me as the deb version works fine.

probonopd commented 5 years ago

the AppImage exporting the wrong variables

Can you explain in one post what "wrong variables" are being exported so that I don't have to read through the whole long thread? Thanks. Likely you need to change the AppRun file or replace it with a custom launcher script.

yatima1460 commented 5 years ago

@probonopd I will try to make a minimal AppImage that causes this bug