image viewer not forking in trinity

[mike]

This is probably a bug in trinity.
When you launch the image viewer, it doesn't fork, and variety get's stuck until the viewer is closed.

To avoid bugs of this type, in all the gabillion DEs, variety should make sure the viewer has forked.

[James Lu (jlu5)]

Hi,

IIRC xdg-open should always fork and return to the command line after starting the relevant application. What happens when you run 'xdg-open <any image file on your system>' from a command line?

[mike (mike5346874)]

It's indeed a bug in xdg-open

I have trinity installed on linux mint MATE.
When i try xdg-open in my normal account that i have alredy configured, it works properly. In a new account, it doesn't fork and also it opens the image with the MATE viewer.

I also read that xdg-open tends to be buggy in the less popular desktops.

I think the most sensible approach to this, would be to have a configuration option in a config file (not the UI), so that the user can use a custom command, with xdg-open as the default. And also add this info in the tips and tricks.

[James Lu (jlu5)]

The purpose of xdg-open *is* to allow custom programs to be run, based on your configured file associations. You should report this bug to TDE.

[mike (mike5346874)]

errors always happen and you handle them....

this ticket is about not forking.
variety simply assumes that it will never ever fail to fork. When it does fail to fork variety gets stuck.

in bash a simple "&" at the end of the command would have avoided the stuckage, i'm assuming it's similarly simple in python. If you are masochistic, you can even use a try :/ .

if variety called a simple wrapper script located in the config folder, that would easily allow users to edit it if they have too. I don't see why you would refuse that.

in practice xdg-open supports KDE gnome and other.

[Peter Levi (peterlevi)]

This may need further investigation, at least to confirm what the spec for xdg-open is, and if it is always supposed to fork or not.

We use subprocess.call to open child processes, which waits for them to complete to check and return their returncode. This means that if the subprocess crashes, we'll get an exception trace in the log (I need to check this), which would give the user some info about what the problem is. If we just fork and forget, we won't hang should the process hang, but we also won't know whether it succeeded or not. So if xdg-open is supposed to fork and never hang itself, I'd rather not fork it, but wait for it to return an error code and log an exception, should the call fail.

Regarding the other related bug: Adding a dedicated configuration to duplicate what xdg-open is supposed to allow customizing (i.e. your preferred image viewer) seems wrong. If it misbehaves, it should be reported as a bug to wherever is most appropriate, not be worked-around by custom "file association" solutions in client applications.

[mike (mike5346874)]

I don't see any mention of forking in the manual. I'm not sure if that qualifies as "specs"
https://portland.freedesktop.org/doc/xdg-open.html

The generic method of the script has
"$command_exec" "$@"
If the application doesn't fork, it will not.
So variety will always hang here.

The script acts mostly as a front end for desktop specific methods, like kde-open and mate-open. They are the ones that do the forking.

The supported environments are:
Cinnamon
Enlightment
KDE
gnome
LXDE
MATE
XFCE
cygwin
darwin
GENERIC

And i thought of a simple solution.
Just add my own xdg-open in the $PATH to mask the system wide one. That tip should be added in the tips and tricks section.

something like this for example.

#!/bin/bash

if [ "$XDG_CURRENT_DESKTOP" = Trinity ];
then

kfmclient exec "$@" 2> /dev/null

#elif [ "$XDG_CURRENT_DESKTOP" = Desktop_Name ];
#then
#your command

else
/usr/bin/xdg-open "$@"

fi

[James Lu (jlu5)]

Hi,

Have you considered sending this as a patch to xdg-utils upstream?
There's already an open bug for TDE support at
https://bugs.freedesktop.org/show_bug.cgi?id=102395

I still believe that it's out of Variety's scope to encourage replacing
system components, as any little screw up can cause unrelated programs
to fail completely.

On 24/08/17 10:23 AM, mike wrote:
> I don't see any mention of forking in the manual. I'm not sure if that qualifies as "specs"
> https://portland.freedesktop.org/doc/xdg-open.html
>
> The generic method of the script has
> "$command_exec" "$@"
> If the application doesn't fork, it will not.
> So variety will always hang here.
>
> The script acts mostly as a front end for desktop specific methods, like
> kde-open and mate-open. They are the ones that do the forking.
>
> The supported environments are:
> Cinnamon
> Enlightment
> KDE
> gnome
> LXDE
> MATE
> XFCE
> cygwin
> darwin
> GENERIC
>
> And i thought of a simple solution.
> Just add my own xdg-open in the $PATH to mask the system wide one. That tip should be added in the tips and tricks section.
>
> something like this for example.
>
> #!/bin/bash
>
> if [ "$XDG_CURRENT_DESKTOP" = Trinity ];
> then
>
> kfmclient exec "$@" 2> /dev/null
>
> #elif [ "$XDG_CURRENT_DESKTOP" = Desktop_Name ];
> #then
> #your command
>
> else
> /usr/bin/xdg-open "$@"
>
> fi
>

[mike (mike5346874)]

lol, i reported that, see the date....

their generic method already sucks!!!!
People with "unpopular" desktops are usually more savy. It would be much beater to read the solution in the tips, then go dig for the solution like i did.

[James Lu (jlu5)]

Actually, it looks like this bug may affect LXQt too.

AFAIK an easy fix for this would be to simply replace subprocess.call calls on xdg-open with subprocess.Popen.

[James Lu (jlu5)]

This should be fixed in the next release, see commit https://github.com/varietywalls/variety/commit/0c7a65071db3599a650b1f36a68c61fef37e7717