Port to GNOME 40. #1402

Lots of cleanup still needed - bare minimum functionality achieved.

- Fix preferences dialogs. - Fix some awkward preferences alignments. - Fix a bunch of theming issues with the new background - Dock is no longer attached to a side of the screen (possible setting)

Roughly, if you toggle from the desktop we preserve the "return to desktop" behavior, otherwise it toggles between the views.

(margins are still broken) Also: - Fix separator in vertical and horizontal - Remove dead code

Panel mode should now adhere to the screen sides, though it doesn't have much padding. Drag and drop "works" but I haven't fixed issues with the Trash and Mount icon options.

In 40 this is constrained by the overview so there might still be some odd behavior given we can't constraint by the overview outside the overview.

- Fix background colors (transparency doesn't work with this setting) - Style fixes for panel mode, shrink, and default. - Fix icon alignment in panel mode - Fix show apps taking up too much space.

Also fixes restoring the dash to stock on disable.

40 constrains by height and width, but DtD is intended to constrain by a single dimension.

1. Fix dash._dashContainer alignement. 2. Refactor style using the same padding/margin logic as per the upstream styling as a base.

Move padding from the background to the dash icons container, in order to be able to control the padding in panel mode where the size is fixed instead of being controlled by a constraint. This requires adding a name to the dash._dashContainer element in order to easily style it.

This is so that in 'shrink' mode weird off by one subtle but visible rendering is obtained. Not this seems to be the case upstream. However, with the upstream rendering with larger marging/padding it's typically noticeable.

For now we use the same distance between the dash and the screen edge also between the dash and the windows, but it could be reduced. This only applies to the fixed mode, so similarly to the outer side the gap on the inner side is also kept as a launcher target.

They were not expanding within the assigned dialog.

The checkbuttons were wrongly set all the time active.

It's just not used afterwards, so no need to keep a reference for it

…uments When all the arguments are arrays we just use the same strategy as we did before, otherwise we consider the arguments a single call arguments Also use spread operator to explicitly call the _create function without having to destructure the arguments in every implementation

If an handler has a parent object that supports signals, we can automatically perform the destruction operations (such as disconnecting from signals or remove injected features) without having to handle it manually.

This is the upstream dash customization entry point, so better to avoid calling it multiple times, as it must be only called on setup and when adding/removing it.

We're monkey-patching some properties at time and we need to reset them once done, so let's add a another handler implementation to manage this case.

In case we override a function we may want to be able to call the original function on callback, so handle this by passing the original handler to the callback function.

To compute the workspace box size, we used to add a dummy actor (the DashSpacer) which was bound to the actual dock size so that it could have been used by the controls manager layout to figure out the space used by the dash. While this may still work in horizontal mode, it does not when using a vertical dash. So, let's override workspace box computation code instead, making the dash size to change depending on its disposition.

If we have workspaces enabled, there's no space used in the bottom by the dash, so we can show the thumbnails box all the time so that it is possible to move to other workspaces all the times

In some cases we need to change the behavior of the upstream virtual functions, to do this we can't just monkey-patch the definition but we need to register the new function, so let's handle it. Given that we don't redefine a replacement for the overridden function, it's still possible to call the original implementation calling this.vfunc_overridden_virtual_function in the callback closure function (not an arrow function!) as we'd wo with `super` in the normal code.

…he dock When the dock modifies the workarea the code computing the upstream code that allocates the WorkspaceBackground is wrong, so we need to override it a custom implementation that takes care of the dock position and of its sizes.

And vice-versa

This can be useful for debugging purposes without have to reload the shell all the times when only configuration changes are needed.

We used to get monitors from Gdk but this is not working anymore in Gtk4 so let's just follow the GNOME Shell (and g-c-c) strategy here and use the org.gnome.Mutter.DisplayConfig dbus API. We still use the old numbering strategy though, not to break previous configurations and external configuration tools (as ubuntu's g-c-c).

In case the dock is put on top, we need to consider the panel size (if any), by allocating a bigger dock and disposing it to the bottom of this area. This is because we can't just move the dock lower to the panel as upstream code won't update the workarea instead.

We used to redefine things that are now can be automatized by newer gjs so we can just avoid doing that.

The default startup animation assumes that the dash is positioned in the bottom of the screen, this may not be the case for us, so monkey-patch the default method, overriding the final dash animation (temporary disabling the its easing method) and adapting the translations to our dash positioning. Also, given that we may have multiple dashes, perform the animation in all the docks.

We may create and show our docks too early, causing them to be visible while the shell is still performing the startup animation, causing a flicker. Avoid flickering showing the dash during startup by making all the docks transparent till we're not about to show them.

…n workarea-based The allocation of ControlsManagerLayout and WorkspaceBackground is only partially workarea based, causing this to misbehave when using a fixed dock that is positioned in other parts of the screen causing the workarea to reduce. As per this, a fix has been proposed [1] upstream to make always take care of the workarea to allocate workspace widgets. So reimplement it here, monkey-patching the allocation functions so that we adjust the original ones. This code should be removed or adapted when the merge request will land. [1] https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1892

In case the dock is auto-hiding, it's not reducing the workarea, so we need to manually handle this case by resizing the area to be used. We do this adjusting the actors box so that the horizontal shift is correctly applied.

When using a non-fixed dock we need to reduce the space used by the workspaces in secondary monitors not to show them below the dock itself. This is not a problem when using a fixed dock, as it already takes care of the workArea. The math is close to maybeAdjustBoxToDock() but we've to handle also the horizontal case here, and reduce the size by the half.

Avoid going into C calls when not needed during allocation cycles. So automatically bind all the settings to cached values.

This is used to be handled by the running indicators, but there's no point to do this while we can manage it nicely with implicit properties now. So let's add focused, runnning and windows-count properties to MyAppIcon and connect to these changes in the indicators side, so that we can track it

As per upstream commit f60a469a fade offsets have been replaced by margins, so let's use them instead.

This is probably unneeded now, however still apply it only when showing applications from the desktop.

We need to access it in various places, so cleanup such code by just define it once

To compute the real available space for icons we must take care of the actual dash container padding, or we'd end up considering more space than the one that the theme defines. So use the dash container to compute the allocation box. Also use the proper child to compute the size difference between the icon and its parent button, and eventually include the separator (if set) size to compute the available space. This fixes the dynamic icon sized mode.

As per Gtk4 we need now to make all the parents focusable in order to make possible to edit the GtkEntries.

It may happen that the dock is destroyed (and re-created) quicker than the stage is able to paint the first frame (for example on early hotplug events), in this case we end up initializing the dock (and the related components) with a destroyed dock, causing lots of errors and creating unused actors (such as the app icons). So, use signals handler to manage the initialization so that it gets automatically skipped if the dock is destroyed earlier.

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.

After disabling the intelligent autohide, the barrier is not updated, so the dock is still automatically shown. Now the updateBarrier() method is called when enabling/disabling the intelligent auto-hide. Fixes: micheleg#1421

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Port to GNOME 40. #1402

Port to GNOME 40. #1402

Commits on Oct 3, 2021