Re: [fltk.coredev] Towards a Wayland platform for the FLTK library ? - Forums

Le lundi 7 juin 2021 à 22:02:00 UTC+2, spi...@gmail.com a écrit :

Read through the libdecor code and it appears to be drawing everything directly. There is a "plugin", perhaps with the intention that the style of the window borders can change by changing the plugin, but I don't agree with this as the api to the plugin is going to swiftly grow to a baroque monstrosity, just like every other attempt to control the borders. There was a good reason Wayland wanted CSD. I personally do not see any problem with drawing the window borders ourselves, any complaint that they look different is IMHO not logical if the difference in appearance of every other widget is considered acceptable. Also not using this library will mean a single Wayland surface can be used, instead of two.

Here's an investigation with gdb on program test/hello searching for what context calls static function draw_title_text()

from libdecor's src/plugin/cairo/libdecor-cairo.c which draws the text of window titlebars :

1) When a window is first created, libfltk code calls libdecor code which draws the window title :

2) Each time the window is deactivated or activated, its titlebar gets redrawn.
This is done by libfltk calling libwayland-client.so which calls libffi.so (what is it?)

which calls libdecor-0.1.so to draw the title :

#0 0x00007ffff7d3039f in draw_title_text ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#1 0x00007ffff7d30c25 in draw_component_content ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#2 0x00007ffff7d319c0 in draw_border_component ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#3 0x00007ffff7d31b89 in draw_title_bar ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#4 0x00007ffff7d31c5d in draw_decoration ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#5 0x00007ffff7d32d72 in synthesize_pointer_enter ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#6 0x00007ffff7d32ecf in pointer_enter ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#7 0x00007ffff7374d1d in () at /lib/x86_64-linux-gnu/libffi.so.7
#8 0x00007ffff7374289 in () at /lib/x86_64-linux-gnu/libffi.so.7
#9 0x00007ffff7db22d2 in () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#10 0x00007ffff7dae97a in () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#11 0x00007ffff7db003c in wl_display_dispatch_queue_pending ()
    at /lib/x86_64-linux-gnu/libwayland-client.so.0
#12 0x0000000000436940 in fd_callback(int, wl_display*)
    (unused=3, display=0x4b45f0)
    at drivers/Wayland/Fl_Wayland_Screen_Driver.cxx:925
#13 0x000000000044148c in Fl_Wayland_Screen_Driver::poll_or_select_with_delay(double) (this=0x4b43a0, time_to_wait=1e+20) at drivers/Wayland/Fl_wayland.cxx:225
#14 0x00000000004371cc in Fl_Wayland_Screen_Driver::wait(double)
    (this=0x4b43a0, time_to_wait=1e+20)
    at drivers/Wayland/Fl_Wayland_Screen_Driver.cxx:1146
#15 0x0000000000407aa6 in Fl::wait(double) (time_to_wait=1e+20) at Fl.cxx:449
#16 0x0000000000407ad3 in Fl::run() () at Fl.cxx:469

This, I interpret as showing that a shared library plugin is necessary for libdecor. Am I wrong?

FLTK could stop pulling in future libdecor updates when we would feel it's becoming

'a baroque monstrosity'.

I understand that FLTK could do CSD drawing a custom titlebar in the same surface as the window main area.

I see this path has not been followed by libdecor. May be it's because libdecor wants to be compatible

with desktops (and I believe KDE is one) that provide server-side decoration (SSD).