DE integration issues

[Vladimir-csp]

This is a generic issue about using SpaceFM in desktop environments (either full or partial, or frankenstein-style). These are no problems here for advanced users that aware of at least some of DE mechanics. But standard-issue dumb users will have problems and questions.

I see at least three areas of contact with DE's:

• MIME type handling
  • recent changes in SpaceFM mostly took care of that, lets hope that XDG won't do funny stuff again.
• Bookmarks
  • we have GTK bookmark import, which does it's task. But it is too complicated for users. The most obvious question would be "why I add that thingy here (bookmark in GTK dialog), but it does not appear there (in SpaceFM)?" (well, if user is smart enough to grasp bookmarks concept anyway which is pretty rare).
  • Special bookmark submenu that would dynamically represent GTK bookmarks would be a better solution.
  • it is impossible to tell what fate awaits XDG bookmarks spec. Right now it is de-facto ignored, but who knows. Let's ignore it too for now.
• Mounts
  • mounts in $HOME/.cache/spacefm are not seen by GTK nor QT dialogs. Users that want to open a file from mounted FS via some application would not know where to look, especially since .cache is hidden and has lots of subdirs in it.
  • I've tried adding a dirty hack to handlers, calling udevil to mount empty file (and silently fail) to create /media/$USER with user write permissions (setfacl_program = /bin/nonexistent). And then use mountpoints there. It sort of works, although not as flawless as with "%a" mountpoint.

[IgnorantGuru]

.cache would not have been my first choice, but that is the convention, and I didn't see a good reason for breaking it. I think on opening files, it's good enough to be able to open the file from within SpaceFM using the given application. For navigating to it from another app, I would just create a link to ~/.cache/spacefm/ or just ~/.cache/, then add this to Places in the GTK file chooser. I just don't see what action can be taken on this without becoming DE-specific. .cache is the traditional place for this.

I considered a 'GTK Bookmarks' submenu that automatically reflects .gtk-bookmarks when you click it, but I just don't see it being used enough to warrant the work and bloat, and if you're wanting to modify the bookmarks, this is a lot of overhead (code to watch the file, parse it, update it, etc). I think this could be done reasonably as a plugin as well, where the plugin could show the gtk-bookmarks in a popup dialog as a list, allowing you to select from or even edit the list. SpaceFM Dialog makes this very easy to construct - it can populate a list from a text file for example, and update the file. .gtk-bookmarks is a simple text file so there are many automation possibilities. (Someday SpaceFM may have menus that can be created dynamically from a script as well.)

Whether any more development occurs in SpaceFM wrt GTK bookmarks is another question. While I realize there are some people who use GTK bookmarks across Gnome apps, it doesn't have much to do with SpaceFM anymore, and SpaceFM is not a Gnome app. You might as well ask for KDE bookmarks integration, etc. Also, we're not talking about a web browser, so I think most users just bookmark a few system locations. I don't see this area as being worth heavy development time to make it highly integrated with Gnome, etc. But if it's an area of interest for some, I think a lot can be done with a SpaceFM plugin designed for this - just some light scripting.

So overall you've brought up some ootb DE integration issues, but I don't see off-hand how they can be improved reasonably - SpaceFM is DE-independent ootb.

[Vladimir-csp]

I suggest to leave this open in case someone would drop some ideas here.

[IgnorantGuru]

To give a very simple but working example of the plugin idea, try this as a custom command (or you can even paste all lines into your terminal at once):

bookmarks=~/.gtk-bookmarks
eval "`spacefm -g --title "GTK Bookmarks" \
                  --list @$bookmarks \
                  --button cancel --button ok`"
if [ -n "$dialog_list1" ]; then
    # remove any name after space
    path="${dialog_list1%% *}" 
    # remove any "file://" prefix
    path="${path#file://}"
    if [ -d "$path" ]; then
        spacefm "$path"
    fi
fi

That shows how much can be done with a very simple command - obviously that can be embellished in various ways. You could also use text reformatting commands to read .gtk-bookmarks and create a text file containing a multi-column list, as described in --list, add buttons to add/remove bookmarks, etc. That dialog even watches the file so if it changes, the list is automatically updated.

You can add that command in Bookmarks (menu or side pane), which almost gives you the automated 'GTK Bookmarks' menu idea.

[Vladimir-csp]

Thanks, I will look at it.

Regarding mount location, Maybe try to place symlinks to $HOME/media by default, or link $HOME/media > $HOME/.cache/spacefm. The former is preferable, since $HOME/.cache/spacefm could be used for something else along with mounts. Anyway, that would not make mounts visible in file dialogs (even placing links in /media doesn't, I've tried), but at least make them somewhat more visible.

[IgnorantGuru]

So you're suggesting that SpaceFM create a link in $HOME named media, or put links into a dir named media? For that I would ask, what other software uses $HOME/media and for what? Is it covered by any spec? Also, some users definitely won't like it, and will ask for a way to remove it (if it keeps being created). It seems like this is best done by someone setting up the system.

Anyway, that would not make mounts visible in file dialogs (even placing links in /media doesn't, I've tried)

I don't understand why you're saying that. If I have a link named ~/media to ~/.cache/spacefm. I can see it in the file chooser dialog and navigate into it - the link isn't hidden because it doesn't have a dot prefix in its name. So I'm not following you. I'm using GTK2, in case that matters.

[Vladimir-csp]

There is no spec on that, that is why I suggest link, not the dir itself. About dialogs, I've meant special treatment: Here is the result of my custom hacks: sshfs mounted by modified handler to "/media/$USER/$(basename %a)" with "/media/$USER" prepared by udevil.

[arclance]

Also, some users definitely won't like it, and will ask for a way to remove it (if it keeps being created).

Your right I would do that. I don't like things that create things in $HOME without asking first or have no way to configure a different location. $HOME is cluttered enough by things that do that already.

[IgnorantGuru]

About dialogs, I've meant special treatment:

So you're saying you would like to see the mount points listed in Places of the dialog. I've never done it, but there is a way for an application to add Places - not sure what's involved or whether it requires loading bookmarks manually as well, etc. If that worked, it could allow SpaceFM to add known mount points each time a chooser dialog opens. But they still would not appear in other applications' dialogs, so I'm not sure what the use would be.

If you see devices listed in other applications, they are probably just listing their own known mount points, but they probably won't be shown in other applications.

This also gets into DE-specific things, as you're talking about Gnome apps, their browse dialog, and where it knows to find mount points (if it knows at all). I've never seen mention of this in the GTK docs. If there is a spec, it's likely Gnome-specific.

[Vladimir-csp]

But they still would not appear in other applications' dialogs, so I'm not sure what the use would be.

No use in this case.

I've randomly mounted sshfs to various points of filesystem and checked with GTK file dialog: It seems that GTK file dialog checks /media/ (with subdirs), /run/media/$USER/ (possibly with subdirs), and $HOME (with subdirs, I've checked up to third depth) for mountpoints, excluding hidden files.

I've tested with leafpad which does not depend on GNOME.

[IgnorantGuru]

You can see the docs for the GtkFileChooser, which is what GTK apps use (usually via GtkFileChooserDialog). It says there:

Bookmarks - are created by the user, by dragging folders from the right pane to the left pane, or by using the "Add". Bookmarks can be renamed and deleted by the user.

Shortcuts - can be provided by the application or by the underlying filesystem abstraction (e.g. both the gnome-vfs and the Windows filesystems provide "Desktop" shortcuts). Shortcuts cannot be modified by the user.

Volumes - are provided by the underlying filesystem abstraction. They are the "roots" of the filesystem.

So GTK must have some built-in discovery, even when gvfs is not in use.

[Vladimir-csp]

So GTK must have some built-in discovery, even when gvfs is not in use.

It appears so.

[IgnorantGuru]

That would be a reason for moving the mount points dir - would be nice if they would appear in the GTK dialog. But I don't like ~/media or anything non-hidden in the user's home. So I guess that means it's not practical to support due to upstream's rotten discovery (this should really be reported to them - so they look in .cache - but they're so uncooperative I doubt they would ever add it unless Gnome used it).

But it's more of a reason to let the user define a mount points dir. If I added an option to /etc/spacefm.conf, would that be sufficient? it would still have to be writable by the user ofc, not /media, although you could try a /media subdir with appropriate permissions.

None of this will help ootb DE integration though. I suppose SpaceFM could use ~/media by default, and the spacefm.conf option could move it elsewhere. But that seems pushy to put it in the user's home - I assume this is why ~/media hasn't been used.

[Vladimir-csp]

I do not like the idea of creating ~/media or anything similar too. I wish it would be justified by some spec, but AFAIK it is not. SpaceFM option would satisfy those who do not like that. And it would also greatly simplify handler hacks similar to mine.

Filing the bug upstream is a nice idea, regardless of their reaction. Could you point me to the spec covering the use of ~/.cache for mountpoints and stuff?

[IgnorantGuru]

I don't know where that originated offhand. I've just seen it used by LXDE and XFCE apps at least.

I think the GTK chooser should also discover in .config, which would have been another somewhat logical choice.

[IgnorantGuru]

next branch for 1.0.2 is mostly in a freeze now, so the option will have to wait for 1.0.3.

[Vladimir-csp]

Mountpoints in .config?

[Vladimir-csp]

Could you remember what components of LXDE and XFCE used or using $HOME/.cache for mounting? Just in case. I've filed the bug https://bugzilla.gnome.org/show_bug.cgi?id=750182

[IgnorantGuru]

I see they've already rejected it, but you might mention that Thunar, PCManFM, and other widely used GTK file managers mount fuse/network filesystems there, and have for some time. But really you're wasting your time with Matthias Clasen - he'll never help any non-Gnome project using GTK. GTK development is pretty much dead for practical purposes.

[IgnorantGuru]

I added a comment, but there's not much point wasting time with GTK upstream (aka Red Hat, which only supports GTK's use in Gnome these days, if that).

