Commit Graph

15010 Commits

Author SHA1 Message Date
Aurimas Černius
5e66b104dc Updated Lithuanian translation 2020-06-21 22:18:03 +03:00
Florian Müllner
08a5f41505 windowManager: Support prepending workspace with horizontal layouts
Commit ce35d523a2 implemented that behavior for vertical workspace layouts,
there is no reason to not allow the same for horizontal layouts.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2916
2020-06-20 08:15:44 +00:00
Carlos Garnacho
ec36762309 st: Add st_clipboard_get_content()
Complementing st_clipboard_set_content(), this function allows retrieving
specific mimetypes from the selection as GBytes.

Related: https://gitlab.gnome.org/GNOME/nautilus/-/issues/634

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1321
2020-06-19 13:44:15 +02:00
Georges Basile Stavracas Neto
aa70020bc8 appDisplay: Compare indicator and grid pages
In the past, the icon grid would update the number of pages
during the call to adaptToSize(). However, after the new grid
layout landed, the number of pages is updated by the time an
item is added or removed.

Instead of comparing the old and new number of pages in the
icon grid, compare the pages shown by the indicator, and the
grid pages.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:54:31 -03:00
Georges Basile Stavracas Neto
1e77e6fc79 pageIndicator: Add getter for current number of pages
Add a getter to PageIndicators to retrieve the number of pages
it currently displays.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:54:31 -03:00
Georges Basile Stavracas Neto
68203e7091 appDisplay: Allow a slighly bigger area for drag overshoot
Now that we don't have the Frequent tab anymore, and subsequently
the buttons to switch tabs, the app grid fill all the way to the
bottom, leaving no room for drag overshoot.

Add a 20px (i.e. OVERSHOOT_THRESHOLD) area at the bottom of the
grid where dragging actually scrolls to the next page.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:54:31 -03:00
Georges Basile Stavracas Neto
cff0752bcc appDisplay: Factor out shared code into BaseAppView
The two BaseAppView subclasses now share a lot in terms of
widgetry: they both have a scroll view, pagination dots, swipe
management, etc.

Move this shared code into BaseAppView. Notice, however, that
BaseAppView only creates the widgetry, but it doesn't add them
to any specific layout. FolderView arranges the widgetry in a
vertical box, while AppDisplay arranges it in a ShellStack.

Add a new 'orientation' parameter to BaseAppView and use it
to determine the orientation of the pagination dots, the swipe
tracker direction, and the scroll event handling.

It is worth noticing that the scroll event is a bit more
sophisticated now: when the orientation is horizontal, it
handles all directions since mice wheels usually only generate
up/down events.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:54:31 -03:00
Georges Basile Stavracas Neto
45d8e11123 Add pagination to the folder dialog
Make the folder dialog's app grid horizontal, and add
paginators to it as well. Add a new _createGrid() method
to BaseAppView that created an IconGrid.IconGrid by
default, and make FolderView override it to return the
new FolderGrid class.

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

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:54:22 -03:00
Georges Basile Stavracas Neto
5aee714b70 theme: Adjust folder dialog CSS
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:32:01 -03:00
Georges Basile Stavracas Neto
3c3c3b7c69 appDisplay: Don't destroy FolderView directly
When FolderIcon is destroyed, it destroyed the FolderView and, if
there's a folder dialog present, it destroys the dialog as well.

Turns out, the folder dialog adds the icon's FolderView to itself.
The view becomes part of the dialog's actor tree. When the dialog
is destroyed, it also tries to destroy the view - but the folder
view was already destroyed by FolderIcon!

Fix that by letting the dialog destroy the folder view if it exists,
otherwise destroy the folder view directly.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:32:01 -03:00
Georges Basile Stavracas Neto
6ba2913075 appDisplay: Add items in order
Add app icons to the exact page and position they're located
instead of always appending. This will be useful later when
custom icon positions are in place.

