Commit Graph

25 Commits

Author SHA1 Message Date
Sebastian Keller
a6588d054f windowPreview: Unset selected if window was clicked to switch workspaces
This is used to detect whether a click was short enough to select a
window and activate it or long enough to start a drag. Usually when
clicking on a window and selecting it, this leaves the overview, but
when clicking on a window on a neighboring workspace, the overview is
kept open, but selected is not unset in this case. So all attempts at
dragging the window after using it to switch workspaces will fail.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3783

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1717>
2021-03-01 14:45:50 +00:00
Sebastian Keller
ef5b92c596 windowPreview: Ensure scaling is limited to defined size increase
The preview was getting scaled up by a factor based on what is needed to
increase the width by activeExtraSize pixels. With windows that are
wider than than they are tall, this means that the size of the window
will not increase any more than activeExtraSize in any direction, but
for windows that are taller than they are wide, the vertical scaling
can exceed this. This would break some of the assumptions in the
reported size for the preview chrome and could for very narrow windows
result in a rather large scale.

To fix this, calculate the scaling factor based on whatever is larger,
the height or the width.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1707>
2021-02-24 09:58:31 +00:00
Jonas Dreßler
bc034d5553 windowPreview: Add scaled extra size to chromeWidths() and chromeHeights
Right now the rowSpacing and columSpacing of the layout strategy is
calculated by looking at the overlapping sizes of the close button and
the app icon of the WindowPreview, plus a constant spacing read from CSS
by the WorkspaceLayout that's added to that. We're not factoring in the
extra size of the scaled-up WindowPreviews here and instead depend on
the constant spacing being large enough. If we don't want to depend on
the spacing here, we should add the scaled-up extra size to the sizes
returned by chromeWidths() and chromeHeights().

Since the last commits all previews scale up by the same amount of
pixels, so we can now just add that size to the values returned by
chromeWidths() and chromeHeights().

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
2021-02-19 11:23:07 +00:00
Jonas Dreßler
7d40930cd6 windowPreview: Scale up by the same extra size for every window
Scaling differently sized WindowPreviews by a constant factor will
result in smaller windows getting enlarged by a smaller amount of pixels
than larger windows (1000*1.02=1020 but 100*1.02=102, one will grow by
20 pixels and the other one by 2), this can look a bit weird because
smaller windows don't scale up as much as larger windows.

So introduce a constant extra size to use when scaling windows up, we
set only the half size there because we want to ensure that the size
added on both sides is not fractional and we remain aligned to the pixel
grid.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
2021-02-19 11:23:07 +00:00
Jonas Dreßler
3795ccbcf3 windowPreview: Use a proper spacing between icon and title
Right now the spacing between icon and title works using a little trick
that doesn't really seem intended: The title is offset by
(icon-height * ICON_OVERLAP), when the icon is actually overlapping the
preview by ICON_OVERLAP, and *overflowing* the preview by
(1 - ICON_OVERLAP).

So correct that and offset the title by
(icon-height * (1 - ICON_OVERLAP)), and since now there's no spacing
anymore, add a proper ICON_TITLE_SPACING to that offset.

Also add the new ICON_TITLE_SPACING to the overlapHeight, where the
spacing was ignored so far.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
2021-02-19 11:23:07 +00:00
Sebastian Keller
1bd2b0123e windowPreview: Consider chrome overlaps when offscreening for opacity
The icon and close button might be overlapping the window actor but
were not considered in has_overlaps() which gets used to decide whether
to offscreen the actor for transparency. Since currently the icon is
visible when the preview is dragged and the whole actor is turned
transparent, the opacity will not be applied to everything as a whole
but the child actors individually. This leads to the window becoming
visible behind the icon.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1684>
2021-02-16 13:29:00 +00:00
Florian Müllner
2beca14b8d windowPreview: Tie icon scale to overview state
Scaling the icons all the way from/to 0 is a relatively big transition,
which is fairly distracting when playing simultaneously for multiple
previews after reaching the WINDOW_PICKER state.

Instead, tie the scale to the overview state itself, so that the animations
runs in parallel.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1654>
2021-02-12 19:48:43 +00:00
Florian Müllner
29e2b15236 data: Rename custom close icon
Resource icons are added to the fallback icon theme, so they won't
get used if a matching icon is found in the configured theme.

That includes fallback names, so Adwaita's "window-close-symbolic"
takes precedence over "window-close-24-symbolic" in hicolor.

Fix this by using a custom name for a custom icon.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1640>
2021-02-05 01:01:09 +01:00
Florian Müllner
252f2f5144 cleanup: Define GObject accessors in camelCase
gjs is smart enough to match a propertyName getter/setter to the
corresponding property-name GObject property, so use that and get
rid of the eslint camelcase rule exceptions.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1611>
2021-02-03 20:19:29 +01:00
Florian Müllner
42c2bf709e windowPreview: Overhaul chrome style
- increase close button size
 - use custom close icon that's better suited
   for the non-default 24pxp size
 - use translucent light gray for both close button
   and window caption

https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/81

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1605>
2021-02-02 10:06:23 +01:00
Florian Müllner
30f27412c2 windowPreviews: Replace border with scale effect
We currently use a thick border to indicate the hovered/focused preview. It
works well for that purpose, but is a bit in the face. Slightly scaling up
the preview still provides a clear indication, but in a more subtle and
elegant way.

https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/81

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1605>
2021-02-01 21:06:13 +01:00
Florian Müllner
56c118de87 windowPreview: Keep borderCenter always visible
We need it to position the icon now, which isn't hidden with the
border.

