Ewlsh/gnome 40 #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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).
Introduced in 4dcaa49.
Another breaking update upstream that needs some changes for which it might be quite hard to maintain multiple versions (while could be possible for some classes, https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559 will make it even more impossible). So, better to do all at once: * Inheriting from native Actors instead of composition * Cleanup settings object usage, by avoiding passing it eveywhere * Remove Tweener to animate, in favor of new Clutter transitions
This change introduces a basic trash icon that can open and empty the trash. I did not attempt to implement any sort of drag and drop to put something in the trash. The implementation follows the path of least resistence and creates a DesktopAppInfo so that it can be represented by a regular AppIcon. That has particular implications - most significantly being that any actions offered by the icon have to be Execs of external programs, rather than code. In this case, we care about opening the trash and emptying it. We can use the 'gio' utility to open the trash using the default file manager, but emptying it is trickier. You can use gio to empty the trash but there is no confirmation dialog if you do this. Rather than implement such a dialog, I decided to use the Nautilus EmptyTrash dbus call; this triggers confirmation from Nautilus, but is obviously nautilus specific. Finally, I did not attempt to pin the icon to the bottom of the dash as Unity does. Given how elaborate the icon allocation logic is, I couldn't bring myself to tackle it.
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.
Instead of keeping the FileManager1 proxy around all the times, only create it when needed and destroy it on extension destruction.
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.
I missed this originally.
Starting from GNOME/gnome-shell upstream commit ff3d32dd18 AppDisplay is meant to be used only by the AppGrid and in fact it supports DnD drop operations, being a drop target for other icons in order to be able to create an app folder. However dash-to-dock doesn't need anything of that, so in order to have proper dock dnd inherit the app icons from the newly introduced (available since the commit above, included in 3.34.0) Dash.DashIcon LP: #1846477, #1847102
Given the occasion, also move to use GLib functions instead of deprecated Mainloop ones.
Gjs Mainloop is now deprecated in favor of native gjs source functions, so let's use them instead.
The dash slide contianer was de-facto a bin widget already, so no point of reimplementing the same logic in a St.Widget, but instead just inherit from St.Bin
Menu items doesn't have a _onDestroy method by default, so we can't override it by default. So connect to the 'destroy' signal instead.
Hello translation updated
dock._settings is no longer a valid expression. Update to new global settings. Fix regression introduced in 4dcaa49.
Do not make the theme to access the dash private members to update its theming, but use signals instead.
Especially under wayland we should avoid to get the theme from the default gtk one as it may be uset, as it depends on the Gdk Screen that is undefined in such scenario (and we might not be able to either rely on Xwayland). So add an helper class to create a new Gtk theme using the shell's gtk icon theme (that is the system one eventually) and that monitors its changes. As per this, remove direct calls to Gtk.IconTheme and rely on the theme that this helper class has created. At the same time, monitor for theme changes via its native signal, and reset the icons on changes. See: https://gitlab.gnome.org/GNOME/mutter/-/issues/960
This is now removed from ubuntu too in favour of upstream API, so no need to support it here.
org.Nautilus.FileOperations is now deprecated, so let's use the new API. Would be nice to pass some platform data too, but would need a bigger refactor of the code.
Now that the applications expose when they've focus we can easily listen for focus changes and when they are focused scroll to the icon.
Applications can be marked urgent even without Unity API so move this into AppIcon, adding an urgent property, applying the effect when this value changes. Urgency is removed once an application window is focused.
When a an application window is marked as urgent or demands attention we should also mark an application as urgent, so that we can perform the dance animation on it and make it visible in the dash
Make possible for the dash to be shown for a period of time when something needs attention.
We used to do ui-blocking operations to initialize the trash, let's avoid them and use async promises calling async Gio functions instead.
xgettext is still bugged in many distros
Both are generic managers that are not dash-dependent and we need to initialize just one of them in multi-monitor scenario, so move them to the dock manager.
An application is urgent when one of its windows is, however we were resetting this once the application was focused. While this is acceptable for manual urgency (the one set via APIs for example), in the case of urgency triggered by a single window we should keep this state till the window isn't set as non-urgent. So now: - An application keeps stay urgent until any window is requiring attention or marked as urgent. - An application marked as urgent from unity API is urgent until all of its windows have not been focused.
If urgent windows are available activation action should give priority to them so that they can be focused and eventually unmarked as urgent. So make getInterestingWindows() to list such windows as first ones, and adapt activation code to ignore the focused state in case urgent windows are there, prioritizing focusing them.
…ager We're using the dockmanager singleton for all the shared bits, but not for the remote-model that is shared by the various docks, dashes and launcher icons. We can instead just expose it publicly as the DockManager instance and get it once when needed.
We're using the same class for handling both location icons and app icons, while we can manage this in a nicer way using subclassing. As per this we can properly monitor for running and focused state of such apps, fixing the case in which a location is opened but its icon isn't highlighted.
Given that the actual class names will be now auto-generated by the shell there's no risk of clashing with other extensions
…apps We're customizing the dock icons so that we can only consider their location windows, however we can handle this at a lower level by changing the way the shell apps behave, by patching the location apps methods, overriding their defaults. As per this we can reduce the DockLocationAppIcon customizations.
Location applications doesn't support opening new windows, as nautilus will by default try to reuse the mostly recently used window. We may support this in future, once we've added to nautilus a new API for handing such scenario.
Override the app-ID value for location apps by overriding the appInfo relative vfunc for location icons. We also need to delay updating the windows though to avoid recursion
…-manager We have location applications that are currently joined with the file manager but this is not something expected if locations and/or trash are enabled, so start supporting splitting this, integrating the application with the panel too. This can be now easily done by just returning the location application as the focused application when this is the case.
Ensure that the windows tracker will notify the whole shell when the active application has changed, as per this we can just rely on the same logic for both real applications and location applications
By overriding further AppSystem and WindowTracker methods we can fully expose the location applications as standalone applications in both app switchers and window overview selection.
When using the locations isolation mode we should just not consider location windows as part of nautilus, we might have done this at dock icon level, but it's better to just handle this for the whole shell so that nautilus is never considered as running when a location window is there. To do this we need to patch the nautilus shell app as we're doing with the location apps, but now we're using the inject utilities in order to be able to easily revert our monkey-patching once the extension gets disabled.
We used to call this manually but failing to set the proper event timestamp in order to raise the confirmation dialog, that could have not been focused at times. So use the DBus API instead patching the launch_action accordingly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.