For now, it assumes pages are always filled, which is true,
but this will also change with custom icon positions.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:31:57 -03:00
Georges Basile Stavracas Neto
75c4e1cd63 appDisplay: Actually destroy icons
AppDisplay currently adds all icons, and hides the ones inside
a folder. Change that to only add the icons that are not inside
folders. Adding an icon to a folder removes the icon from the
main grid.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:30:12 -03:00
Georges Basile Stavracas Neto
fb4a4ca4a2 appDisplay: Redisplay folders before AppDisplay
When filtering out the app icons, AppDisplay calls FolderIcon.getAppIds(),
which then calls FolderView.getAllItems(). This last function reads the
already added app icons inside the given folder, and return their app ids.

So far, so good.

When the GSettings backing a folder changes, FolderIcon emits 'apps-changed'
to notify AppDisplay that the folder changed.

Cool.

When AppDisplay receives this signal, it first recreates its own icons, then
updates the folders, and finally hides the icons that are inside folders.

This series of events is unfortunate. Future patches will need the folder
to be updated *before* AppDisplay updates its own icons.

Update folder icons before chaining up to BaseAppView._redisplay().

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:30:12 -03:00
Georges Basile Stavracas Neto
4c2c1297be appDisplay: Move child focus handling to IconGrid
The icon grid is always paginated, so the app grid code doesn't need
to behave differently in the FolderView and AppDisplay.

Move the keyboard handling to IconGrid itself, and remove the now dead
code from AppDisplay.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:30:12 -03:00
Georges Basile Stavracas Neto
c5dbdad5fc iconGrid: Adapt grid layout according to available size
The new icon grid layout operates based on rows and columns, and
doesn't try to dynamically adapt it to fit to the container. In
this case, it is better to have a pre-defined set of well-known,
well-tested rows and columns, and switch between them based on
the aspect ratio of the screen.

Introduce a set of modes to the icon grid, and select the mode
that is closest to the aspect ratio.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:30:12 -03:00
Georges Basile Stavracas Neto
4e05bcd3b6 iconGrid: Use IconGridLayout
Replace the current grid code with IconGridLayout.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:30:12 -03:00
Georges Basile Stavracas Neto
3555550d5e iconGrid: Introduce IconGridLayout
IconGridLayout is a new layout manager that aims to replace the
current paginated layout algorithm implemented by the icon grid.

There are a few outstanding aspects of this new layout manager
that are worth highlighting. IconGridLayout implements all the
mechanisms necessary for a paginated icon grid, but doesn't
implement any policies around it. The reason behind this decision
is that this layout manager will be used by other places (e.g.
the login dialog) that demand different policies to how the
grid should look like.

Another important aspect of this grid is that it does not queue
any relayouts when changing its properties. If a relayout is
required, the actor should manually queue it. This is necessary
to avoid layout loops.

Add the IconGridLayout class. Next commits will do the surgery
to IconGrid and any related code to use this new layout manager.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
2020-06-18 10:30:12 -03:00
Daniel van Vugt
8e05fa2728 st: Don't leak st_describe_actor strings
Hopefully this code doesn't get hit much. And it does seem to be the
only user of the function.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1319
2020-06-18 14:10:59 +08:00
Florentina Mușat
d7c3050e2d Update Romanian translation 2020-06-17 15:47:59 +00:00
Jonas Dreßler
89ba8562c3 dnd: Set drag actor position immediately after reparenting
For drag actors which get reparented to the uiGroup, we currently wait
until the next input event to set the fixed position of the actor, until
that they will just be allocated their old fixed position, which is 0,
0.

So avoid drag actors flickering at the top left for one frame and
position them correctly right after reparenting.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
2020-06-17 10:47:50 +02:00
Jonas Dreßler
82da73baff dnd: Fix size of actors which don't get allocated their preferred size
Properly adjust for drag actors which were allocated using a custom
vfunc_allocate() and might not have gotten allocated their preferred
size. When DND reparents the actor to the uiGroup, the drag actor will
get allocated its preferred size, so we also need to take the difference
between the old allocation size and the preferred size into account
before reparenting to the uiGroup.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
2020-06-17 10:47:47 +02:00
Jonas Dreßler
b2eeda9b46 dnd: Don't override fixed position if actor had no fixed position before
Properly handle drag actors which are not allocated using a fixed
position and disable the fixed position we were using to move the actor
around before we reparent it again to its original parent.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
2020-06-17 10:46:46 +02:00
Florian Müllner
0db41a3773 st/scroll-bar: Fix horizontal bar in RTL locales
As the view now scrolls from right-to-left in RTL locales, the
scroll bar handle should reflect that.