[IgnorantGuru]

Wow you actually got him to almost take an action. :) That was a good idea to ask where user mounts could be placed, because that solution would be backwards compatible (older FMs will find them with the existing chooser). But he didn't answer your question. :/ I guess we'd have to look in the GIO sources (part of glib afaik), since they don't document hardly anything in GTK.

If by some miracle they fix this in glib, that might be better than a GTK3 fix, since I don't think they'll ever update GTK2.

From the GIO docs:

One of the big advantages of putting the VFS in the GLib layer is that GTK+ can directly use it, e.g. in the filechooser.

You can quote that for them if it helps, since they don't seem to know the difference between gio and gvfs (and Clasen certainly should as he's one of the lead Red Hat devs in GTK).

[Vladimir-csp]

New info! http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html $XDG_RUNTIME_DIR seems to be the perfect place, with fall back to $XDG_CACHE_DIR.

[IgnorantGuru]

But is XDG_RUNTIME_DIR typically used? What is the typical location?

I see in some java deployment:

Where $XDG_CONFIG_DIR, $XDG_CACHE_DIR and $XDG_RUNTIME_DIR are set as ~/.config, ~/.cache and /tmp or /var/tmp if not set.

So XDG_RUNTIME_DIR is basically /tmp? Yet is this where we want to mount things? That seems more for pipes and sockets. (Also note that noexec is sometimes enforced in /tmp, which not all users may want for fuse mount points).

I don't see in that spec that it mentions XDG_RUNTIME_DIR falling back to XDG_CACHE_DIR (~/.cache). Rather, it says

If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement directory with similar capabilities.

And what is the difference between XDG_CACHE_HOME and XDG_CACHE_DIR ?

The chooser behavior should not be limited to the Freedesktop specs anyway, as common usage doesn't obey them. I wouldn't encourage them to only support XDG_RUNTIME_DIR, which probably isn't even usually set. A little common sense needs to be brought into it if it's going to be practical.

[IgnorantGuru]

Anyway I would see if you can convince them to search XDG_CACHE_HOME, since that is the old fallback for XDG_RUNTIME_DIR and is still widely used.

[Vladimir-csp]

$XDG_RUNTIME_DIR is usually /run/user/$UID.

XDG_CACHE_DIR is probably a mistype, XDG_CACHE_HOME is in the spec, defaulting to $HOME/.cache

[IgnorantGuru]

There are lots of hits on google for XDG_CACHE_DIR - doesn't seem like merely a mistype.

[Vladimir-csp]

then maybe it is a global mistype: https://bugs.launchpad.net/bzr/+bug/1272042 https://github.com/Shougo/neomru.vim/pull/20

[IgnorantGuru]

I have added the option in next (and key): Devices|Settings|Auto-Mount|Mount Dirs. It's not exactly the most logical place, but it's an advanced setting so I wanted it out of the way, and I think those looking for it can still find it.

