Any ideas on how to get the surface for the titlebar?

[Gonzalo Garramuño]

This is a question for ManoloFLTK and perhaps something he can transmit
to the libdecor folks as an API request(s).

Currently, libdecor seems not allow getting the (sub)surface used for
the title bar.  The Wayland Pen driver receives tool_cb_down (ie a
"touch" with the pen) for that subsurface, not a libdecor_frame or the
actual FLTK surface.  Only when the touch happens on a Fl_Widget do we
get the surface for it and all is peachy in that case.
Mapping the subsurface to a libdecor_frame therefore cannot be done.
Matt's approach was that we iterate through all windows and check
whether they are GTK decorated and assign their libdecor_frame for them
and also raise them (show them to the top of the pile). But that
approach breaks when there are multiple decorated windows, as FLTK can
deliver them in any order.  Also, there's no highlighting of the buttons
as when the mouse moves over the close/maximize/etc. buttons.
Independently from Matt's hard work, I took 3 approachs:

- First one was to make libdecor aware to tablet-v2.  That approach
failed as there can only be one tablet_manager_v2 per application.
- I then similar approach to Matt but with the cairo-plugin approach.  I
did two attempts: one with the an approach similar to Matt's which ran
into the same issues.
- As final attempt, I modified libdecor code to create a function like
libdecor_inject_* where the highlighting would work but still had the
issue of how to pick the appropriate libdecor_frame.

[melcher....@googlemail.com]

ggar...@gmail.com schrieb am Montag, 22. Juni 2026 um 21:43:42 UTC+2:

This is a question for ManoloFLTK and perhaps something he can transmit
to the libdecor folks as an API request(s).

I am very unhappy with the burning hoops that we need to jump through to may Wayland and libdecor work. I was trying to peek how Qt solves this, and it seems that the rGUI toolkit don't bother with external decoration at all, but draw (and handle) their own title bars. What a huge step backwards from X11 desktop management into the Not-Invented-Here world. At this point, I have given up on understanding the limitations and workarounds with Wayland. 

 

Matt's approach was that we iterate through all windows and check
whether they are GTK decorated and assign their libdecor_frame for them
and also raise them (show them to the top of the pile). But that
approach breaks when there are multiple decorated windows, as FLTK can
deliver them in any order. 

Well, this code is copied from elsewhere after I saw no way whatsoever to get to those sub-surfaces (or whatever they are called). The approach should work, because every Fl_X* should only have one unique wl_frame. On a side note, Fl::first_window() / next_window() sorts windows from top to bottom. So doing a mouse hit test here, should always return the topmost (and correct) window.

 

Also, there's no highlighting of the buttons
as when the mouse moves over the close/maximize/etc. buttons.

Yeah, I have not found out how that works without going into private libdecor classes.

 

- As final attempt, I modified libdecor code to create a function like
libdecor_inject_* where the highlighting would work but still had the
issue of how to pick the appropriate libdecor_frame. 

That seems to be the best approach, but doesn't work if FLTK apps link with the system libdecor instead of the packaged libdecor.

I have to ask the question why libdecor does not have pen support or injection built-in. Is that the safety aspect that ruins the ability to programmatically position windows? 

So every client app that uses lidecor by definition ignores pen events, and only the GTK variant has a rudimentary touch event handling. Since all my desktop apps (Ubuntu 26.4) work seamlessly with my tablet, either none of the use libdecor, or we are using libdecor wrong. 

Confused.

 - Matthias

[Manolo]

Here are a few points about libdecor and FLTK:

- GTK-based and Qt-based apps don't use libdecor. The titlebar of GTK apps is often richer than what libdecor produces.

- Examples of non-FLTK Wayland apps using the gnome libdecor-0-0 package are /usr/bin/eglgears_wayland, egltri_wayland, vkgears,

all from the mesa-utils package. Matthias may try them on his tablet and report whether their titlebar

responds to pen events. I would guess they don't.

- A recent PR in libdecor shows that the intention is to move all GTK-based code to a separate process;

the benefit of that being to gain the accelerated graphics features of GTK4 and allowing the client app to use GTK3

while the libdecor process uses GTK4. This would totally forbid any access to titlebar Wayland surfaces.

I don't think FLTK should engage in modifying the source code of the libdecor-gtk plugin.

We can expect libdecor plugins to handle pen events in some future just as they now handle touch events.

[Albrecht Schlosser]