Likewise the event handling needs adjusting as well: Scrolling
left should increase the adjustment value, and clicking the
trough to the left of the handle as well.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1318
2020-06-17 01:08:03 +02:00
Florian Müllner
8d7f7e61dd st/scroll-view: Adjust scroll events in RTL locales
In RTL locales, scrolling left should increase the adjustment value.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1318
2020-06-17 01:07:28 +02:00
Florian Müllner
3f4b253dac st/viewport: Fix horizontal translation in RTL locales
In RTL locales, the lowest value should correspond to the right-most
position and vice-versa.

That this went unnoticed for so long shows how we have avoided horizontal
scrolling so far :-)

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1318
2020-06-16 23:57:51 +02: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
Jonas Dreßler
8357739ef8 workspace: Stop exporting window actor in the WindowPreview
Having a public property exporting the MetaWindow is enough to get the
window actor, too, so remove the public realWindow property and while at
it, rename that property to _windowActor, too.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
2020-06-16 14:10:01 +02:00
Jonas Dreßler
6bef9334b7 workspace: Initialize WindowPreview using a MetaWindow
MetaWindow is Mutters representation of a window and provides all the
APIs about it, MetaWindowActor is just the ClutterActor that's drawing
that window. So use a MetaWindow to create a WindowPreview instead of
the window actor.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
2020-06-16 14:10:01 +02:00
Jonas Dreßler
8c49f45ac8 workspace: Set overviewHint on MetaWindow
We want to stop using the MetaWindowActor for things which are actually
related to the MetaWindow, one more thing where we can change that is
the overviewHint, which is currently added to the MetaWindowActor.

So move that hint to the MetaWindow and stop calling
get_compositor_private() in a few more places.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
2020-06-16 14:10:01 +02:00
Jonas Dreßler
46600740fe workspace: Stop using WindowPreview.realWindow in the overview
We can simply get the MetaWindowActor by calling
MetaWindow.get_compositor_private(), so stop accessing the realWindow
property of WindowPreview. For this we also have to make _isMyWindow()
and _isOverviewWindow() take a MetaWindow as an argument instead of a
MetaWindowActor.

Since the WorkspacesThumbnails are also drop targets for WindowPreviews
and their WindowClones also have the public metaWindow property, switch
to using the metaWindow property there, too.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
2020-06-16 14:10:01 +02:00
Jonas Dreßler
c281e868a0 workspace: Only pass MetaWindow to WindowPreviewLayout
Since the WindowPreview class rarely needs to handle the actual actor
painting the window preview, refactor the WindowPreviewLayout a bit to
only pass a MetaWindow to its addWindow() and removeWindow() functions.

