-
Notifications
You must be signed in to change notification settings - Fork 25
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
Improve xdg-open behaviour #30
Comments
Ok, now I am really confused. Apparently, having DE=gnome (which is basically the same as settings XDG_CURRENT_DESKTOP=gnome, seems to solve the problems I was having on_certain_sftp_servers. Same with DE=xfce. That is: if I open an sftp link to my university server, then I can open files and get back mc. However,if I open an sftp link to my raspberry pi on my local network, then somehow the file is not copied into /tmp/mc-username. The weird thing is that the file itself is probably transferred from the pi to my machine, because there is network activity, and I have to wait until the appropriate application opens. (And the waiting time seems to be proportional to the filesize.) It just is not written to disk. And then the application is launched and complains about not finding the file that should be there. |
Does setting that variable actually fix the issue that user was having with mc (or possibly xdg-open)? exo-open is already available, (comes with thunar-volman) so we could also try XDG_CURRENT_DESKTOP=XFCE btw the xdg-open code you quoted is probably from a later version than what comes with Debian Jessie, where the DE options are more limited.
|
I tried setting the variable DE=xfce and also tried DE=gnome in the shell before starting jessie. As I wrote, the result is promising. That is: locally it behaves exactly as it should, but using an sftp link it may or may not copy over the file to /tmp/mc-username. More precisely it looks that it always copies the file to RAM, but may or may not put it to /tmp/mc-username. From Thunar I think it works as intended without setting any variables. (I vaguely remember trying this but I am not sure.) Edit: Also tried setting XDG_CURRENT_DESKTOP=GNOME or XFCE, with the same result as setting DE=gnome or xfce. |
Jens and John, what's your recommendation here? |
I'd say try to use exo-open, which we already have on the system. @2ion Jens, what do you think? |
Do not leave the setting unset, set to XFCE, that is a reasonable default. I have no chance to investigate ATM but IIRC exo-open should be what the XFCE setting is triggering. Personally, I'm using KDE here but only because I am already using KDE desktop applications. Using kde-open would launch a KDE daemon, so that'd be a suboptimal solution. |
OK let's put |
...hold this a moment. exo-open still fails the directory-name-with-spaces test (I just checked). On Wheezy gvfs-open failed too, but on Jessie it works OK. (On default BunsenLabs plain xdg-open (with no XDG_CURRENT_DESKTOP set) works too, because open_generic_xdg_mime() checks the bl-file-manager.desktop we installed.) That's a different issue from what brought this question up of course, but since gvfs-open covers both: gvfs-bin is a 444kB install. Should we add that to the default system and set XDG_CURRENT_DESKTOP=GNOME after all? |
More complications - using either GNOME or XFCE will cause some of the .desktop files in /usr/share/applications to hide or show themselves differently. OnlyShowIn and NotShowIn refer to XDG_CURRENT_DESKTOP.
But... this: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1212408 suggests that not having XDG_CURRENT_DESKTOP set might possibly be responsible for the suspend/locking issues some users are getting. |
That's true; as I have said earlier, not having XDG_CURRENT_DESKTOP set causes all kinds of unexpected or broken in software. This also affects proprietary programs which some users might use. While some of the settings are questionable (lxappearance not in GNOME/KDE/XFCE?), XFCE is maybe a good choice because we are using thunar as the file manager already, aren't we? |
Thunar, as well as xfce4-volumed, xfce4-notifyd and xfce4-power-manager. |
Yes, XFCE looks like the better choice on the whole, for compatibility. OK as for the best place to set XDG_CURRENT_DESKTOP, ~/.config/openbox/environment would apply to any session using Openbox, while ~/.xsessionrc would apply for all X sessions. I'm starting to think that in the long term we should have a startbunsen script to hold things we want only for BunsenLabs, leaving LXDE or XFCE sessions clean. It could be triggered from a /usr/share/xsessions/bunsenlabs.desktop which we would set as default in lightdm.conf. But that's for our next release maybe, so for now I'll put |
More reason not to use GNOME:
Like, with GNOME xfce4-power-manager wouldn't be autostarted any more, and a bunch of other stuff would be... Anyway, whichever we use, we'll have to check over all those autostarts and see if anything needs adding to or removing from openbox/autostart. |
Yes, we can change this down the road if need be. |
OK test. The variable is in the environment, but isn't affecting the OnlyShowin XFCE autostart items for some reason. More research needed...
|
Re: above:
So it's not referring to $XDG_CURRENT_DESKTOP but wants the environment passed as an argument. Which means our current openbox/autostart entries won't be affected by setting that variable and can stay as they are. Panic over, I'll just go ahead and set it in openbox/environment in bunsen-configs. |
by setting XDG_CURRENT_DESKTOP=gnome in the environment and making sure that gvfs-open is installed (maybe pulled in by a gtk dependency already?).
The issue came up here: http://crunchbang.org/forums/viewtopic.php?pid=438920#p438920 & http://crunchbang.org/forums/viewtopic.php?pid=438940#p438940. The problem is that xdg-open's generic file opening procedure produces mediocre results at best. Marshalling gvfs-open could be a viable workaround and a nice configuration detail.
The text was updated successfully, but these errors were encountered: