- 08 Mar, 2021 1 commit
-
-
Daniel Mustieles García authored
-
- 07 Mar, 2021 4 commits
-
-
Rūdolfs Mazurs authored
-
Sebastian Keller authored
Changing the workspace of a window causes the window tracker to remove and add it to the app again. If this happens from within _shell_app_add_window() before the window has been added to the windows list, this will cause the check that is supposed to prevent adding the same window multiple times to fail and the window to be added twice. The app will then be considered still running after the last window has been closed. Then when clicking on the corresponding app icon, the shell would attempt to switch to a NULL workspace for the closed window instead of starting a new instance, resulting in a crash. Changing the workspace also needs to happen after increasing the interesting window count, because otherwise removal of the window by the window tracker would trigger a uint underflow leading the app to be considered running with UINT_MAX interesting windows, despite having no windows, leading to crashes right after launching the app. Fixes #3833 Part-of: <!1745>
-
Piotr Drąg authored
-
Danial Behzadi authored
-
- 06 Mar, 2021 1 commit
-
-
Philipp Kiemle authored
-
- 04 Mar, 2021 2 commits
- 03 Mar, 2021 19 commits
-
-
Ivan Molodetskikh authored
If the window wasn't in _windowSlots, the index is -1, so the last element of the array is removed, leading to #3547 I logged the stack trace from removeWindow() and it seems that when you move the window from the second monitor to another workspace like shown in #3547, removeWindow() is called twice for it, presumably once for the second monitor workspace, and then once for the first monitor workspace for some reason. It is during that call that _windowSlots doesn't contain the window, so instead the last element (index -1) is removed, leading to the animation bug. Part-of: <!1727>
-
Florian Müllner authored
Previously the information which commit failed a commit message check was hidden in parts of the report that don't show up in gitlab's UI. Part-of: <!1740>
-
Florian Müllner authored
We block state updates while the indicator for the active workspace is animating. To track that, we check whether the scroll-adjustment's value matches the active workspace index. That works as long as the adjustment's value changes after the active workspace, but not when switching workspaces via SwipeTracker which only changes the active workspace after transitioning to the new scroll value. To fix that, update the indicator on workspace changes as well. Part-of: <!1716>
-
Florian Müllner authored
New workspaces are added in two steps, first the minimap expands to make room for the new thumbnail, then the thumbnail animates in. However we currently don't queue a state update after the first step, so the second one only happens after one is queued by some other event (like a workspace switch). #3748 Part-of: <!1716>
-
verdre authored
Animating items of the iconGrid involves calling a few more C functions, which is quite slow. Especially calling ClutterActor.set_easing_delay() is slow because we override that function in JS to adjust for the animation slow-down factor. So add a small class variable to make sure we only animate the icons of the grid when we actually need it. This makes the average time spent in vfunc_allocate() of the iconGrid go down to about 0.7 ms. Part-of: <!1713>
-
verdre authored
It's quite slow to access class variables in JS, especially when they're backed by GObject properties. To avoid accessing them in every iteration when we're looping through the children of iconGrid, store those values to another variable and reuse that inside the loop. This shaves off another 0.2 ms from iconGrids vfunc_allocate(), getting the average time spent in that function down from 1.3 ms to 1.1 ms. Part-of: <!1713>
-
verdre authored
Using a preexisting array to iterate over is much faster than iterating over the actors children using a "for ... of" loop, that's because the latter calls into C functions to get the next actor all the time. Also, stop using array deconstruction here, it turned out that this is extremely expensive. When profiling this part of the code, it turned out that only 9% of the time spent in _getChildrenMaxSize() is spent calling the get_preferred_height/width() methods. When not using array deconstruction, this time increased to 22%, still not great, but a lot better. Part-of: <!1713>
-
verdre authored
We need to access the visible children of a page in inside vfunc_allocate(), and since getting those children is quite slow (it involves iterating over all the children of the actor) let's avoid that and cache the array instead. This reduces average time spent in vfunc_allocate() of the iconGrid from 1.6 ms down to 1.4 ms. Part-of: <!1713>
-
verdre authored
We call this._getChildrenMaxSize() from the allocate() vfunc of IconGridLayout. Since the function is quite expensive, it slows the layout process down a lot, so instead of re-calculating it on every relayout, cache the max size of children. This makes the average time spent in vfunc_allocate() of the iconGrid go down from 2.3 ms to 1.6 ms. Part-of: <!1713>
-
Ivan Molodetskikh authored
Part-of: <!1738>
-
Felix Divo authored
Part-of: <!1246>
-
verdre authored
Instead of always aligning window previews vertically at the bottom of their row, only do that if we have multiple rows. If there's only a single row of windows, align every window vertically centered. This is a very small step towards the new layout for window previews in the overview, but since the release of 40 is getting nearer and nearer, changing more is not feasible anymore. #3634 Part-of: <!1737>
-
verdre authored
To ensure the workspace thumbnails are vertically closer to the window picker than to the search, scale down the wallpapers by a fixed number of pixels. Using 24 px for this means we'll take of 12 px at the top and 12 px at the bottom of the wallpaper, that's a better strategy than always scaling it by a fixed factor since it doesn't change with the monitor size. Part-of: <!1702>
-
verdre authored
The Dash currently has a horizontal margin and a top margin applied. The horizontal margin isn't necessary since there already is a horizontal padding applied, and the top margin is a bit large, since the ControlsLayout enforces a spacing between the different containers already, so slightly decrease the margin-top here. Part-of: <!1702>
-
- 02 Mar, 2021 13 commits
-
-
Georges Basile Stavracas Neto authored
The back → transparent transition gives it a very bad look when booting and running the startup animation. Use the same transition duration hack to ensure that the panel starts completely transparent. Part-of: <!1678>
-
Georges Basile Stavracas Neto authored
There's this little hack that we do to match the panel transition from transparent to black with leaving the overview via swipe down. The only problem is that, while the duration of the panel transition itself is matches, the corners don't, and they get out of sync. This isn't very noticeable with the swipe gesture, but it'll be much more prominent when booting straight into the overview. Bind the 'style' property of the panel to the corners', so that the transition duration hack applies to all of them. Part-of: <!1678>
-
Georges Basile Stavracas Neto authored
The new startup animation consists of rising the Dash from the bottom, falling the search entry from the ceiling, and going from HIDDEN to WINDOW_PICKER with an opacity applied. One little trick from IconGridLayout was added to ControlsManagerLayout, which is a promises-based wait for allocation. This is required to make sure that the transformed position of the search entry is valid, which is only the case right after an allocation. This animation also ensures that the overview is shown right on startup. For session modes that do not have an overview, continue using the same fade + scale animation. Part-of: <!1678>
-
Georges Basile Stavracas Neto authored
It'll be used by the next commit. Part-of: <!1678>
-
Georges Basile Stavracas Neto authored
We want to avoid updating the input region on startup, since it incurs in roundtrips to the X server, but not workspaces struts, since they affect the visible clip of wallpapers in the workspace. Since next commits will make the overview be the after-boot screen, we really don't want the wallpaper to be clipped wrongly. Allow updating regions while starting up, but only workspace struts. Make sure input is not updated by accounting for 'this._startingUp' on 'wantsInputRegion'. Part-of: <!1678>
-
Georges Basile Stavracas Neto authored
This is an X11-specific routine, and building the list of input region rects on Wayland is a waste, since it incurs in many trampolines only to throw them in the trash. Don't build input region rects on Wayland. By modifying the 'wantsInputRegion' variable, it also skips actors that only update input, which is another small optimization for Wayland. Part-of: <!1678>
-
Georges Basile Stavracas Neto authored
LayoutManager doesn't update struts when there's any modal running. Turns out, the Overview itself is a modal. That, and the fact that the Overview will be the startup state, prevents the workarea to be updated. Allow updating struts when there's no other modal than the Overview. Part-of: <!1678>
-
Remi Salmon authored
Be consistent and use the same wifi signal strength thresholds that are used by Settings to ensure that the signal strengths look the same in Settings and gnome-shell. See https://gitlab.gnome.org/GNOME/gnome-control-center/-/blob/master/panels/netwo> for the values used in Control Center. Fixes #217 Part-of: <!1432>
-
Florian Müllner authored
Launching applications on a particular workspace works through launch contexts and startup notifications. While this is no longer required by a launcher/WM split, in theory this allows us to reliably identify the correct window to apply startup properties to. However in practice we fail more often than not: Missing support in toolkits, differences between display protocols, D-Bus activation and single-instance applications all provide their own pitfalls. So instead, take advantage of the fact that launcher and WM live in the same process, and go with the unsophisticated approach: Just remember the last workspace that was requested when launching an app, then move the next window that is associated with the app to that workspace. This will break X11 applications that set an initial workspace, but that's legacy functionality anyway (given that there's no wayland protocol for that functionality), and seems a price worth paying for making launching apps on workspaces more reliable. Part-of: <!1316>
-
Carlos Garnacho authored
When the setting is false, we apply anyway depending on the adjustment value. Look for the right value corresponding to that side as per the locale. Part-of: <!1630>
-
Carlos Garnacho authored
Let the goToPage call afterwards to take precedence, instead of resetting the adjustment (thus the view) on the side. This resulted in strange state when the last page contains a single icon, and it is dragged. The last page being emptied triggers a pages-changed signal, which half resets the view to the first page while DnD is ongoing. Letting goToPage do its business means we neatly clamp to the closest page to currentPage, the last page in that case. Part-of: <!1630>
-
Carlos Garnacho authored
When clicking on the page hints, the hint rectangles being visible in place and not moving together with the page is a bit too distracting. Since the page hints are not part of the iconGrid hierarchy and we have just 2 general ones for prev/next page (i.e. no page associated), do this sliding via some smoke and mirrors: We don't slide the page hints, but a parent container for both of them, and we also control opacity so that the container is fully transparent mid-page. At the point it is transparent, the container can be snapped to the other side of the page, and faded back in as it slides together with it, so it always looks like it goes away and comes from the right sides. Part-of: <!1630>
-
Carlos Garnacho authored
Depending on the available horizontal space, we may want to manipulate the icon grid and scroll view spacing to result in an optimal layout that has space left to preview prev/next pages. The main change here is that, when adapting to the available size, the space given to a page does not necessarily match the available space, as we need to be able to show more than one page at a time. With this decoupling of available and page sizes in place, we now know how much space there is available in order to extend the padding between pages, or the fade effect applied to the previewed pages. Underneath, we rely a bit less on hardcoded CSS paddings, and a bit more on the StScrollView::content-padding property. All put together, gives us proper space management from ultra-wide displays, to display ratios that are close to the optimal grid ratio. Part-of: <!1630>
-