Resizing on tiling window managers is broken

[zjeffer]

https://user-images.githubusercontent.com/4633209/213937857-2236bb1c-742e-463a-8e1c-1e8cf6e97042.mp4

This is on bspwm, a tiling window manager running in X11. Resizing with bspwm's keyboard shortcuts works fine: I press super+left click on the window to move, super+right click near a corner to resize.

1. Moving the window using the window bar works fine.
2. Resizing the window by dragging the top border continuously moves the window diagonally to the left until I release the mouse button. Only the top border seems to be interactive.
   • Resizing windows by dragging the border shouldn't even be possible in most tiling window managers. I've been using bspwm for around 5 years, and I've never come across an app that can be resized by dragging one of the window's borders. I always resize using keyboard shortcuts.
3. With native window frame disabled, double clicking the bar will create new borders around the whole window (see 0:40 in the video). This makes all borders have resizing handles, including the corners for diagonal resizing. Dragging these handles results in the same bug as point 2.
4. Resizing this way widens the notes list pane to be about half the window width. (This is a separate issue: #482)

[bjorn]

For sure related to our custom resizing implementation, which can be found in the code by looking for m_canStretchWindow. While it would be nice to fix it, this code should likely also get disabled when a native frame is used.

[nuttyartist]

For sure related to our custom resizing implementation, which can be found in the code by looking for m_canStretchWindow. While it would be nice to fix it, this code should likely also get disabled when a native frame is used.

👍

[zjeffer]

Just out of interest, why do we have a custom resizing implementation? What does it do better than the normal Qt resizing?

[guihkx]

I could be wrong, but I believe once we go "frameless mode", we have to (or had to) deal with window decorations and window controls ourselves...

[nuttyartist]

I could be wrong, but I believe once we go "frameless mode", we have to (or had to) deal with window decorations and window controls ourselves...

Exactly. It's a big pain to do so, it's never as smooth as native. On macOS it's a native experience because we're using custom native Objective-C code from this repo https://github.com/Bringer-of-Light/Qt-Nice-Frameless-Window. We should also try to integrate its Windows equivalent (in the same repo), but I remember the last programmer reported problems to do so. We should try again tho.

[nuttyartist]

Seems like there are many other cool open source projects:

This one is pretty cool https://github.com/zhiyiYo/PyQt-Frameless-Window based on: https://github.com/wangwenx190/framelesshelper https://github.com/winsoft666/Qt-FramelessWindow https://github.com/antonypro/QGoodWindow

[bjorn]

Of course, similar to our change to use startSystemMove (#445), for proper resizing behavior we need to call startSystemResize.

[nuttyartist]

Of course, similar to our change to use startSystemMove (#445), for proper resizing behavior we need to call startSystemResize.

Oh, cool.

[nuttyartist]

Is this fixed after https://github.com/nuttyartist/notes/pull/492? @guihkx

[guihkx]

I'm not really sure. Perhaps @zjeffer can retest this...

[zjeffer]

It's not completely fixed but is has been improved. Resizing using the window borders is now impossible unless I enable non-native frame, and double click the border.

So only point 3 needs to be fixed. Preferably, double clicking the border shouldn't really do anything.

[zjeffer]

Current situation when building the dev branch, starting from a clean settings file:

https://user-images.githubusercontent.com/4633209/221948417-65ac04fc-cdfc-4b74-b03b-37b4171a72a3.mp4

Since recently, the 'double clicked mode' seems to have shadows inside of the window borders (these borders are automatically added by my window manager). I would expect to see those shadows outside of the border.

[bjorn]

I would expect to see those shadows outside of the border.

Hmm, yes, but then the window manager has to draw the shadow rather than Notes, I guess.

[guihkx]

Oof. When you double click the title bar, the window is actually supposed to be maximized (to mimic what most window managers do), but I'm guessing bspwm doesn't allow that on purpose?

The margins and shadows around the window were restored in #492, so users could resize it properly. We could get rid of the margins again, but in my opinion the resizing mechanism has to be improved as well...

Overall, we should probably recommend using native window decorations for people using tiling window managers.

[nuttyartist]

Current situation when building the dev branch, starting from a clean settings file:

Since recently, the 'double clicked mode' seems to have shadows inside of the window borders (these borders are automatically added by my window manager). I would expect to see those shadows outside of the border.

Oh no, how come with native window rendering you can't resize the window? Is this only a problem with your specific window manager? At least that should work...

[zjeffer]

Oh no, how come with native window rendering you can't resize the window?

That's a tiling window manager thing; not a problem :)

[zjeffer]

Oof. When you double click the title bar, the window is actually supposed to be maximized (to mimic what most window managers do), but I'm guessing bspwm doesn't allow that on purpose?

Maximizing on bspwm works by putting the window in the monocle mode, which requires a specific keybind, not something you can do with the mouse.

Usually, bspwm hides the titlebar anyway, so the user never gets to double click the titlebar. For apps that implement custom window decorations (like Visual Studio Code), this is how it looks:

https://user-images.githubusercontent.com/4633209/222233737-5bbe398a-7336-436f-b6a4-6529d56ca86f.mp4

So the maximizing function does get called, and the middle button changes. But nothing happens to the window itself. I would prefer something like this to happen in Notes, too.

Maybe we could find a way to fix the margins and shadows, and improve resizing, but without the impact on tiling wms.

Overall, we should probably recommend using native window decorations for people using tiling window managers.

Definitely

[zjeffer]

I'm also getting strange behaviour in my Ubuntu VM (latest master Qt6 AppImage):

https://user-images.githubusercontent.com/4633209/226169308-cae43aa7-ed40-45ef-b11a-7ee382d47eda.mp4

• There's an area near the top bar that can drag, but when dragging slightly below that, the window resizes in height to fill the whole screen.
• Resizing with the top bar works
• Resizing with the two sides also works, but I forgot to record this
• Resizing with the corners triggers the bug

Maybe this happens because I'm on a VM running inside a tiling WM, can any of you check whether this same thing happens on your machines?

[zjeffer]

I just found the above only happens when:

1. Starting the application with native decorations enabled
2. Disabling native decorations inside the application
3. The bug will occur

When starting the application with native decorations already disabled, this bug doesn't occur. I'll create a separate issue. The bug in this issue still happens on bspwm, regardless of when I disable native decorations.

[nuttyartist]

Weird. Day by day I'm getting more used to the fact that we should ship native window decorations by default on Linux as well. Edit: It just doesn't look sexy ):