Fixed space size issue when move the application button at the beginning of the dock #4
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
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.
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.
Ewlsh/gnome 40
21 tasks
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.
Before:
After: