-
Notifications
You must be signed in to change notification settings - Fork 463
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
Trash and Removable Device Icons #677
Conversation
Nice! I hope that this will be merged soon to fix #173. |
great! thanks! |
Regarding those 3 points you make, I have some questions to the first 2 points.
Is anybody else interested in getting those ideas back to upstream? I'd like to help in that case. |
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)? |
454a1fd
to
12fa1cb
Compare
dash.js
Outdated
this._removables = new Locations.Removables(); | ||
|
||
// Trash Icon | ||
this._trash = new Locations.Trash(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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!
5cdda59
to
26cacaf
Compare
I've updated it to not create the apps if the icons are hidden. |
@didrocks Do you have any interest in putting this functionality into the ubuntu dock? |
@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. |
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 |
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. |
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. |
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). |
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 Excellent! :) |
@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! |
@philipl Can we still keep the xid patch along with this one ? |
@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. |
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. |
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) |
With bad code, I modified the file locations.js to :
to :
|
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. |
In locations.js, I think you can replace Nautilus by gio open (line 176). Replace : |
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)
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 |
What makes you say that? The strings all use |
If this is the |
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). |
@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. |
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). |
I've plans for this and even for devices, but not sure if I'll have time this cycle. |
@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. |
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
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
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
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
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
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.
To summarise the old discussion, this is mostly complete with a few issues that I wouldn't consider blockers: