Implement interactive move #547

Pajn · 2024-07-15T18:15:47Z

I've started working on interactive move support as I eventually want #122 but it's a little too big to start with. Interactive move feels smaller but still like a step towards it.

Currently implemented:

YaLTeR · 2024-07-15T18:17:45Z

Cool! But just FYI, I was going to get this done as part of adding floating windows, which will need lots of refactoring.

YaLTeR · 2024-07-15T18:20:11Z

(I am postponing it until then specifically because it will influence the architecture and design of moving windows)

Pajn · 2024-07-15T18:21:46Z

@YaLTeR If you are on it I can drop it. I wanted to try and get a feel for the code before committing to something publicly but do understand that it can mean it doesn't at all fit with your plans or is already started in some other way.

YaLTeR · 2024-07-15T18:27:02Z

I am not "on it" (busy with uni atm, don't want to take on big tasks for the time being), but it will likely lead to different design and code compared to implementing move without a floating layer. For example, I thought that moving a window out of a column would just put it on the floating layer for the duration of the move (and then whether it stays there or goes back into a column depends on where you drop it). Which is obviously not possible without a floating layer. Or, how to handle moves across monitors, which will also be just transparently handled by the floating layer, etc.

Pajn · 2024-07-15T18:51:16Z

That was badly worded. Having some thoughts about the implementation definately counts in what I inteded with "on it" even if not actively or having started coding. And you should ofc. prio uni.
I'm very happy to just drop it if you want. Or rework it in a way closer to what you describe.

I'm thinking maybe I could take a shot at adding a "floating layer" that to start with will only be used for holding the window under drag and then full floating support can be added to it later?

However that would immediately raise at the very least one architectural question that maybe you don't want to nail down atm. Is the floating layer bound to a workspace (so floating windows are hidden when you switch workspace/possibly other floating windows from the new workspace are shown) or is the floating layer above the workspace so the same floating windows are shown over all workspaces?

Or is there anything else I can look at that could help bring floating windows closer while still being a limited scope?

YaLTeR · 2024-07-15T19:01:00Z

However that would immediately raise at the very least one architectural question that maybe you don't want to nail down atm. Is the floating layer bound to a workspace (so floating windows are hidden when you switch workspace/possibly other floating windows from the new workspace are shown) or is the floating layer above the workspace so the same floating windows are shown over all workspaces?

I think floating should be global across monitors (use the same coordinate system as the mouse pointer essentially) and, for the first impl, always on top (no workspaces). This means, among other things, moving monitor position tracking into the layout.

I'm very happy to just drop it if you want. Or rework it in a way closer to what you describe.

I'm thinking maybe I could take a shot at adding a "floating layer" that to start with will only be used for holding the window under drag and then full floating support can be added to it later?

Well, I really don't want to tell people to drop something, especially when I haven't started working on it myself. I took a very brief glance at the contents of this PR and it seems to change all the expected places, which is good. But it's just, with larger refactors like this, it may turn out that reviewing someone else's work and shaping it to my vision takes way more effort for both parties than if I eventually just do a several day long dive myself.

Pajn · 2024-07-15T21:45:25Z

But it's just, with larger refactors like this, it may turn out that reviewing someone else's work and shaping it to my vision takes way more effort for both parties than if I eventually just do a several day long dive myself.

Totally agree and why not tackling floating layout directly and also why I'm happy to drop this work if you think it's too close to it. I'll start looking into shaping this into something that could work well with the floating layout you describe and see if it's possible while keeping it small.

Pajn · 2024-07-18T09:54:17Z

I've reworked it to remove the window from the workspace and store it on layout during the move instead. So while no floating layer atm. I think it should work pretty well with one, with some code just getting moved into it instead.

So far it has been very kind to the existing structure but I do start to need to extract some stuff from Tile into some kind of TopLevel structure that can be used by both Tile and the moving window (as well as floating windows in the future). For example borders and the rendering logic.
I think I can leave monitor position tracking untouched as it should be able to recover on the next motion event but will look into re-config during move later to make sure it's not too broken.

Still very wip and not ready for review but I'm at a point where its very usable for myself at least.
I've also added a very basic solid color insert hint which really helps seeing what's happening. I tried to make it autoscroll to show the insert hint outside of the screen but that part feels quite yanky to use. Probably just going to drop it and add a way to manually scroll the workspace during the move.

YaLTeR · 2024-07-18T10:19:54Z

I do start to need to extract some stuff from Tile into some kind of TopLevel structure that can be used by both Tile and the moving window (as well as floating windows in the future)

That is what the Tile already is. Window with borders and other stuff. Don't mind that it's called Tile.

Pajn · 2024-07-22T09:35:22Z

I think this is working quite well now.

Switched to using Tile which cleaned up a few things and added back focus-ring rendering
Switched the attempt at auto-scrolling to instead allow pressing the middle mouse button during the move for manual scrolling.
Tested workspace and output actions during moving and made sure it doesn't blow up

YaLTeR · 2024-07-23T05:27:48Z

I'll try to take a look over the following days.

YaLTeR

Thanks, this looks very solid already!

These clients are very useful for testing: https://gitlab.freedesktop.org/emersion/wleird

Especially wleird-resize-loop. I also found useful these patches to it:

diff --git a/resize-loop.c b/resize-loop.c
index c1171a5..200908f 100644
--- a/resize-loop.c
+++ b/resize-loop.c
@@ -6,7 +6,7 @@
 
 #define MIN 2
 #define MAX 512
-#define SPEED 10
+#define SPEED 3
 static int size = MIN;
 
 static struct wleird_toplevel toplevel = {0};
@@ -27,6 +27,8 @@ static void callback_handle_done(void *data, struct wl_callback *callback,
 
 	toplevel.surface.width = abs(size);
 	toplevel.surface.height = abs(size);
+	xdg_toplevel_set_min_size(toplevel.xdg_toplevel, abs(size), abs(size));
+	xdg_toplevel_set_max_size(toplevel.xdg_toplevel, abs(size), abs(size));
 	surface_render(&toplevel.surface);
 
 	size += SPEED;

YaLTeR · 2024-07-28T05:49:13Z

resources/default-config.kdl

@@ -178,6 +178,14 @@ layout {
        // inactive-gradient from="#505050" to="#808080" angle=45 relative-to="workspace-view"
    }

+    insert-hint {


Tbh I'd not include this in the default config, not that important for first time users.

YaLTeR · 2024-07-28T05:51:06Z

src/niri.rs

@@ -2919,8 +2923,18 @@ impl Niri {
        if mon.render_above_top_layer() {
            elements.extend(monitor_elements.into_iter().map(OutputRenderElements::from));
            extend_from_layer(&mut elements, Layer::Top);
+            elements.extend(


Right, how to handle this ordering is one of the design questions... I guess this makes sense even if a bit weird.

YaLTeR · 2024-07-28T05:52:58Z

src/window/mapped.rs

@@ -69,6 +69,11 @@ pub struct Mapped {
    /// Snapshot right before an animated commit.
    animation_snapshot: Option<LayoutElementRenderSnapshot>,

+    /// Last time interactive move was started.
+    ///
+    /// Used for double-move-click tracking.


What do we do with a double-move-click? Whatever we do, I'm not sure it's a good idea, because when moving clients by title bar, double click will cause a maximize. So I think it should either be also maximize, or nothing, to avoid the ambiguity.

Right, I copied the setup from resize without thinking about that. Nothing probably makes sense for now at least. It still allows adding maximize or other things later.

YaLTeR · 2024-07-28T05:58:20Z

src/input/move_grab.rs

+                    .cloned();
+                if let Some(output) = output {
+                    self.is_moving = true;
+                    data.niri.layout.view_offset_gesture_begin(&output, false);


I feel like we shouldn't re-use the view offset gesture like this, and rather add the necessary logic into interactive move itself. Especially when we go into the floating layer direction where it will behave differently.

YaLTeR · 2024-07-28T05:59:22Z

src/layout/mod.rs

 #[derive(Debug, Clone, Copy)]
 pub struct InteractiveResizeData {
    pub edges: ResizeEdge,
 }

 pub trait LayoutElement {
    /// Type that can be used as a unique ID of this element.
-    type Id: PartialEq + std::fmt::Debug;
+    type Id: Clone + PartialEq + std::fmt::Debug;


Why is this needed?

YaLTeR · 2024-07-28T06:53:00Z

src/layout/mod.rs

@@ -41,11 +41,13 @@ use smithay::backend::renderer::element::Id;
 use smithay::backend::renderer::gles::{GlesRenderer, GlesTexture};


When a workspace switches, the new workspace should get an insert hint right away. Currently it doesn't until a mouse movement.

YaLTeR · 2024-07-28T06:56:01Z

src/layout/workspace.rs

+                let size = Size::from((self.data.get(column_index)?.width, 300.));
+                let loc = Point::from((
+                    self.column_x(column_index),
+                    self.columns.get(column_index)?.tile_offset(tile_index).y - size.h / 2.,


This doesn't take topmost/bottommost gap into account, so the hint extends up/down there. I feel like it should end on the same pixel the window would end.

YaLTeR · 2024-07-28T06:58:10Z

src/layout/mod.rs

@@ -2246,6 +2361,154 @@ impl<W: LayoutElement> Layout<W> {
        None
    }

+    pub fn interactive_move_begin(


When starting a move while in the middle of a workspace switch, the grabbed window position is wrong (does not correspond to where you grabbed the window).

YaLTeR · 2024-07-28T06:58:50Z

src/layout/mod.rs

+        true
+    }
+
+    pub fn interactive_move_update(


When in the middle of a workspace switch, you can't interactive-move across the two workspaces. Up to you if you want to fix this because this is a bit of an edge case.

YaLTeR · 2024-07-28T07:00:37Z

src/layout/workspace.rs

+    fn insert_hint_area(&self, insert_hint: &InsertHint) -> Option<Rectangle<f64, Logical>> {
+        let mut hint_area = match insert_hint.position {
+            InsertPosition::NewColumn(column_index) => {
+                if column_index == 0 || column_index == self.columns.len() {


Hint at index 0 is rendered one gap further to the right than it should be (so it touches the next window).

* Added the better color averaging code (tested & functional) * rustfmt * Make Color f32 0..1, clarify premul/unpremul * Fix imports and test name * Premultiply gradient colors matching CSS * Fix indentation * fixup * Add gradient image --------- Co-authored-by: K's Thinkpad <K.T.Kraft@protonmail.com>

v3xro · 2024-09-07T16:10:12Z

This now needs to be rebased to remove the gradient changes that were force-pushed to main.

Pajn force-pushed the interactive-move branch from 16af77e to b673b6d Compare July 18, 2024 09:42

Pajn changed the title ~~WIP: Implement interactive move~~ Implement interactive move Jul 22, 2024

Pajn marked this pull request as ready for review July 22, 2024 09:35

YaLTeR requested changes Jul 28, 2024

View reviewed changes

Pajn force-pushed the interactive-move branch from 5e5b18f to 758a93b Compare August 17, 2024 20:03

Pajn force-pushed the interactive-move branch from 758a93b to f4ef432 Compare August 27, 2024 20:34

YaLTeR and others added 13 commits August 27, 2024 23:55

Add an rpkg spec template

ad1255c

Support initiating an interactive move

48c0ee0

Fix updating other positions correctly while moving

988c278

Add animations when picking up window

20f5c54

Insert windows where they where dropped

0fa604c

Remove moving window from workspace

7bea45a

Render moving window

876a44b

Fix animations of drop in column

10ec525

Handle multiple outputs

2cca981

Fix activation when placing in column

f0a17bc

Show visual hint where window will be placed

a7bff0d

Keep focus on moving window

535bfb7

Pajn added 19 commits August 27, 2024 23:55

Use Tile for moving window

9eaaa37

Replace auto scrolling workspace with manual using middle mouse button

11a2318

Fix insert hint left after switching workspace during move

86e35c5

Fix insert hint position on empty workspace and with gaps

6b9892d

Comment + whitespace

12e52b5

Disable insert hint by default

391a5d6

Remove unnecessary clone derive

f927235

Check window id in (store|clear)_unmap_snapshot

9180536

Make layout render method name clearer

4663622

Only buffer is not fallback buffer

654fb6f

Disable triple-click moves

9915e95

Handle resizing windows during move

dea5da3

Clear insert hint if moved window get closed

09d3c76

Take into account gaps in x direction for insert hints

0056dbe

Implement window_under for moving window

7f2602f

Extract move location calcs to methods

2879070

Update insert hint after workspace shift

28e67a9

Make insert hint stay in vertical working area

d54c1f3

Round hint_area to physical pixels

7b5c01d

Pajn force-pushed the interactive-move branch from 2215b11 to 7b5c01d Compare August 27, 2024 21:57

YaLTeR force-pushed the main branch from 62f2af1 to a2c8553 Compare September 4, 2024 09:39

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement interactive move #547

Implement interactive move #547

Pajn commented Jul 15, 2024 •

edited

Loading

YaLTeR commented Jul 15, 2024

YaLTeR commented Jul 15, 2024

Pajn commented Jul 15, 2024

YaLTeR commented Jul 15, 2024

Pajn commented Jul 15, 2024 •

edited

Loading

YaLTeR commented Jul 15, 2024

Pajn commented Jul 15, 2024

Pajn commented Jul 18, 2024 •

edited

Loading

YaLTeR commented Jul 18, 2024

Pajn commented Jul 22, 2024

YaLTeR commented Jul 23, 2024

YaLTeR left a comment

YaLTeR Jul 28, 2024

YaLTeR Jul 28, 2024

YaLTeR Jul 28, 2024

Pajn Jul 28, 2024

YaLTeR Jul 28, 2024

YaLTeR Jul 28, 2024

YaLTeR Jul 28, 2024

YaLTeR Jul 28, 2024

YaLTeR Jul 28, 2024

YaLTeR Jul 28, 2024

YaLTeR Jul 28, 2024

v3xro commented Sep 7, 2024

		@@ -41,11 +41,13 @@ use smithay::backend::renderer::element::Id;
		use smithay::backend::renderer::gles::{GlesRenderer, GlesTexture};

Implement interactive move #547

Are you sure you want to change the base?

Implement interactive move #547

Conversation

Pajn commented Jul 15, 2024 • edited Loading

YaLTeR commented Jul 15, 2024

YaLTeR commented Jul 15, 2024

Pajn commented Jul 15, 2024

YaLTeR commented Jul 15, 2024

Pajn commented Jul 15, 2024 • edited Loading

YaLTeR commented Jul 15, 2024

Pajn commented Jul 15, 2024

Pajn commented Jul 18, 2024 • edited Loading

YaLTeR commented Jul 18, 2024

Pajn commented Jul 22, 2024

YaLTeR commented Jul 23, 2024

YaLTeR left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

v3xro commented Sep 7, 2024

Pajn commented Jul 15, 2024 •

edited

Loading

Pajn commented Jul 15, 2024 •

edited

Loading

Pajn commented Jul 18, 2024 •

edited

Loading