Also make the getWindows() function return an array of MetaWindows,
which makes the getMetaWindow() function obsolete, so remove that.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
2020-06-16 14:09:54 +02:00
Jonas Dreßler
039431a73f workspace: Stop using clone terminology in WindowPreviewLayout
We're going to remove ClutterClones, so call the parameters to
addWindow() and removeWindow() "actor" instead of "clone". Also make the
destroyIds less confusing and rename the actual actor destroy id to
"destroyId", and rename the window actors destroy id to
"windowActorDestroyId".

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
2020-06-16 14:04:10 +02:00
Jonas Dreßler
d4f8ea1c53 workspace: Make some functions in WindowPreview private
Now that the WindowPreview also shows the overlays itself, we can make
some functions private.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
2020-06-16 13:55:17 +02:00
Jonas Dreßler
96f5e2b33e workspace: Call _activate() directly when clicking the window preview
We can remove the simply callback function in favour of an anonymous
function here.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
2020-06-16 13:55:17 +02:00
Jonas Dreßler
93a542d52c workspace: Set WindowPreview offscreen redirect inside constructor
This can also be moved to constructor, so do it.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
2020-06-16 13:55:17 +02:00
Jonas Dreßler
f4fcba74ff workspace: Remove slot property of WindowPreview
Since the slot property was only accessed by the old WindowOverlays to
get the position and size of the preview, we can safely stop setting it
and remove that property now.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
2020-06-16 13:55:17 +02:00
Jonas Dreßler
cadbf7cd8b workspace: Rename WindowClone to WindowPreview
Since ClutterClones are going to be removed, let's switch the
terminology here to something that's more understandable and rename the
WindowClone class and its layout manager to
WindowPreview/WindowPreviewLayout.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
2020-06-16 13:55:17 +02:00
Jonas Dreßler
dd8e1aef51 st-widget: Use clutter_input_device_get_actor() to get pointer actor
Use clutter_input_device_get_actor() since it replaces
clutter_input_device_get_pointer_actor().

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1285
2020-06-16 09:33:08 +00:00
Baurzhan Muftakhidinov
15dc37a139 Update Kazakh translation 2020-06-15 13:38:33 +00:00
Jonas Dreßler
c23ad83c59 windowManager: Warn when removing old animationInfo
Now that we properly notify mutter about when a size-change animation
has ended, it should never happen that a new size-change animation is
started without the last one being cancelled (ie. 'kill-window-effects'
being emitted).

