Bug 9822

Why not, instead of looking for $GNOME_DESKTOP_SESSION_ID, directly test for the existence of gnome-open?

I tested and gnome-open myfile.dvi works correctly even over ssh.

> Why not, instead of looking for $GNOME_DESKTOP_SESSION_ID, directly test for
the existence of gnome-open?

Because xdg-open then wouldn't work correctly when both KDE and GNOME are installed and you use KDE.

You are describing an interesting edge case, though - where one doesn't use a particular DE but wants to force xdg-open to pretend that this DE is used (it should have worked using X directly, i.e. XDMCP).

> Because xdg-open then wouldn't work correctly when both KDE and GNOME are
> installed and you use KDE.

Ah, drats.

> You are describing an interesting edge case, though - where one doesn't use a
> particular DE but wants to force xdg-open to pretend that this DE is used 

Not really. I don't want to "pretend" anything -- just want to use some 
mime mechanism that works, like gnome-open if available.

> (it should have worked using X directly, i.e. XDMCP).

You mean with Xnest? Complicated.

What about testing _inside_ open_generic() for the presence of gnome-open? 
(and after that for kfmclient?) Would be an improvement wrt the 
current situation. 

Is there any mime opener not dependent upon a DE?  mailcap-based? 

> What about testing _inside_ open_generic() for the presence of gnome-open? 
> (and after that for kfmclient?) Would be an improvement wrt the 
> current situation. 

Using a DE-specific preferences when the DE is not used may be considered a bug. We use mailcap in that case for local files, and I don't know why it doesn't work for you.

Maybe you should update /etc/mailcap on the host machine and include a line like

application/x-dvi; evince '%s'; test=test -n "$DISPLAY" ; nametemplate=%s.dvi

This is what Ubuntu uses, at least.

> Maybe you should update /etc/mailcap on the host machine and include a line
> like
>
> application/x-dvi; evince '%s'; test=test -n "$DISPLAY" ; nametemplate=%s.dvi

Tried that; doesn't make any difference.

(Before you ask: my /etc/mime.types contains a line
application/x-dvi               dvi 
)

Where does xdg-open call the mailcap mechanism? I don't see it. Perhaps it 
should.

I have fc4, but debian (and ubuntu?) has a program (perl script) 
called run-mailcap.

> Where does xdg-open call the mailcap mechanism? I don't see it. Perhaps it 
> should.

To answer my own question, it uses mimeopen, another perl script. Which I don't have installed, and which apparently is not a dependency for the xdg-utils rpm (Fedora Extras packaging bug?) The package name is perl-File-MimeInfo and it is first available for fc5. I have fc4.

Still, I would suggest to (inside open_generic()) look in sequence for mimeopen, run-mailcap, gnome-open, kfmclient and exo-open... surely one of those will bite. Note that this problem only comes up when logging in outside a DE session, which may be intentional (unlikely if xdg-utils is installed) or accidental (ssh basic X-forwarding login). The first case implies a knowledgable user. The second case -- the only way a dummy would run X remotely -- should be handled robustly and with grace.

Does GNOME set a property (X11 property) on the root window which could be used to identify it?

In this case we could probaly extend the detectDE() check to first check for the environment variable and, if this fails, for the property.

This would allow to "force" a certain behavior by setting the environment variable, e.g. your local machine is running KDE but you want your remote machine to use the GNOME lookup.

> Does GNOME set a property (X11 property) on the root window which could be used to identify it?

Hmmm. Do you mean to test for the property on the local machine (running the X server) from the remote, so as to use the same DE as locally? 

Yes. The check for XFCE is already based on such a property and I think D-Bus uses a similar fallback when the envirnoment variable for the session bus address is missing.

Ah. How does it work? One idea that came to me was to look at _NET_CLIENT_LIST for DE-specific entries. Laborious. And how do you do this from the shell?

If this can be made to work it is the Obviously Correct(TM) solution...

detectDE() is one of the functions shared by all xdg-utils scripts, look for it in
http://webcvs.freedesktop.org/portland/portland/xdg-utils/scripts/xdg-utils-common.in?revision=HEAD&view=markup

I think KDE sets a root window property as well (in recent versions), so I thought GNOME might as well do something in this direction.

Well, it sets

NAUTILUS_DESKTOP_WINDOW_ID

and I think all non-ancient GNOMES do that. Is this useable? What does KDE set?

Well, hmm, this depends on Nautlius handling the desktop, right?

But if this is the most common situation on GNOME desktops, it could be acceptable (but I think someone from GNOME should decide this)

As for KDE, I think it basically sets the same thing (i.e. KDE_FULL_SESSION=true) in both environment and root window property.

In any case, the remaining problem is to check if this additional "desktop detection" will likely work.
The remote machine might not have the tools installed the respective script code path would then execute.

A possible solution, but quite hacky, would be to set the environment variable and then call the script again from within itself.
If this second invocation returns the error code for "delegate not found", one could still proceed with the original decision (no DE detected)

GNOME sets the environment variable

GNOME_DESKTOP_SESSION_ID=Default

It would be good if it set this also as an X property -- which cannot be
very hard to implement.

If you start an X application in a remote machine, you want it to conform to
the desktop standard on your _local_ machine, where the window will appear. If
at all possible. This is something every DE should try to do, and apparently
the way to do it is by using an X property. 

Don't you think that is a reasonable demand and should be part of a free
desktop standard?

- Martin

Here's a quick workaround for your SSH needs:

* For your server, add a

AcceptEnv DESKTOP_SESSION

directive to sshd_config (usually /etc/ssh/sshd_config)

* For your client, add a

Host *
    SendEnv DESKTOP_SESSION

directive to ssh_config (/etc/ssh/ssh_config or ~/.ssh/config)

Now the DESKTOP_SESSION should be propagated to the host machine after you restarted the host sshd.

On Windows or Mac there are no environment variables to propagate; running applications on new clients and old servers (run a program on home machine using X server on an ancient university system) is not something exotic either. So while it's good to get environment from the server machine, it is not enough at all. Bunch of fallbacks as proposed in comment #6 would be good.

Debian's xdg-open tries run-mailcap by the way.

Generic mode should take care of this nowadays. Please reopen otherwise.