Labwc misplaces titlebar on small window

[jjramsey]

Here's what it looks like:

Unfortunately, the titlebar doesn't have a place where a pointer can hold and drag to move the window (but Alt-click-drag still works).

This window is from Workrave.

[Consolatis]

Is this an X11 or a wayland native window? ([xdg-shell] or [xwayland] when pressing A-Tab.)

[01micko]

It runs under Xwayland - I just tested it out, same as above screencap.

Edit to add:

mick@dellhome:~$ grep "^Exec" /usr/share/applications/workrave.desktop 
Exec=/usr/bin/env GDK_BACKEND=x11 workrave

Throws a segfault when calling directly, so hard to capture a log.. suggestions?

[droc12345]

You might try running from a terminal, "env GDK_BACKEND=x11 workrave" to see if more messages show or perhaps a clue why it segfaults.

[tokyo4j]

I could't reproduce this, but this weird behavior is expected. We are restricting the window geometry in "configure" events, but not restricting the geometry the client submits. And if the submitted geometry is smaller than minimal values, SSD is not updated (introduced with #1762), so SSD remains in the weird look like in the picture. We need more sophisticated solution for this.

[droc12345]

tokyo4j , I have a question, that this brings up. When we provide ssd, is that bolted onto the app or is all of it in container?

Much of this would be easier to fix if the window and the ssd were treated as one object, ie a container has both window and ssd.

The reason I wondered about this is I'm looking at possibly adding opacity to windows and don't really want to try and handle ssd separate from window, much better to treat them as a whole, before sending to output.

[tokyo4j]

When we provide ssd, is that bolted onto the app or is all of it in container?

With the scene-graph API, we have view->scene_tree for every window and it contains view->scene_node and view->ssd as children. view->scene_node represents the tree for surfaces drawn by the app and view->ssd represents tree for all ssd components like buttons, borders, titlebars, drop-shadows, and extent for resize handle. The surface geometry and ssd geometry are mostly synced in view_moved() when the app commits its geometry, but in this issue I guess it's not because ssd rejects to be resized to very small values. (Note that I'm not expert about ssd.)

The reason I wondered about this is I'm looking at possibly adding opacity to windows and don't really want to try and handle ssd separate from window, much better to treat them as a whole, before sending to output.

I think sway handles this well. To apply opacity for a container, it traverses the child nodes of the container tree and calls wlr_scene_buffer_set_opacity() for each buffer nodes. If we apply the same thing for labwc, we can traverse the child nodes of view->scene_tree.

[jjramsey]

Is this an X11 or a wayland native window? ([xdg-shell] or [xwayland] when pressing A-Tab.)

Wayland native. This is the latest beta of Workrave (and requires passing -DHAVE_WAYLAND:BOOL=TRUE to its cmake configure line to build on Wayland properly).

[tokyo4j]

Wayland native. This is the latest beta of Workrave (and requires passing -DHAVE_WAYLAND:BOOL=TRUE to its cmake configure line to build on Wayland properly).

I reproduced the issue by following your guide.

Here is the PKGBUILD for it.

EDIT: And as I expected, this is caused by workrave committing window geometry smaller than minimal values and labwc refuses applying the geometry for SSD.

If we revert #1762, ssd for workrave looks better, but buttons overlap and I see an error below on my Arch setup, which is why I made #1762.

*** BUG ***
In pixman_region32_union_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

I guess we can allow buttons to overlap and prevent negative values for each call to wlr_scene_rect_set_size(), rather than just refusing to resize ssd.

[jjramsey]

Is there any reason why you wouldn't simply want to expand the Workrave window to accommodate the decorations?

[tokyo4j]

Is there any reason why you wouldn't simply want to expand the Workrave window to accommodate the decorations?

It's just because workrave doesn't resize its window as labwc requests (with xdg_toplevel.configure event) for some reason. I guess Wayland support for workrave is still work-in-progress.

[jjramsey]

That's odd. When I tried Workrave under Wayfire and KDE Wayland, the window was resized enough to accommodate window decorations. Maybe Wayfire used a different request?

If Workrave isn't resizing when it should, that probably is an issue to submit to Workrave, though.

[stefonarch]

I didn't follow all but Qt has a bug now that allows ridiculous resizing, that's featherpad:

It looks like the limit is by all buttons widths summed up, with or without decoration.

[Consolatis]

It looks like the limit is by all buttons widths summed up, with or without decoration.

Correct, the without decorations part is still an open issue. This specific minimal size should only matter for windows with server side decorations. However, we likely need *some* minimal size even for windows without server side decorations because finding a 1px x 1px window without server decorations and recovering from that state seems pretty much impossible from a UX perspective.

That's odd. When I tried Workrave under Wayfire and KDE Wayland, the window was resized enough to accommodate window decorations. Maybe Wayfire used a different request?

Could also be that both just happen to have a slightly bigger minimal window size in regards to the their decorations.

[jjramsey]

Turned out Workrave was using CSD under Wayfire at the time.