https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/81

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1605>
2021-02-01 21:06:13 +01:00
Florian Müllner
efa3585bcc windowPreview: Add (back) application icons
The overview is less visually-busy nowadays, so add back application
icons to make identifying window previews easier.

Fun fact: Removing the icons was part of my very first gnome-shell
contribution!

https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/81

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1605>
2021-02-01 21:06:13 +01:00
Florian Müllner
5e10bed458 windowPreview: Allow titles to overlap other previews
We are about to add additional chrome, but still want to use
as much space as possible for the previews. Allowing titles
to overlap other previews should help keeping the additional
whitespace requirement low.

https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/81

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1605>
2021-02-01 21:06:13 +01:00
Florian Müllner
bc6849c7a2 windowPreview: Track overlay state separately
We currently express the state as a combination of border visibility
and the eventual transition state. That's tedious, in particular if
we want to use the state outside the show()/hide() methods.

Just track the requested visibility in a separate property.

https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/81

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1605>
2021-02-01 21:06:13 +01:00
Jonas Dreßler
959639bdc9 windowPreview: Cache the boundingBox of the layout manager
Accessing GObject properties from JS has proven to be quite slow because
of the JS->C->JS roundtrip involved. With the WindowPreview this
actually has an impact since we're accessing those properties very often
while creating new layouts.

So cache the boundingBox and the windowCenter properties of the
WindowPreview using a this._cachedBoundingBox JS object. This might
speed up opening the overview with lots of open windows significantly.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
2021-02-01 13:12:43 +00:00
Florian Müllner
40e22eb524 cleanup: Use optional chaining and ?? operator
Those operators have been supported since gjs switched to mozjs78
last cycle. While not ground-breaking, using it makes for a nice
cleanup here and there.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1517>
2020-12-02 15:10:29 +00:00
Jonas Dreßler
0b2430128a windowPreview: Handle case where window already is part of layout
We sometimes add dialogs multiple times to the WindowPreview, for
example for modal dialogs we receive both the "window-added" and the
"window-entered-monitor" signal, which means we call
WindowPreview.addDialog() twice.

We handle that fine already in the WindowPreviewLayout and return NULL
in case the window already was added, so simply handle that NULL return
value and bail out of WindowPreview.addDialog() in this case.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1482
2020-10-26 03:40:19 +00:00
Jonas Dreßler
06df79286d windowPreview: Adapt to ClutterActor API changes
The API of clutter_actor_allocate_preferred_size() changed with
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1310, so adapt to
this change and pass the origin to the function.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1322
2020-07-07 16:51:33 +00:00
Jonas Dreßler
89574abc83 windowPreview: Remove slotId property
We're no longer using that property, so clean up a bit and remove the
last occurences of it.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1351
2020-07-07 11:22:20 +02:00
Florian Müllner
c134091268 windowPreview: Allow to disable overlay
WindowPreviews now contain and manage overlaid elements like close
button or title label themselves. That's generally better, but right now
the only way to disable those overlays (for example during transitions)
is to prevent any hover or focus events from getting to the preview.

Instead, add some explicit API for enabling or disabling overlay support.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
2020-07-07 00:06:49 +02:00
Jonas Dreßler
c26860dcb7 windowPreview: Ensure style as soon as preview is realized
For the windowPreview we need to ensure the style information of the
border and title is up-to-date when chromeWidths() or chromeHeights() is
called. Since the introduction of the WorkspaceLayout those functions
may be called during an allocation cycle, which means we should avoid
calling queuing relayouts inside them. Calling StWidgets ensure_style()
method will queue a relayout though in case the newly generated theme
node has a different geometry.

So avoid queueing a relayout during allocation cycles (and the warning
Clutter logs because of that) by ensuring the style of the border and
title earlier, as soon as the WindowPreview is attached to a stage.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
2020-07-06 23:16:15 +02:00
Jonas Dreßler
751189253a workspace: Use the new WorkspaceLayout for allocating window clones
Switch to the new WorkspaceLayout layout manager to allocate the window
clones of the overview properly using Clutters layouting mechanisms.

Since we now no longer make use of the fullGeometry, we can remove the
setFullGeometry() function from the Workspace class. Also we can stop
setting the actualGeometry on the Workspaces and WorkspaceViews and
instead just set the fixed position and size of the views to their
full or actual geometry. This also has the benefit that we no longer
have to set a custom clip, but can simply enable clip_to_allocation.

The geometry needs to be set inside a BEFORE_REDRAW later because
_updateWorkspacesActualGeometry() is called from a notify::allocation
handler.

This isn't doing any animations when showing/hiding the overview yet,
we'll add that in the next commit.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
2020-07-06 23:16:15 +02:00
Jonas Dreßler
87e4bf52b7 windowPreview: Fix a division by zero
When the bounding box size is 0 during allocation (which happens right
after creating a window for example), we're doing a division by zero and
end up with a NaN scale. This ends up making the childBox NaN, which
triggers an error in Clutters allocation machinery.

So fix that and fall back to a scale of 1 in case the bounding box is
empty.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1320
2020-06-23 15:50:03 +00:00
Jonas Dreßler
e4cbe5126a workspace: Split WindowPreview into a separate file
The workspace.js file is quite large and is a bit confusing when it
comes to the term "window" in there, because it can either refer to a
WindowPreview of a complete window or to an individual window like an
attached dialog.

So try to avoid that confusion and split the new WindowPreview class and
its WindowPreviewLayout layout manager out into a new windowPreview.js
file.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
2020-06-16 14:13:02 +02:00