Trash and Removable Device Icons #677

philipl · 2018-01-19T03:43:48Z

This is a re-submission after the original pull request ( #619 ) was accidentally merged and then unmerged.

This set of changes adds Trash and Removable Device/Drive icons similar to what the Unity dock offers.

Trash icon that reflects whether trash is empty or not, and has an action to empty the trash
Icons for removable devices and mounted volumes with unmount and eject actions (as appropriate)
Preferences to control whether to show icons or not
Window tracking using either the original extended Ubuntu fileManager1 api added for Unity, or the new upstream Nautilus version (which works with Wayland)

To summarise the old discussion, this is mostly complete with a few issues that I wouldn't consider blockers:

No drag and drop for trash. I think the best thing to do here is let the gnome shell folks implement this for their desktop icons extension and then copy/use it. :-)
Trash icon cannot be pinned to the bottom of the bar as in Unity. This could be done by someone with more knowledge than me but I really struggled to understand the St layout code.

AsciiWolf · 2018-02-18T21:26:45Z

Nice! I hope that this will be merged soon to fix #173.

corebots · 2018-02-19T13:08:17Z

great! thanks!

fredldotme · 2018-03-19T01:08:13Z

Regarding those 3 points you make, I have some questions to the first 2 points.
Writing here in the hope of getting the point across to GNOME upstream (especially the designers) sooner rather than too late for GNOME 4.

Might be interesting if some upstream GNOME developers have different plans, especially since extending "Wayland" (the set of protocols) with custom protocols seems to be a thing now.
Keeping trash/device separation intact seems to be a feasable goal AFAICT, though I could see Canonical/Ubuntu ditching their patches sooner rather than later. Which almost screams for a general protocol/API to be in place.

Is anybody else interested in getting those ideas back to upstream? I'd like to help in that case.

fredldotme · 2018-03-19T01:14:35Z

Continuing:

I could see some difficulties (not getting the "full experience" on non-Ubuntu distros) with those options being turned on by default. I don't want to add insult to injury but would it make sense to keep those options turned off by default and be enabled by Ubuntu via gsettings overrides (in case they want to get the feature in quickly)?

franglais125 · 2018-05-13T21:53:49Z

dash.js

+        this._removables = new Locations.Removables();
+
+        // Trash Icon
+        this._trash = new Locations.Trash();


Would it be possible to create the _trash object only if enabled in the settings?

I actually disabled it a long time ago, and only today I realized why my system froze for a few seconds every time I deleted files: the call back to trash changes is still active!

philipl · 2018-05-14T00:13:10Z

I've updated it to not create the apps if the icons are hidden.

philipl · 2018-05-14T00:14:30Z

@didrocks Do you have any interest in putting this functionality into the ubuntu dock?

didrocks · 2018-05-14T06:47:17Z

@philipl: yes, once merged in Dash To Dock properly, I think we'll rebase on it and activate that feature right away. No window matching in Wayland (and I guess no Trash window matching either) would be great to see it fixed though.

philipl · 2018-05-15T02:44:45Z

So, I have an idea now on how to implement window tracking that works with Wayland. There is no equivalent of the XID from X11, as Wayland doesn't allow windows to be enumerated. Fortunately for us, Nautilus is a GtkApplication and uses GtkApplicationWindows. These have unique per-window ids which are published as part of the GtkApplication DBus API. Mutter tracks these ids and you can get them from a Mutter window. So, if the nautilus window reporting uses the 'window object path' that is published over dbus, then we can match the windows up. I'll try and prototype this

philipl · 2018-05-15T04:22:45Z

Good initial results. I need to do Wayland testing, but the fundamental approach works. Obviously it still requires a nautilus patch, but this will be less controversial than the xid based approach.

philipl · 2018-05-16T02:51:27Z

Ok. I've implemented support for this new way of doing window mapping. For now, the patch series includes support for both the Xid and window-object-path mechanisms. There may be some virtue in keeping that as it means compatibility with shipped Ubuntu releases.

I've got an updated version of the nautilus patch here:

https://gitlab.gnome.org/philipl/nautilus/commit/e43d39dbffc93cd18e0064e390105ac90f96be43

@didrocks We should discuss the best way to approach upstreaming this patch, and you can, of course, take it into the Ubuntu build of nautilus.

didrocks · 2018-05-16T07:52:16Z

Sounds excellent! I would prefer that you MR against nautilus and try to get some feedback from Carlos and other upstreams! You can maybe refer this discussions telling it's going to help dash to dock and others extensions matching windows, like ubuntu-dock?