It still falls back to .cache, but if you later have a suggestion for a better default, I'll consider it. I don't really have a preference, but it should be something available on much older systems (like Debian Lenny era, where udisks/udisks2 wasn't even yet a nightmare).

[IgnorantGuru]

From the latest on your bug, now you can see how useless it is to try to get those ***\ to do anything. And I've heard the patch stuff before - it's their standard reply when they just want to ignore people, and typically they'll never accept a patch. At least SpaceFM now allows the user to adjust it as they please. If they actually want the GTK chooser to show mounts, they'll have to adjust things, unless we find a default dir that is seen by the chooser and is appropriate. I would just dump them in ~/.gvfs but there is already too much confusion that SpaceFM is somehow gvfs dependent, so I don't wish to encourage that association for any number of reasons.

You can also see from the way he's erroneously speaking about gio being (really moving toward) gvfs-dependent, what their plans are. This is why I don't think glib, gvfs-independent apps like SpaceFM have much of a future in Red Hat's productions. They're just pushing for one single stack. And they're completely useless for any kind of support.

Thanks for reminding me why I despise them. :)

[Vladimir-csp]

Emmanuele Bassi gave a hint at g_unix_mount_guess_should_display(), maybe you could check it out? $XDG_RUNTIME_DIR in debian is maintained by package libpam-systemd, which can work without systemd installed.

[Vladimir-csp]

They defend their bloatware stack, but making rants there is counterproductive. You're putting yourself in vulnerable position. At least, they agreed reviewing the patch for search locations. This could help a lot.

[IgnorantGuru]

It doesn't matter - you notice they closed your report immediately initially, barely reading it. I just gave it a worthless shot. But all of those people and I have a long history. They were featured jackasses in some of my blog articles read by over 100,000 people, and they received a lot of mail and flack for their development practices for months afterward. I probably should have stayed out of the conversation, but when I see them spouting lies I like to call them out. They removed my comment because they don't want people to be informed on the gvfs dependency issue.

They are useless in any event and will not actually accept a patch for this, is my prediction. In any event, it's not my problem. SpaceFM uses the chooser minimally. This is more of an issue in other apps that use it. If they want it to work correctly, they should address it.

As they removed my comment, I'll restate this: The Red Hat devs there are lying to you telling you that GTK+ depends on gvfs. They're also simply changing the subject, since this is a simple case of the chooser not searching in logical locations that have been in use for a long time. Had they any will to fix it, it's easy. These same Red Hat people tried desperately to make gvfs a dependency of GTK+, but they were forced to backtrack on that decision. GTK+ remains gvfs-free and works fine without it. gio is supposed to be independent of DE-specific layers like gvfs by design, but their agenda is to break that. And they probably will - even if you get the change you want, I suspect they have plans for gio, and they already threatened to remove the file chooser in GTK3.

What happened in this bug is someone added a hack to gio to make it look in ~/.gvfs instead of where it would have fallen through to: XDG_CACHE_HOME. So they're hacking gio for gvfs and breaking everything else. This is why the chooser shows only gvfs mounted fuse, and is blind to anything else. This may have been deliberate, or they were just sloppy and only concerned with gvfs.

That whole development team is worthless for support with an app like SpaceFM which doesn't use their complete stack, because of their hostility alone. Just look at how they responded when you said you're not running udisks, which should have nothing to do with this. But they'll never refuse straight out, they'll just waste your time indefinitely. And you notice he has promised nothing. He just said he would accept the patch, but he doesn't have the authority to include it in gio, so you'll get dragged into their chain of command trying to get anything included, and it will likely be rejected with lots of contrived reasons. He also just wants someone else to do the work - they're always like this. They broke it, they should fix it. But they won't, because they like it broken like that.

That said, if you find someone to write the patch you can see how they respond - maybe you'll get lucky. I'll stay out of it.

[IgnorantGuru]

I have published an article on the GTK+ bug report and their conduct, including all the comments they deleted, for public record and for anyone who wishes to review the unvarnished version. Distribute far and wide - let people know what's going on. I think they're misusing their administrative privileges on that tracker, although that's the only way they ever operate.

[Vladimir-csp]

Does "Mount Dirs" option support variables? It falls back to cache if I use variable in the path, but works if I give same path literally.

[IgnorantGuru]

The only variable accepted there is a "~/" expansion prefix for the home dir. It would be unusual to accept XDG vars there but if you think it would be valuable please state your reason and what vars you think it should parse.

[Vladimir-csp]

IMHO, $USER, $UID, $HOME, $XDG_RUNTIME_DIR, $XDG_CACHE_HOME should be treated for this feature to be predictable. With just '~/' I can not properly globally point it to $XDG_RUNTIME_DIR

I would love to be able to assemble a list of fallbacks in this option, not just a single path, something like this:

$XDG_RUNTIME_DIR/spacefm
/run/user/$UID/spacefm
$XDG_CACHE_HOME/spacefm
$HOME/.cache/spacefm

[IgnorantGuru]

I have opened your Jun 7 request as #558.