On 6/23/26 15:57 Manolo wrote:
> I don't think FLTK should engage in modifying the source code of the
> libdecor-gtk plugin.

... or any other part of libdecor, IMHO. This is particularly important
since we may use the system versions (.so's) of libdecor.

> We can expect libdecor plugins to handle pen events in some future
> just as they now handle touch events.

Yes, I'd like that too. I seem to recall that touch events were added
some time ago. I hope tablet/pen events will follow.

Until that happens, FLTK might not support pen events in the title bar.
So what? Then it's libdecor's fault. As long as we can use pen events in
the client area of ​​the window, that's fine by me.

[imacarthur]

On Tuesday, 23 June 2026 at 15:46:59 UTC+1 Albrecht-S wrote:

Until that happens, FLTK might not support pen events in the title bar.
So what? Then it's libdecor's fault. As long as we can use pen events in
the client area of ​​the window, that's fine by me.

Are mouse events equivalent to the pen events delivered to the title bar, or some events that the titlebar _can_respond to?

(Or does this mean that the window can't be moved by dragging the titlebar around, for example?)

I don't know much Wayland, but I guess this is perhaps part of why the MS Windows stuff sends "the same" event in multiple flavours when the pen is used?

[melcher....@googlemail.com]

Windows and macOS send pen events first. If they are not handled by the app, the synthesize them into mouse events and send them again. A bit like FLTK sending FL_KEYBOARD events, and resending FL_SHORTCUT if the keyboard event was not used. Events on the titlebar are never sent to the app, but the results are (calling Fl_Window::resize(), for example). The titlebar is handled by the OS. However, apps can request drawing areas in the title bar for additional functionality to gain some usable space.

Wayland itself does not handle titlebars and resize areas at all (if I understood that correctly). Wayland just provides surfaces. What they do is up to the application. Some GUI libraries generate their own title bars and resize areas, so if your GUI library does not care about pen and touch, you can't move, resize, or close such an app on your desktop that way. Users *must* use the mouse. FLTK doesn't draw its own decoration, but uses a copy of libdecor (similar to a copy of libpng, libjpeg, and libz). So libdecor is CSD, Client Side Decoration.

An alternative is SSD, server side decoration, using for example the xdg-decoration protocol. In its infinite wisdom, Wayland does not *require* as SSD, so there are compositors out there that don't *have* SSD, because of course there are.

So one alternative to libdecor would be to request xdc-decoration, and if that fails, draw our own title bar using FLTK widgets. If I understood this correctly.

[Gonzalo Garramuño]

On 6/23/26 12:57, Manolo Gouy wrote:
> That could occur if you link mrv2 to a version of libfltk built with FLTK_USE_SYSTEM_LIBDECOR=0 and FLTK_USE_LIBDECOR_GTK=0
Why would that be a bad idea?  If I use FLTK_USE_LIBDECOR_GTK=ON, I used
to run into the problem that GTK3 seemed to use libpng for its icons and
when distributing my application to different versions of the OS there
would be conflicts, depending on what version of libpng they used.
> (which would be a bad idea) and have environment variable LIBDECOR_FORCE_CSD defined.
Yes!  That was the silly error on my part on my environment.sh file. 
Thank you, Manolo!

[Manolo]

All this is absolutely correct, but to the risk of being pedantic I would like to add a few minor details.

FLTK by default and on recent Linux versions doesn't use a copy of libdecor. It dynamically links to libdecor.so (which may itself link to libdecor-gtk.so, but not for all compositors). FLTK bundles a copy (100% identical) of libdecor only to remain compatible with old Linux versions without a libdecor package (or with one that's too old).

I wouldn't say "libdecor is CSD". A Wayland compositor can be SSD (Plasma for example) or CSD (Gnome for example). Wayland provides the xdg-decoration protocol for the client to determine whether the compositor it's connected to is CSD or SSD. Libdecor uses this protocol. When the compositor is CSD libdecor pulls in a plugin (2 plugins exist) to draw titlebars. When it's SSD, libdecor hasn't much to do, mostly respond to resize requests it receives from the compositor; all drawing and event handling with the titlebar is done by the compositor. FLTK uses libdecor. When an FLTK app runs under Gnome, libdecor draws titlebars and responds to mouse and touch events there, but not (yet?) to pen events on the bar.

The very same FLTK app run under Plasma gets Plasma-drawn titlebars, and I'm told it responds to mouse, touch and pen events (because that's done neither by FLTK nor by libdecor).