[app,io] Feature/make decoration size available to consumer

[tauraamui]

At present it is not possible without using this unintentional/unsupported "feature" of gio initially sending the full non-decorated window size in the first config event, which might "break" or is not defined as intended behavior (actually it does seem like a bug in itself) and it would be preferable to just simply make the size of the decoration available in a supported and explicit fashion.

Signed-off-by: tauraamui adampstringer@protonmail.com

[eliasnaur]

actually it does seem like a bug in itself

Thanks, but I'd like to see the first-frame bug fixed first, then evaluate the need for DecorationSize afterwards. Can you raise an issue on the tracker with OS and a small demonstration program? An outright fix for the issue would be even more ideal, of course.

[tauraamui]

actually it does seem like a bug in itself

Thanks, but I'd like to see the first-frame bug fixed first, then evaluate the need for DecorationSize afterwards. Can you raise an issue on the tracker with OS and a small demonstration program? An outright fix for the issue would be even more ideal, of course.

So I recognise that my initial description based explanation of this PR and its purpose is unclear due to poor wording. My apologies. Basically without the changes within this PR, it is otherwise possible, (via the first frame bug (I will raise an issue for that separately)) to acquire the size of the window's decoration upon application start.

However, as that possibility relies on the bug's existence, I would prefer to just access the decoration's size directly. If anything therefore I think I personally would appreciate this being merged first, as my use-case would no longer have any method of acquiring that information if the bug is fixed beforehand. Would you like me to explain my use-case for wanting this field?

[whereswaldon]

Would you like me to explain my use-case for wanting this field?

@tauraamui Yes, we prefer only to consider features with a stated use-case.

[tauraamui]

Would you like me to explain my use-case for wanting this field?

@tauraamui Yes, we prefer only to consider features with a stated use-case.

Fair enough. When you acquire the cursor's position, it gives it in window space (relative to the window not the screen), which is fine, and great. However, it does not account for the height of the decoration in the same way that the window's content rendering is offset to be below the decoration bar.

I have an application which uses the concept of an "infinite" canvas. To be able to interact with elements on/within the canvas, we take the pointer's position and convert it from window space into canvas space. In the included image example below:

there's a "textbox" within an A4 page representation on the canvas which can be dragged around, but only if the cursor is within the bounds of it whilst dragging. Without taking into account and manually offsetting by the decoration's height, the cursor position whilst visually in the correct position, is actually worked out to be higher (the faded out pointer's position). This is not a bug or issue within the window to canvas conversion, but the initial provided pointer's position is just wrong technically. I am not using the immediate mode style area of concern + tag registration aspect of dealing with user input within a defined area, as it makes having an "infinite" canvas space with movable entities much more complicated.

For example, register the text box's event capturing to be it's bounds, but then when you drag within this area, you move the area of concern with it, additionally sometimes the cursor does escape the bounds of the AOC whilst dragging for a fraction, and then the dragging will randomly halt for no visible reason.

[whereswaldon]

@tauraamui Firstly, looks like a cool application! May I ask what it's for? Always interested to know what people are building with Gio.

More topically, it seems to me that your problem would be solved if Gio returned pointer coordinates that were exclusively within the non-automatic-decoration region of the window. This seems like a bug to me. Given that Gio only recently gained support for automatic client-side decorations on Wayland, I suspect we've got a bug left over from those changes.

My preferred way to resolve this would be:

• fix the bug in app.ConfigEvent so that the first event correctly reports only the non-decoration size of the window (unless the window is configured explicitly to draw its own decorations as part of Gio layout).
• fix the bug in the top-level Gio event routing that is including the dimensions of the decorations in the event coordinates (this is only correct when the window is configured to manually draw its own decorations).

The result would be that you no longer need to know the size of decorations, because the input coordinates are already in the proper coordinate space.

@eliasnaur Please correct me if I've said anything inaccurate.

@tauraamui The best way to move this forward would be:

• a small demo program posted on https://todo.sr.ht/~eliasnaur/gio demonstrating the problems
• patches fixing one or both bugs, if you're interested in helping to address this

[tauraamui]

@tauraamui Firstly, looks like a cool application! May I ask what it's for? Always interested to know what people are building with Gio.

Thanks. It is an attempt to create a PDF viewer and editor, where editing of PDF content is made as simple and powerful as possible, by doing things like character recognition (so converting "stream"/image stored text content into actual editable text etc.,) as most crappy PDF editors just store vector text as bitmaps making them undetectable as text. I can also see the opportunity to re-implement a "painting" application with a fresh approach, stuff like using Gio's clipping functionality for example to be able to paint all over the canvas (outside the page bounds), but when you "export" or "print" equivalent it clips to only include the stuff within the A4 bounds.

More topically, it seems to me that your problem would be solved if Gio returned pointer coordinates that were exclusively within the non-automatic-decoration region of the window. This seems like a bug to me. Given that Gio only recently gained support for automatic client-side decorations on Wayland, I suspect we've got a bug left over from those changes.

I have been using Google's Pixelbook Go device, with their Linux dev VM as my primary and preferred development environment so far. I only provided the screenshot today from macOS as an exception. The bug applies both on macOS and X11 as far as I can tell. However I have noticed that some features which I was reading about in Gio's sauce 🥫 like forced "re-animate" or something when the window crosses into a different display completely breaks my application, something which does not occur on the PG' Linux VM. That dev environment might be quite an interesting case study btw, as there are a lot of hardware based limitations/protections that prevent the Linux VM having much insight into what is happening on the host device.

fix the bug in the top-level Gio event routing that is including the dimensions of the decorations in the event coordinates (this is only correct when the window is configured to manually draw its own decorations).

If we do fix the pointer position coming back with the decoration height being ignored, isn't that going to break widgets, and/or entities which do register to receive input events within an area of concern + tag though?

fix the bug in app.ConfigEvent so that the first event correctly reports only the non-decoration size of the window (unless the window is configured explicitly to draw its own decorations as part of Gio layout).

Actually the bug is that the first ConfigEvent returns the full window size without the decoration height applied, whereas each subsequent event does, doing a sub on these is how I currently work out the decoration height.

[whereswaldon]

@tauraamui I'm sorry that this has just been sitting around forever. I've just tried to reread the conversation to recontextualize myself. It still seems like the best fix is to ensure that ConfigEvent never sends a window size containing the space of system- or Gio-provided window decorations. If you set app.Decorated(false) then it will of course just tell you the size of the window rectangle. I don't think that I understand your previous concern about breaking event routing.