This means there should also never be an old animationInfo attached to a
window actor, so warn in case we still find one when starting the
animation.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
2020-06-15 13:12:03 +00:00
Jonas Dreßler
4a6f550acb windowManager: Use new mutter API to freeze window actors ourself
We're currently using the hack of telling mutter that our effect is
completed (even though it isn't) in order to unfreeze updates of the
window actor.

This causes a bug with detecting the wl_outputs a window is
visible on, because the MetaWindowActor emits its "effects-completed"
signal too early, making Mutter update the wl_outputs while we're doing
the animation.

Now since meta_wayland_actor_surface_is_on_logical_monitor() uses the
transformed position and size of the MetaSurfaceActor and is being
called right after we setup the animation (but before it actually
starts, that happens at the next paint cycle) it will use a "very wrong"
rectangle: The transformation has been set to move the actor back to its
old position, and while we did already unfreeze updates and called
clutter_actor_set_position() in meta_window_actor_sync_actor_geometry(),
the actual allocation is not updated yet; this makes
clutter_actor_get_transformed_position() return a position including in
the new transformation, but not including the new allocation, and the
rectangle ends up being moved to the next monitor or completely out of
the stage.

To fix this issue properly, we need to decouple unfreezing actor updates
from emitting the "effects-completed" signal, which is now possible with
the new meta_window_actor_freeze() and meta_window_actor_thaw() APIs. So
use those new methods to freeze and thaw actor updates ourselves and
make sure to call shellwm.completed_size_change() only after the
animation has finished.

Mutter MR: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1250

Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/513

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
2020-06-15 13:12:03 +00:00
Jonas Dreßler
8078d78c30 windowManager: Also clear animationInfo when size-changed wasn't emitted
It might be that we receive a "kill-window-effects" signal between the
emission of the "size-change" and the "size-changed" signal.

In this case we already have the animationInfo attached to the window
actor, so we should also remove it.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
2020-06-15 13:12:03 +00:00
Jonas Dreßler
d7185d71c6 windowManager: Clean up starting of size-change animations a bit
We can do without having two calls to shellwm.completed_size_change() in
there, so use an early return for all cases.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
2020-06-15 13:12:03 +00:00
Sebastian Keller
522ecba180 workspace: Center overlay close button on border using guide actor
This makes use of the invisible actor introduced in the previous commit
to center the close button on the border.

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

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1313
2020-06-14 21:58:47 +00:00
Sebastian Keller
9b22f6183f workspace: Use invisible guide actor to center overlay title on border
Using CSS to center the title actor on the border is a bit ugly, because
it requires the CSS to match the calculations used in chromeHeights().
Also it is not possible to use CSS margins for cases where the position
of the actor is determined at run time, such as for the close button.

Instead use an invisible actor that spans between the horizontal and
vertical center lines of the border as guide when aligning the title
actor.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1313
2020-06-14 21:58:47 +00:00
Florian Müllner
b2c35e4fb0 workspace: Unbreak reposition animation
Commit 1ea22a5281 broke the window reposition animation when it
based the ::size-changed signal on the layout manager's bounding box
instead of the MetaWindow::size-changed signal.

That's happening because of the combination of:

  1. we adjust to window size changes immediately without animations
  2. closing a window triggers a change to a 0x0 bounding box which
     is not treated as a size change

Fix this by addressing the 2nd factor, and don't treat a change to
a 0x0 bounding box as size change.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2901
2020-06-14 21:20:36 +00:00
Jonas Dreßler
af543daf1c workspacesView: Only animate on show() when geometries are already set
Animating the window clones of the overview requires the fullGeometry
and the actualGeometry to be set, which they won't be when showing the
overview for the first time. So don't even try to animate the window
clones in that case because the geometries will still be null and
accessing them in workspace.js will throw errors.

The workspace views will still get the correct layout as soon as the
allocations happen because syncing the geometries will trigger updating
the window positions. Since animations are disabled for position changes
when syncing the geometry though, we won't get an animation and the
clones will jump into place. That's not a regression though since before
this change we also didn't animate in that case because the geometries
used were simply wrong (the actualGeometry was 0-sized as explained in
the last commit).

If we wanted to fix the initial animation of the overview, we'd have to
always enable animations of the window clones when syncing geometries,
but that would break the animation of the workspace when hovering the
workspaceThumbnail slider, because right now those animations are "glued
together" using the actualGeometry, so they would get out of sync.

The reason there are no errors happening in workspace.js with the
existing code is that due to a bug in Clutter the fullGeometry of
WorkspacesDisplay gets set very early while mapping the WorkspacesViews
(because the overviews ControlsManager gets an allocation during the
resource scale calculation of a ClutterClone, see
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1181), so it
won't be set to null anymore when calling
WorkspacesView.animateToOverview().

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1119
2020-06-14 14:44:10 +00:00
Jonas Dreßler
baeb4079ee workspacesView: Avoid setting invalid geometries on views
The fullGeometry and the actualGeometry of the WorkspacesDisplay are set
from the allocation of the overviews ControlsManager and the
WorkspacesDisplay, that means they're only valid after those actors got
their allocations during Clutters allocation cycle.

Since WorkspacesDisplay._updateWorkspacesViews() is already called while
showing/mapping the WorkspacesDisplay, that allocation cycle didn't
happen yet and we end up either setting the geometries of the views to
null (in case of the fullGeometry) or to something wrong (a 0-sized
allocation in case of the actualGeometry).

So avoid setting invalid geometries on the views by initializing both
the fullGeometry and the actualGeometry to null, and then only updating
the geometries of the views after they're set to a correct value.

Note that this means we won't correctly animate the overview the first
time we open it since the animation depends on the geometries being set,
but is being started from show(), which means no allocations have
happened yet. In practice this introduces no regression though since
before this change we simply used incorrect geometries (see the 0-sized
allocation mentioned above) on the initial opening and the animation
didn't work either.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1119
2020-06-14 14:44:10 +00:00
Emin Tufan Çetin
f91f9801b4 Update Turkish translation 2020-06-14 07:52:41 +00:00
Jonas Dreßler
c5634335b0 workspace: Remove WindowOverlay in favour of new overlays of WindowClone
Start using the new overlays we introduced in the last commit and remove
the WindowOverlay class and the objects for keeping track of them in the
Workspace.

The new layout which doesn't use the -shell-close-overlap CSS property
anymore sligthly changes the position of the close button to be a bit
further away from the actual window.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
2020-06-11 20:50:08 +02:00