Ubuntu dock monitor awareness#2412
Open
bertramdryan wants to merge 747 commits intomicheleg:masterfrom
Open
Conversation
We used to control volumes and volumes differently, while a mount can always refer to its parent volume, so we can just handle both cases using a more abstract class to handle all the mountable volumes so that in case an unmounted volume gets mounted we can avoid creating a new app but just update the state of the old one. This will allow also to control more devices as the ones that are in a not-mounted state
For some implementations we're getting the volume set after the mount so let's ignore the volume in such case. LP: #1960898
Some devices may not be visible in the launcher even if we can technically list them, but it was not possible to mount them before because we were using gio open only and we needed a mount location. This is not the case anymore now, so we can just support showing all the devices, whether they're mounted or not.
It's just faster to wait the last event not being cancelled in an idle instead of doing them after the idle is ready.
If the user already requested to mount or umount a device, there's no point to permit calling this again till the operation is not completed. Notify about
So, for example still present the mount/unmount operations on devices that are being mounted/unmounted but do not leave the user activate them
…-manager When a new filemanager window is opened, we may assign it to nautilus while we're still receiving its location infos, causing it to be temporarily associated to the file manager app, instead to the actual location app. Causing some blinking, so let's use some quick timeout to wait the dbus events to come before proceeding with the assignments.
An application can take some time to start (especially when performing busy operations such as mounting a remote device), so in this case it's better to mark the application as starting and only when we've windows set as running. This can be now easily implemented for the case
Sadly nautilus doesn't provide an API to open new windows when a location is already opened, so using `gio open` can lead to focusing an already opened location. As per this, manually handle opening new windows if the command-line supports --new-window parameter.
No need to use further hacks here, we can just user simpler operations.
In all the cairo drawing operations we assume that the area we're drawing is a square, otherwise the icons will just be drawn outside the visible zone. So let's ensure this at allocation time
The theme colors are now handled by the running them (and so yaru for ubuntu) and not by the settings. Settings can be still used by users to override such parameters.
It seems to have skipped git.
Because `g_file_monitor_set_rate_limit` doesn't work. It's a stub in glib! Fixes: https://launchpad.net/bugs/1962699
To fix the memory issue: https://launchpad.net/bugs/1962699 Whether we release this as-is or it gets merged into a larger update probably doesn't matter. I just want to make sure at least one update with the fix is prepared before jammy release.
We were already filtering them out, but this follows upstream change: https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/c02ca54943
Otherwise the previews menu would never trigger 'menu-opened' for DockDash. We need to emit it before calling this._previewMenu.popup() to prevent that call from triggering a hover-out and the dock immediately auto-hiding.
Losing the hover state is technically correct so it can't be the only
condition we check for. Also wait until the menu is closed before
resync'ing the hover state and auto-hiding.
This became necessary in GNOME 42 with the introduction of new grab APIs.
Perhaps because the old method we used for preventing auto-hide during
menus was removed:
ignoreRelease() {
- return this._grabHelper.ignoreRelease();
}
Fixes micheleg#1714
Fixes micheleg#1755
Fixes https://launchpad.net/bugs/1967121
dash-to-dock v97
dash-to-dock v99
dash-to-dock v100 Git-EVTag-v0-SHA512: 07d2b221a8324af536c96cf616858538a670b59fca8bc789cd6ae9497f8dbddf81e4420dd291ad71954838f3f629d10675ba9aa5f81d3a4f4681862ff0d779b4
dash-to-dock v101 Git-EVTag-v0-SHA512: bb4bf630ad7648b535aca51d8209d06dd350af9cc4b06aa3b7ece2e59fb502dde7ca3c1a0466c7826dbf94ca9542fb891ea60bd457d05a1c9fed8655d50a37a9
It works properly for now, not changing it upstream yet though, as it may still be a temporary case
We depend on some gir packages that we assumed to be there as depending on the shell, but it's better to be explicit here (in fact the dbus menu support was not enabled by default)
Collaborator
|
This branch should be rebased on master and dropped the ubuntu bits (so just cherry-pick your latest commit). That said, I think it may be a bit controversial and it may require an option, in fact I do understand that we want to move a window opened from a specific launcher to the right monitor, but we should not move the windows around once opened IMHO. |
Collaborator
|
Mhmh, it seems like this needs a rebase ;) |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
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.
###Problem
Currently, when an app is launched from the dock, it opens on the primary display, regardless of which monitor the dock interaction occurred on. This behavior can interrupt workflows—such as video calls or media playback—by unexpectedly shifting focus to another display.
Solution
This PR modifies the activate(button) method in appIcon.js to capture the monitor where the click event originated and request the app to launch on that monitor. This aligns window placement with user intent, creating a more intuitive multi-display experience.
Notes
Tested with various dock placements and multiple display configurations.
Behavior now matches user expectations similar to macOS, where new windows respect the context of user interaction.
Special thanks to Grok 4 for assisting with code suggestions.