Ofc, need to ensure that it doesn't regress for GNOME Shell dash in particular when you only have a nautilus desktop icon without any Trash (that it still matches nautilus).

philipl · 2018-05-16T19:56:29Z

@didrocks https://gitlab.gnome.org/GNOME/nautilus/merge_requests/223

This is a reworking of a long standing Ubuntu patch that publishes the set of locations open in each Nautilus window. The motivation for this change is that a desktop environment providing special icons for things like removable devices and the trash can match windows to those icons for highlighting purposes. In the original incarnation, Unity provided these icons. In today's world, I'm maintaining a set of patches for dash-to-dock/ubunut-dock that provide these icons too. The original implementation uses Xids to identify windows, but Xids aren't a thing in Wayland so this mechanism is a dead end. Instead, we can use the 'gtk application window object paths' which are published over dbus by GtkApplications, including Nautilus. Mutter already detects these, and makes them available on MetaWindows. The original patch added the mapping property to the fileManager1 interface, and I have left that part as-is, but it's likely not to be the right place to put it. fileManager1 is a generic interface and a property that assumes a GTK behaviour doesn't seem right. We could obviously add it to a new interface under org.gnome.Nautilus, but this would be Nautilus specific - although there isn't a huge scope for other file managers to implement this property, so perhaps that's just fine. dash-to-dock discussion is readable here: micheleg/dash-to-dock#677

philipl · 2018-05-19T21:40:29Z

@didrocks It's now merged into Nautilus. If you want to backport to 3.26, the patch is on my ubuntu-3-26 branch in gitlab.

@micheleg I'd love to get this merged; is there anything you want me to do? any specific comments?

didrocks · 2018-05-22T07:23:25Z

@philipl Excellent! :)

philipl · 2018-11-06T00:55:18Z

@micheleg, do you have any feedback? As I said before, I'd like to get this merged, and if you can give me any guidance on that, I can work on it. Thanks!

khurshid-alam · 2018-11-20T13:52:43Z

@philipl
This actually broke the xid patch for unity.

Can we still keep the xid patch along with this one ?

philipl · 2018-11-20T15:08:03Z

@khurshid-alam, sorry, I don't know what you mean. The xid patch is for nautilus and nothing I do here can break it. Are you saying that window tracking doesn't work for you when using my dash-to-dock patches? I'm still running with the default ubuntu nautilus which only supports xid based tracking (vs the application id based tracking I got merged into upstream nautilus) and window tracking is working correctly for me here.

khurshid-alam · 2018-11-20T19:11:35Z

@philipl

Sorry I didn't explain myself well.

