1. 08 Mar, 2021 1 commit
  2. 07 Mar, 2021 4 commits
    • Rūdolfs Mazurs's avatar
      Update Latvian translation · 1066a1bd
      Rūdolfs Mazurs authored
    • Sebastian Keller's avatar
      shell/app: Avoid adding windows with a startup workspace twice · f9f936e7
      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's avatar
      Update Polish translation · d4ae968d
      Piotr Drąg authored
    • Danial Behzadi's avatar
      Update Persian translation · aefafc5f
      Danial Behzadi authored
  3. 06 Mar, 2021 1 commit
  4. 04 Mar, 2021 2 commits
  5. 03 Mar, 2021 19 commits
    • Ivan Molodetskikh's avatar
      workspace: Check if index is valid before using it · 35fb221a
      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
      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's avatar
      ci: Update ci-fairy image · ff163a03
      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's avatar
      workspaceThumbnails: Update indicator on workspace changes · 30f0c9f9
      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's avatar
      workspaceThumbnail: Queue state update after expanding · fac50fb5
      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
      Part-of: <!1716>
    • verdre's avatar
      iconGrid: Only animate items when we actually need it · 7f996550
      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's avatar
      iconGrid: Save class variables to local ones · 7771bf44
      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's avatar
      iconGrid: Bail out of getRowPadding early if we'll return 0 · 7a5650d8
      verdre authored
      This gets our time spent in vfunc_allocate() down again by ~0.1 ms from
      1.4 ms to 1.3 ms.
      Part-of: <!1713>
    • verdre's avatar
      iconGrid: Don't update pages in vfunc_allocate() · 0fd394d4
      verdre authored
      vfunc_allocate() is a hot path, and we don't want to do expensive stuff
      there, so avoid updating the pages, which seems unnecessary anyway.
      Part-of: <!1713>
    • verdre's avatar
      iconGrid: Get max child size using existing array of visible children · 0978b87e
      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
      Part-of: <!1713>
    • verdre's avatar
      iconGrid: Cache visible children of pages · 8e938064
      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's avatar
      iconGrid: Cache max size of children · b3c46a33
      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's avatar
      workspace: Fix switched arguments · 0a144ee5
      Ivan Molodetskikh authored
      Part-of: <!1738>
    • Felix Divo's avatar
    • verdre's avatar
      workspace: Center-align window previews if there's only a single row · 31d7770e
      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.
      Part-of: <!1737>
    • verdre's avatar
      workspace: Decrease spacing between workspaces in the window picker · 9b9be4a1
      verdre authored
      Use a bit less spacing between the workspaces in the window picker, this
      uses more of the available space and makes it easy to take a peek at
      adjacent workspaces.
      Part-of: <!1702>
    • verdre's avatar
      workspace: Scale down wallpaper by a fixed number of pixels · 99378b6d
      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's avatar
      theme/search-entry: Tweak the margins a bit · df9129b2
      verdre authored
      Use a bit less margin at the top and add some margin at the bottom of
      the search entry. This should ensure the search entry is closer to the
      panel than to the workspaces and avoid associating the workspace
      thumbnails with the search instead of the window picker.
      Part-of: <!1702>
    • verdre's avatar
      theme/dash: Tweak margins of the dash · a27009f9
      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>
    • verdre's avatar
      theme/overview: Use a spacing of 16px between elements · 613efa72
      verdre authored
      In the overview we want to make sure window previews are shown as large
      as possible, so make the spacings a bit less excessive and only use a
      16px spacing.
      Part-of: <!1702>
  6. 02 Mar, 2021 13 commits
    • Georges Basile Stavracas Neto's avatar
      overview: Don't show black panel on startup · 9bce2a02
      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's avatar
      panel: Bind style to corners' style · 72505227
      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's avatar
      overview: Implement startup animation · c4e43efb
      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's avatar
      overviewControl: Store search entry container · 930d0b61
      Georges Basile Stavracas Neto authored
      It'll be used by the next commit.
      Part-of: <!1678>
    • Georges Basile Stavracas Neto's avatar
      layout: Update workspace struts even while starting up · e3f12e3e
      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's avatar
      layout: Don't build input region rects on Wayland · bc097461
      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's avatar
      layout: Allow updating struts in Overview · ba0b9239
      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's avatar
      status/network: Use the same signal strength values as GNOME Settings · 9cd211a9
      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's avatar
      shell/app: Handle workspace from startup notifications · 9a273e1d
      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's avatar
      st/scrollview: Apply correct fade_edges_left/right effect uniforms in RTL · 40b67a14
      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
      Part-of: <!1630>
    • Carlos Garnacho's avatar
      appDisplay: Don't reset adjustment on ::pages-changed · 9b24d9c4
      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's avatar
      appDisplay: Slide page hints along page switching · ec223f31
      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
      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's avatar
      appDisplay: Adapt to available extra space showing icon grids · 9e5b357b
      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>