custom_titlebar doesn't support resize

[PerBothner]

Is your feature request related to a problem? Please describe.
The custom_titlebar looks nice, and moving the window by dragging the titlebar works great. However, resizing the window by dragging the border doesn't work. This may be a documentation/example issue - though it probably needs support in Tao.

Describe the solution you'd like
There should be an option to specify a thin border (but not too thin). Dragging a border side or corner should resize the window. The custom_titlebar example should demonstrate this.

Describe alternatives you've considered
It is probably possible to do this "by hand": Create a border by nesting the main content inside a slightly larger element, and implement a drag handler. But that seems fairly complicated/fragile, and it would be better for the library to do it (either Wry/Tao or the native Gui toolkit).

Would you assign yourself to implement this feature?

• [X ] No

Additional context
This Qt blog seems interesting.

[amrbashir]

custom_titlebar or a window without decorations should be resizable, we added this a while back.
Can you provide info about your system ?

[PerBothner]

Hm. With some care I am able to resize by dragging the border with the mouse. However there are two problems:

1. The mouse cursor only changes on mouse-down, not on hover. That is different from other windows, and makes it difficult to discover the right place to press the mouse - or even that resize-by-drag is a feature.

2. The draggable border is awfully thin, making it harder to find and more painful to use. (This is also an annoyance with KDE applications in comparison with Gtk. The latter seem to have a slightly wider "hit area".)

I'm on Fedora Linux 34, running the default Gnome/Wayland desktop.

[PerBothner]

Also:

3. I can't manage to resize using touch on a touchscreen.

[amrbashir]

1. This is a known issue in Linux and I couldn't find a way to fix it yet.
2. It is a thin border so it doesn't intrude much on the actual content of the window.
3. Can you file a separate feature request for it ? It is a missing event handler like the last time.

[PerBothner]

Created issue #397.

[PerBothner]

"It is a thin border so it doesn't intrude much on the actual content of the window."

Of course it's a tradeoff, but at least on my desktop slightly wider (perhaps matching Gtk) would be more pleasant. Even more so when there is no hover-feedback.

On Gnome the resize-border doesn't actually intrude on the size of the window because the drag area is outside the window area. Could this be done using a transparent frame? That might also make cursor-change-on-hover possible.

[amrbashir]

Nope it is not possible for it to be outside the window.

[PerBothner]

But you get (almost) the same effect by having the user-visible window be slightly smaller and inside a transparent frame. I.e. the actual window is transparent, and nested within it contains a slightly smaller widget for the browser (including custom titlebar). The area between is the invisible border than responds to hover (changing the cursor) and dragging (by resizing).

I don't know if that is how Gnome/Gtk does it, but it is clearly possible - since they do it.

[amrbashir]

The transparent frame is not a possible solution since it will affect the actual size of the window and we would get weird behaviors.

If you happen to know of any gtk app that have custom titlebar I'd be happy to try to mimic how they do it.

[PerBothner]

Most major Gtk/Gnome apps seem to have a custom titlebar: Gnome Terminal; Gnome Web browser (formerly known as epiphany); the gedit editor; Gnome Settings.

They may be using Grtk.HeaderBar but I don't see anything that suggests the HeaderBar container is "magic" or deals with resize borders. Using Gtk.HeaderBar may have the benefit of using the standard icons and content-menu, but it wouldn't be as flexible as creating a custom titlebar with HTML.

[amrbashir]

Using a GtkHeaderBar doesn't necessary mean the window has decorations or not. you can have a GtkHeaderBar and turn off the decorations (resize handlers will be gone).

What we currently do to allow resizing is we listen to the mouse movement event and check the cursor position, if it is in the first 3 pixels of an edge then we change the cursor icon, and if he clicks then we start resizing.

It is not ideal but I couldn't find a better way to do so, this is the same technique used on Windows too and I think this is how electron does it too.

[PerBothner]

Out of curiosity, I tried Electron with new BrowserWindow({frame: false, ...}), In that case the nouse-cursor does change when hovering over the border (like regular windows). The window is surrounded by a mostly-transparent gray shadow (like regular windows - and unlike the wry example).

Interestingly, with a frame: false window the active region is narrower and mostly inside the window (not in the shadow). It also uses different mouse-cursor for hover and drag (like non-Electron window). With frame: true the active region is outside the region (in the window shadow), a bit wider - and it uses the same mouse-cursor for hover and drag. (This applies to both electron-v13.1.3 and electron-v16.0.0-nightly.20210816.) So there seems to be some weird (gratuitous?) differences between frame and non-frame.

[amrbashir]

Yes ofc there is difference between Frameless window and Regular window.

Regular windows will let the OS window manager handle the title bar and resizing handlers which is most of times outside the window itself and on the shadows, but Frameless windows take away that from the OS window manager and lets the user decide how he want to handle resizing.

With that said, The only issue I see is that On Linux, On Frameless Window, the cursor style changes back to normal arrow icon when the resize is happening.

I am gonna close this issue now but feel free to open another one for the cursor icon while resizing.