We plan to add that patch back into nautilus 3.30 in disco for unity dock (for unity7 desktop). So I was concerned if it could interfere with application based tracking. But now that I checked again it doesn't. Another option is to use id based tracking in unity dock as well so that we don't need yet another dbus property. I well let Trevinho (it's his patch) to look into this.

Thanks.

3v1n0 · 2018-11-20T21:25:22Z

From a quick look at the code, it seems you've to give one method some priority... So try to use the XIDs mode only if the gtk one isn't available.

As nautilus in ubuntu 19.10 will probably provide both (or might be, while probably we'd try to avoid it)

mohegan · 2019-10-04T13:22:47Z

With bad code, I modified the file locations.js to :

    _onVolumeAdded(monitor, volume) {
        if (!volume.can_mount()) {
            return;
        }

        let activationRoot = volume.get_activation_root();
        if (!activationRoot) {
            // Can't offer to mount a device if we don't know
            // where to mount it.
            // These devices are usually ejectable so you
            // don't normally unmount them anyway.
            return;
        }
        let uri = GLib.uri_unescape_string(activationRoot.get_uri(), null);

        let volumeKeys = new GLib.KeyFile();
        volumeKeys.set_string('Desktop Entry', 'Name', volume.get_name());
        volumeKeys.set_string('Desktop Entry', 'Icon', this._getWorkingIconName(volume.get_icon()));
        volumeKeys.set_string('Desktop Entry', 'Type', 'Application');
        volumeKeys.set_string('Desktop Entry', 'Exec', 'nautilus "' + uri + '"');
        volumeKeys.set_string('Desktop Entry', 'StartupNotify', 'false');
        volumeKeys.set_string('Desktop Entry', 'Actions', 'mount;');
        volumeKeys.set_string('Desktop Action mount', 'Name', __('Mount'));
        volumeKeys.set_string('Desktop Action mount', 'Exec', 'gio mount "' + uri + '"');
        let volumeAppInfo = Gio.DesktopAppInfo.new_from_keyfile(volumeKeys);
        let volumeApp = new Shell.App({appInfo: volumeAppInfo});
        this._volumeApps.push(volumeApp);
        this.emit('changed');
    }

to :

    _onVolumeAdded(monitor, volume) {
        if (!volume.can_mount() || volume.get_name().search("gmail") > 0) {
            return;
        }

        let activationRoot = volume.get_activation_root();
        if (!activationRoot) {
            // Can't offer to mount a device if we don't know
            // where to mount it.
            // These devices are usually ejectable so you
            // don't normally unmount them anyway.
            return;
        }
        let uri = GLib.uri_unescape_string(activationRoot.get_uri(), null);

        let volumeKeys = new GLib.KeyFile();
        volumeKeys.set_string('Desktop Entry', 'Name', volume.get_name());
        volumeKeys.set_string('Desktop Entry', 'Icon', this._getWorkingIconName(volume.get_icon()));
        volumeKeys.set_string('Desktop Entry', 'Type', 'Application');
        volumeKeys.set_string('Desktop Entry', 'Exec', 'nautilus "' + uri + '"');
        volumeKeys.set_string('Desktop Entry', 'StartupNotify', 'false');
        volumeKeys.set_string('Desktop Entry', 'Actions', 'mount;');
        volumeKeys.set_string('Desktop Action mount', 'Name', __('Mount'));
        volumeKeys.set_string('Desktop Action mount', 'Exec', 'gio mount "' + uri + '"');
        let volumeAppInfo = Gio.DesktopAppInfo.new_from_keyfile(volumeKeys);
        let volumeApp = new Shell.App({appInfo: volumeAppInfo});
        this._volumeApps.push(volumeApp);
        this.emit('changed');
    }

philipl · 2019-10-04T15:17:19Z

So, what we should be doing is excluding mounts that are identified as 'remote' - ie: accessed over the network. This is a gvfs filesystem attribute that should be set. There is no gmail backend in gvfs itself so I don't know where it's coming from, but it should be setting this attribute. If it does, it should already be excluded.

mohegan · 2019-10-05T14:07:38Z

In locations.js, I think you can replace Nautilus by gio open (line 176). Replace :
volumeKeys.set_string('Desktop Entry', 'Exec', 'nautilus "' + uri + '"');
by :
volumeKeys.set_string('Desktop Entry', 'Exec', 'gio open "' + uri + '"');

Another Unity dock capability is showing icons for removable drives and devices. This change introduces such icons for these entities. As with the Trash, we back these with DesktopAppInfo, and implement the open/unmount/eject actions with the 'gio' utility. In Unity, icons are shown for both mounted and unmounted entities, and this behaviour is retained. Also retained is the practice of not exposing an unmount operation for ejectable entities. We also cannot show an unmounted icon if the entity has no activation root, but I believe that most entities of this type are ejectable so it's not a real problem. This limitation arises because the activation root is how we know where to mount the entity. Unlike the trash, the natural icon placement matches the behaviour in Unity.

Make showing of these items optional.

In Unity, special logic is present that will map a Nautilus window the removable device or trash icon in the dock. The key to making this possible is a special dbus property that was patched into Nautilus that allows us to find the window where a location is open. Once we have access to this Nautilus information, we can then jump through a bunch of hoops to map the locations to MetaWindows and then a little special-casing logic, link our dock icons to those windows. Now, the special icons will have a running process highlight and window counts, and all the usual features of a running app. We support both the Ubuntu-specific patched Xid based window matching as well as the upstream GtkApplication based matching that I added to Nautilus. In a difference from Unity, I made no attempt to subtract the special location windows from the Nautilus app; that would be a bunch of work and the benefit is unclear. When run with a Nautilus that supports neither method, we will simply never see any linked windows, and the behaviour will be the same as without this change.

I was already deduplicating if a window had the identical location open in tabs but if the locations were different but still under the same removable device, we'd get two separate entries created for that same window. This is now fixed.

(cherry picked from commit 7b58ceb)

(cherry picked from commit 921b68d)

Instead of keeping the FileManager1 proxy around all the times, only create it when needed and destroy it on extension destruction. (cherry picked from commit 6bddbc3)

Add SignalsHandlerFlags which allows to connect to a signal using flags, the only defined for now is CONNECT_AFTER, that allows to use `connect_after()` method when the parent object supports it (so when it is inheriting from GObject). (cherry picked from commit 3ff622d)

Changing show-trash/show-mounts causes the file-manager proxy object to be destroyed, in order to make sure this happens before that the icons might consume this, connect to show-mounts and show-trash changes after. (cherry picked from commit cbb7ce7)

philipl · 2019-10-05T16:49:16Z

I'm going to leave this based on the 3.32 branch until I have upgraded to 19.10 and can use 3.34. Otherwise I can't actually test it.

I've fixed the nautilus vs gio open. Not sure how I missed that.

philipl · 2019-10-05T16:54:03Z

Can you add the possibility to translate the trash icon name and volume actions (Trash and Unmount for examples) ?

For now, it isn't easily translatable (in the locations.js file, I think).

What makes you say that? The strings all use __("value") which makes them translatable, does it not? This is used elsewhere in dash to dock.

philipl · 2019-10-05T17:00:13Z

So, what we should be doing is excluding mounts that are identified as 'remote' - ie: accessed over the network. This is a gvfs filesystem attribute that should be set. There is no gmail backend in gvfs itself so I don't know where it's coming from, but it should be setting this attribute. If it does, it should already be excluded.

If this is the goa backend in gvfs, that sets its class identifier to network, which is the check that I do to filter out volumes. So not sure why that doesn't work for you.

micheleg · 2019-10-06T17:34:36Z

I've merged into master what was currently in the ubuntu-dock branch [8092813], as I want to make a release for 3.34.

I see further discusson here and I see also that @philipl you are working on a 3.32 based branch. I'm not sure how you want to evolve this PR now. I do not want to add features for older releases as I would not be able to support them (I might make exceptions for versions currently in ubuntu LTSs and Debian stable).

philipl · 2019-10-06T18:12:42Z

@micheleg Thanks for merging! I'm shortly going to upgrade myself so I'm on 3.34, but in practice, there's only been a single line change on top of what you merged and I can open a separate PR for that.

You can merge this PR to the 3.32 branch if you think the you want the feature there, but otherwise we can close it.

proninyaroslav · 2019-10-30T15:32:28Z

I don’t know how real this is, but I would be glad to see the possibility of Drag'n'Drop files in the trash (e.g from Nautilus).

3v1n0 · 2019-10-31T00:32:11Z

I've plans for this and even for devices, but not sure if I'll have time this cycle.

philipl · 2019-11-11T20:23:58Z

@3v1n0 Can you close this PR in a way that indicates it was merged in the end? Due to how the merging was done, github isn't smart enough to notice.

3v1n0 · 2019-11-12T16:09:28Z

Looks like I can't do that as per isaacs/github#2 but well, we can close this.

Merged as 8092813

This is a reworking of a long standing Ubuntu patch that publishes the set of locations open in each Nautilus window. The motivation for this change is that a desktop environment providing special icons for things like removable devices and the trash can match windows to those icons for highlighting purposes. In the original incarnation, Unity provided these icons. In today's world, I'm maintaining a set of patches for dash-to-dock/ubunut-dock that provide these icons too. The original implementation uses Xids to identify windows, but Xids aren't a thing in Wayland so this mechanism is a dead end. Instead, we can use the 'gtk application window object paths' which are published over dbus by GtkApplications, including Nautilus. Mutter already detects these, and makes them available on MetaWindows. The original patch added the mapping property to the fileManager1 interface, and I have left that part as-is, but it's likely not to be the right place to put it. fileManager1 is a generic interface and a property that assumes a GTK behaviour doesn't seem right. We could obviously add it to a new interface under org.gnome.Nautilus, but this would be Nautilus specific - although there isn't a huge scope for other file managers to implement this property, so perhaps that's just fine. dash-to-dock discussion is readable here: micheleg/dash-to-dock#677

philipl force-pushed the master branch from cc8232a to 827a336 Compare March 21, 2018 23:28

philipl force-pushed the master branch from 827a336 to 5cdda59 Compare April 10, 2018 14:08

philipl force-pushed the master branch 2 times, most recently from 454a1fd to 12fa1cb Compare April 26, 2018 15:06

franglais125 reviewed May 13, 2018

View reviewed changes

philipl force-pushed the master branch 2 times, most recently from 5cdda59 to 26cacaf Compare May 14, 2018 00:11

philipl force-pushed the master branch from fa6e937 to 1f0f425 Compare May 16, 2018 19:57

philipl force-pushed the master branch from 1f0f425 to 79c237f Compare May 19, 2018 21:21

philipl force-pushed the master branch from 79c237f to 92bae18 Compare August 29, 2018 18:06

philipl and others added 9 commits October 5, 2019 09:47

prefs: Add prefs to toggle showing Trash and Mounted Volumes

d1e63c9

Make showing of these items optional.

locations: Ensure volume monitor is destroyed on destruction

f762484

(cherry picked from commit 7b58ceb)

dash: Destroy Removables and Trash if disabled

01746fb

(cherry picked from commit 921b68d)

DockManager: Keep a fm1Client reference and destroy it when unneeded

605f0e1

Instead of keeping the FileManager1 proxy around all the times, only create it when needed and destroy it on extension destruction. (cherry picked from commit 6bddbc3)

philipl changed the base branch from master to gnome-3.32 October 5, 2019 16:47

philipl force-pushed the master branch from 0839114 to 053e1c5 Compare October 5, 2019 16:48

philipl mentioned this pull request Oct 6, 2019

locations: Fix a remaining use of nautilus vs gio open #1004

Merged

3v1n0 closed this Nov 12, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Trash and Removable Device Icons #677

Trash and Removable Device Icons #677

philipl commented Jan 19, 2018 •

edited

Loading

AsciiWolf commented Feb 18, 2018

corebots commented Feb 19, 2018

fredldotme commented Mar 19, 2018 •

edited

Loading

fredldotme commented Mar 19, 2018

franglais125 May 13, 2018

philipl commented May 14, 2018

philipl commented May 14, 2018

didrocks commented May 14, 2018

philipl commented May 15, 2018

philipl commented May 15, 2018

philipl commented May 16, 2018

didrocks commented May 16, 2018

philipl commented May 16, 2018

philipl commented May 19, 2018

didrocks commented May 22, 2018

philipl commented Nov 6, 2018

khurshid-alam commented Nov 20, 2018

philipl commented Nov 20, 2018 •

edited

Loading

khurshid-alam commented Nov 20, 2018 •

edited

Loading

3v1n0 commented Nov 20, 2018

mohegan commented Oct 4, 2019

philipl commented Oct 4, 2019

mohegan commented Oct 5, 2019

philipl commented Oct 5, 2019

philipl commented Oct 5, 2019

philipl commented Oct 5, 2019

micheleg commented Oct 6, 2019

philipl commented Oct 6, 2019

proninyaroslav commented Oct 30, 2019 •

edited

Loading

3v1n0 commented Oct 31, 2019

philipl commented Nov 11, 2019

3v1n0 commented Nov 12, 2019

Trash and Removable Device Icons #677

Trash and Removable Device Icons #677

Conversation

philipl commented Jan 19, 2018 • edited Loading

AsciiWolf commented Feb 18, 2018

corebots commented Feb 19, 2018

fredldotme commented Mar 19, 2018 • edited Loading

fredldotme commented Mar 19, 2018

franglais125 May 13, 2018

Choose a reason for hiding this comment

philipl commented May 14, 2018

philipl commented May 14, 2018

didrocks commented May 14, 2018

philipl commented May 15, 2018

philipl commented May 15, 2018

philipl commented May 16, 2018

didrocks commented May 16, 2018

philipl commented May 16, 2018

philipl commented May 19, 2018

didrocks commented May 22, 2018

philipl commented Nov 6, 2018

khurshid-alam commented Nov 20, 2018

philipl commented Nov 20, 2018 • edited Loading

khurshid-alam commented Nov 20, 2018 • edited Loading

3v1n0 commented Nov 20, 2018

mohegan commented Oct 4, 2019

philipl commented Oct 4, 2019

mohegan commented Oct 5, 2019

philipl commented Oct 5, 2019

philipl commented Oct 5, 2019

philipl commented Oct 5, 2019

micheleg commented Oct 6, 2019

philipl commented Oct 6, 2019

proninyaroslav commented Oct 30, 2019 • edited Loading

3v1n0 commented Oct 31, 2019

philipl commented Nov 11, 2019

3v1n0 commented Nov 12, 2019

philipl commented Jan 19, 2018 •

edited

Loading

fredldotme commented Mar 19, 2018 •

edited

Loading

philipl commented Nov 20, 2018 •

edited

Loading

khurshid-alam commented Nov 20, 2018 •

edited

Loading

proninyaroslav commented Oct 30, 2019 •

edited

Loading