Wayland libdecor-cairo plugin questions

[imacarthur]

So I have been idly poking at the "built-in" Cairo based libdecor decorator plugin - not changing anything serious, jus a little bit of "window dressing" as it were...

Now, I'm not sure how representative my testing is, since the box I'm using to test this is actually a Win11 test  with WSL2/WSLg enabled and Ubutunu-22.04 since that's the only "Linux" box I have with Wayland installed. (And my main Linux dev box already has GTK3 installed, which would get in the way of the Cairo-decorator testing, potentially, since the Cairo decorator is the "last resort" if GTK3 is not present...)

Situation: With the Cairo decorator, I'm seeing a weird effect when I go full screen. In the attached screenshots, see the Win11 desktop running my Linux instances of the "demo" and "browser" code, note the position of the "browser" window.

When I go full screen on the "browser" (second screenshot) it draws the browse OK, but then *draws the decorator drop-shadows anyway* at the position that the (non-maximized) window would have been.

This is very ugly, and I'm not quite sure why it happens... I suspect the WSLg compositor is sending misleading requests to the decorator (and hence triggering the border and drop-shadow to be drawn) but I'd like to know what folks running Wayland on a real Linux host are seeing... If this is indeed a widespread issue I can work around it, but it may just be the WSL2/WSLg setup that causes the issue, rather than the decorator plugin itself...

(For those following along at home, the Linux windows in these shots are using our built-in Cairo decorator, but with the title-bar font size corrected *was the bug I suspected, I think) and the colours changed as I was fiddling to see what did what...

[Albrecht Schlosser]

On 12/3/22 11:13 imacarthur wrote:

So I have been idly poking at the "built-in" Cairo based libdecor decorator plugin - not changing anything serious, jus a little bit of "window dressing" as it were...

Great!

Now, I'm not sure how representative my testing is, since the box I'm using to test this is actually a Win11 test  with WSL2/WSLg enabled and Ubutunu-22.04 since that's the only "Linux" box I have with Wayland installed.

OK...

(And my main Linux dev box already has GTK3 installed, which would get in the way of the Cairo-decorator testing, potentially, since the Cairo decorator is the "last resort" if GTK3 is not present...)

You can disable the GTK plugin in CMake with '-D OPTION_ALLOW_GTK_PLUGIN:BOOL=OFF' .

Situation: With the Cairo decorator, I'm seeing a weird effect when I go full screen. In the attached screenshots, see the Win11 desktop running my Linux instances of the "demo" and "browser" code, note the position of the "browser" window.

When I go full screen on the "browser" (second screenshot) it draws the browse OK, but then *draws the decorator drop-shadows anyway* at the position that the (non-maximized) window would have been.

This is very ugly, and I'm not quite sure why it happens... I suspect the WSLg compositor is sending misleading requests to the decorator (and hence triggering the border and drop-shadow to be drawn) but I'd like to know what folks running Wayland on a real Linux host are seeing... If this is indeed a widespread issue I can work around it, but it may just be the WSL2/WSLg setup that causes the issue, rather than the decorator plugin itself...

On my Gnome/Wayland desktop on Linux Mint 20 (based on Ubuntu 20.04 LTS) it's fine, no such drop shadows.

There are two points to this:

1. I remember that there were issues with fullscreen windows, maybe in libdecor, but I don't remember exactly. These issues have been fixed weeks (months?) ago and I don't know what exactly the issues were. Manolo may know more.

2. According to this image WSLg is running a Weston compositor which
    (a) is the reference compositor of Wayland but
    (b) has some known issues.
  Maybe this is one of these issues.

https://github.com/microsoft/wslg/raw/main/docs/WSLg_ArchitectureOverview.png

(For those following along at home, the Linux windows in these shots are using our built-in Cairo decorator, but with the title-bar font size corrected *was the bug I suspected, I think) and the colours changed as I was fiddling to see what did what...

Can we see a patch for testing, please? Thanks

And thank you for testing and for trying to improve the Cairo plugin. I appreciate this very much and I imagine that we can use it if the title bar drawing issues are fixed. And if it's a useful patch for upstream: Manolo had success with some PR's (in GitLab: MR's) that have been accepted upstream. The font issue appears to qualify for an upstream patch (colors maybe not, but that's not important).

[Albrecht Schlosser]

On 12/3/22 13:04 Albrecht Schlosser wrote:

On my Gnome/Wayland desktop on Linux Mint 20 (based on Ubuntu 20.04 LTS) it's fine, no such drop shadows.

There are two points to this:

1. I remember that there were issues with fullscreen windows, maybe in libdecor, but I don't remember exactly. These issues have been fixed weeks (months?) ago and I don't know what exactly the issues were. Manolo may know more.

2. According to this image WSLg is running a Weston compositor which
    (a) is the reference compositor of Wayland but
    (b) has some known issues.
  Maybe this is one of these issues.

https://github.com/microsoft/wslg/raw/main/docs/WSLg_ArchitectureOverview.png

I tried going fullscreen with the Weston compositor and it still worked fine.

To do this you can use on a Linux system with Wayland:

$ weston -S weston-0 --width=1600 --height=900

to start Weston with the socket 'weston-0' and appropriate width and height which runs under the current Wayland session.

From another terminal, start a Wayland enabled program to run under Weston, for instance

$ WAYLAND_DISPLAY=weston-0 bin/test/browser data/browser.cxx


Works well here.

[imm]

On Sat, 3 Dec 2022 at 12:21, Albrecht Schlosser wrote:
>
> I tried going fullscreen with the Weston compositor and it still worked fine.
>
> To do this you can use on a Linux system with Wayland:
>
> $ weston -S weston-0 --width=1600 --height=900
>
> to start Weston with the socket 'weston-0' and appropriate width and height which runs under the current Wayland session.
>
> From another terminal, start a Wayland enabled program to run under Weston, for instance
>
> $ WAYLAND_DISPLAY=weston-0 bin/test/browser data/browser.cxx
>
> Works well here.

OK - and this is all whilst using our built-in Cairo decorator?
Suggesting that it *can* (maybe even *does*) work in this regard and
what I'm seeing is some WSLg weirdness...

Some other points:

- If I start the test with FLTK_BACKED=x11 set, then the fullscreen
works correctly. Based on what that MS claim the WSLg system does, the
Xwayland instance will still be going via Weston compositor, so that
at least suggests that it also *can* work... (or that in that case the
WM provides the decorations and doesn't mess it up!)

- Clicking the titlebar *does not* seem to give the window the focus
properly. For example, if I click in the body of the window then hit
CTRL+ or CTRL- the window zooms in/out as expected. If I click the
titlebar then CTRL+/-, the zoom does not happen. Again, the x11 case
works fine. I'd be interested to hear whether that is peculiar to WSLg
(as the prior bug seems to be) or whether that is a feature of our
Cairo decorator.

Regards a patch, it might be easiest if I post the modified file so
far - I couldn't get on with the style of the base code so might
"accidentally" have run it through astyle to make it more readable. A
patch will show *a lot* of change where really there's very little...

There's a "one liner" change to libdecor/build/fl_libdecor-plugins.c
(attached) and a "new" file libdecor-cairo-modified.c (in zip)

[Albrecht Schlosser]

On 12/3/22 13:53 imm wrote:
> On Sat, 3 Dec 2022 at 12:21, Albrecht Schlosser wrote:
>> I tried going fullscreen with the Weston compositor and it still worked fine.

>> [...]

> OK - and this is all whilst using our built-in Cairo decorator?

Yes. See attached screenshot with your patched version of the Cairo
plugin running in my Gnome/Wayland session under Weston.

> Suggesting that it *can* (maybe even *does*) work in this regard and
> what I'm seeing is some WSLg weirdness...

I have no idea.

> Some other points:
>
> - If I start the test with FLTK_BACKED=x11 set, then the fullscreen
> works correctly. Based on what that MS claim the WSLg system does, the
> Xwayland instance will still be going via Weston compositor, so that
> at least suggests that it also *can* work... (or that in that case the
> WM provides the decorations and doesn't mess it up!)

Very likely the latter (WM provides decorations). This is certainly the
most used case and therefore likely to work whereas libdecor may not be
so well tested with Weston. Or something like that, maybe.

> - Clicking the titlebar *does not* seem to give the window the focus
> properly. For example, if I click in the body of the window then hit
> CTRL+ or CTRL- the window zooms in/out as expected. If I click the
> titlebar then CTRL+/-, the zoom does not happen. Again, the x11 case
> works fine. I'd be interested to hear whether that is peculiar to WSLg
> (as the prior bug seems to be) or whether that is a feature of our
> Cairo decorator.

Works fine here (using Weston and clicking on the titlebar), same as
with the "normal" Wayland desktop session.

> Regards a patch, it might be easiest if I post the modified file so
> far - I couldn't get on with the style of the base code so might
> "accidentally" have run it through astyle to make it more readable. A
> patch will show *a lot* of change where really there's very little...
>
> There's a "one liner" change to libdecor/build/fl_libdecor-plugins.c
> (attached) and a "new" file libdecor-cairo-modified.c (in zip)

Thanks, I copied your file and applied the patch. After disabling the
GTK plugin it uses the modified plugin as can be seen in the screenshot
(modified colours).

[Albrecht Schlosser]

On 12/3/22 17:15 Albrecht Schlosser wrote:
> ... I copied your file and applied the patch. After disabling the GTK

> plugin it uses the modified plugin as can be seen in the screenshot
> (modified colours).

... and better looking font (size), of course. Awesome.

[Albrecht Schlosser]

On 12/3/22 17:15 Albrecht Schlosser wrote:

FWIW, for other users: I made a patch of the "original" Cairo plugin
(attached). It is enough to apply this patch and recompile.

Some notes:

1) changed titlebar color, comment: /* FLTK (TEST only); are there
"better" colors? */

2) changed 'libdecor_cairo_proxy_tag', comment /* FLTK - optional */

3) patched "case SHADOW" as given by Ian:
    looks useful *NOT* to draw drop shadows if the window is maximized,
comment: /* FLTK - Fix (?) */

4) patched 'pango_font_description_set_absolute_size', comment: /* FLTK
- Fix ! */

5) patched "priority" as given by Ian, comment: /* FLTK - optional */


Regarding (3): would likely be useful upstream.

Regarding (4): *should* be patched upstream.

Regarding (1, 2, 5): probably not useful upstream.

The only mandatory part of the patch would IMHO be point (4) above which
fixes the annoying titlebar font size and should be proposed to libdecor
maintainers (MR).

Looking forward to others' test result and Manolo's comments. TIA.

[Albrecht Schlosser]

On 12/3/22 22:33 Albrecht Schlosser wrote:
>
> FWIW, for other users: I made a patch of the "original" Cairo plugin
> (attached). It is enough to apply this patch and recompile.

Oops, missing patch, attached here, sorry.

[imm]

On Sat, 3 Dec 2022, 21:33 Albrecht Schlosser wrote:

On 12/3/22 17:15 Albrecht Schlosser wrote:
> On 12/3/22 13:53 imm wrote:
>> Regards a patch, it might be easiest if I post the modified file so
>> far - I couldn't get on with the style of the base code so might
>> "accidentally" have run it through astyle to make it more readable. A
>> patch will show *a lot* of change where really there's very little...
>>
>> There's a "one liner" change to libdecor/build/fl_libdecor-plugins.c
>> (attached) and a "new" file libdecor-cairo-modified.c (in zip)
>
> Thanks, I copied your file and applied the patch. After disabling the
> GTK plugin it uses the modified plugin as can be seen in the
> screenshot (modified colours).

FWIW, for other users: I made a patch of the "original" Cairo plugin
(attached). It is enough to apply this patch and recompile.

Some notes:

1) changed titlebar color, comment: /* FLTK (TEST only); are there
"better" colors? */

TBH I changed this mainly so I could tell if it was my version that was running...

I'd like to be able to load the system colours, but don't know how to do that.

I like my titlebar colour better than stock...

2) changed 'libdecor_cairo_proxy_tag', comment /* FLTK - optional */

We probably want this in our built-in, but no one else needs this.

3) patched "case SHADOW" as given by Ian:
     looks useful *NOT* to draw drop shadows if the window is maximized,
comment: /* FLTK - Fix (?) */

I'm cautious about this; a feature of the plugin is that it uses the logic that computes the shadow region to also detect the grabbable borders, e.g. for resizing the window.

So if we always suppress the shadow, it then means we can't resize the window by grabbing an edge...

That said, maximized or tiled windows should not have drop shadows (and can't be resized by dragging) but under WSLg they do get shadows. I'm pretty sure that's a bug in WSLg though... Maybe...

I need to do a lot more tests on a real Linux to see what's happening here, but I think the plugin may be "OK" as it was.

4) patched 'pango_font_description_set_absolute_size', comment: /* FLTK
- Fix ! */

I think this is the only definitely useful change I've made 

5) patched "priority" as given by Ian, comment: /* FLTK - optional */

This is useful for our built-in decorator, just so it takes priority over a stock Cairo decorator. Probably not useful for upstream though.

Regarding (3): would likely be useful upstream.

Not sure; this shouldn't be happening anyway...

Regarding (4): *should* be patched upstream.

OK

Regarding (1, 2, 5): probably not useful upstream.

OK

The only mandatory part of the patch would IMHO be point (4) above which
fixes the annoying titlebar font size and should be proposed to libdecor
maintainers (MR).

Looking forward to others' test result and Manolo's comments. TIA.

In later testing I've been seeing some other odd behaviours, with the plugin getting "unexpected" window states sent from the WSLg system. I need to test elsewhere, but I suspect it's not the plugin that's faulty here.

In particular, weird effects where the titlebar has disappeared, and where the main,max, close buttons are not getting set to the correct colour, or are changing colour at the wrong time. 

Also inactive windows aren't being drawn in the inactive colours at all (or maybe very rarely) which again looks like a WSLg bug.

--
Ian
From my Fairphone FP3
  

[Albrecht Schlosser]

On 12/4/22 11:53 imm wrote:

On Sat, 3 Dec 2022, 21:33 Albrecht Schlosser wrote:

FWIW, for other users: I made a patch of the "original" Cairo plugin
(attached). It is enough to apply this patch and recompile.

Some notes:

To make clear what I did an intended: I used your (Ian's) complete file and removed all "(a)style" related changes. I used everything that would change the code for a potential patch.

This includes "private" (FLTK) changes and potential upstream fixes. This was only meant to be used by FLTK devs for testing w/o all the confusing whitespace (including tabs) and '{' ... '}' changes which wouldn't have a chance to be accepted upstream.

In short words: make a minimal patch that includes all changes done by Ian for further testing.

1) changed titlebar color, comment: /* FLTK (TEST only); are there
"better" colors? */

TBH I changed this mainly so I could tell if it was my version that was running...

I'd like to be able to load the system colours, but don't know how to do that.

I like my titlebar colour better than stock...

I like probably all colors better than the stock black (even if it's not exactly black). But anyway, not meant for upstream.

2) changed 'libdecor_cairo_proxy_tag', comment /* FLTK - optional */

We probably want this in our built-in, but no one else needs this.

Yes, maybe, that's why I marked it "optional".

3) patched "case SHADOW" as given by Ian:
     looks useful *NOT* to draw drop shadows if the window is maximized,
comment: /* FLTK - Fix (?) */

I'm cautious about this; a feature of the plugin is that it uses the logic that computes the shadow region to also detect the grabbable borders, e.g. for resizing the window.

So if we always suppress the shadow, it then means we can't resize the window by grabbing an edge...

That said, maximized or tiled windows should not have drop shadows (and can't be resized by dragging) but under WSLg they do get shadows. I'm pretty sure that's a bug in WSLg though... Maybe...

Note that I removed your extra macro SUPPRESS_DROP_SHADOWS and used only the resulting code as if it was not defined in your modified version. The only remaining change is:

-		if (frame_cairo->decoration_type != DECORATION_TYPE_TILED)
+		if (frame_cairo->decoration_type != DECORATION_TYPE_TILED &&
+		    frame_cairo->decoration_type != DECORATION_TYPE_MAXIMIZED) /* FLTK - Fix (?) */

i.e. the condition '!= DECORATION_TYPE_MAXIMIZED' which could make sense since, as you wrote above, "maximized or tiled windows should not have drop shadows".

The only modification would not call render_shadow() if maximized. I don't see how this would change the edge detection, but I can be wrong. In my case there's no edge that can be dragged in fullscreen mode. This may be different in WSL though.

Again, I left this in the patch for further testing and evaluation.

I need to do a lot more tests on a real Linux to see what's happening here, but I think the plugin may be "OK" as it was.

4) patched 'pango_font_description_set_absolute_size', comment: /* FLTK
- Fix ! */

I think this is the only definitely useful change I've made

Yep, I agree, see my previous comment.

5) patched "priority" as given by Ian, comment: /* FLTK - optional */

This is useful for our built-in decorator, just so it takes priority over a stock Cairo decorator. Probably not useful for upstream though.

Regarding (3): would likely be useful upstream.

Not sure; this shouldn't be happening anyway...

Hmm, if 'case SHADOW:' wouldn't apply anyway while the window is maximized, then I agree that this part of the patch is useless. I didn't investigate this but left this change in the patch for evaluation.

Regarding (4): *should* be patched upstream.

OK

Regarding (1, 2, 5): probably not useful upstream.

OK

In later testing I've been seeing some other odd behaviours, with the plugin getting "unexpected" window states sent from the WSLg system. I need to test elsewhere, but I suspect it's not the plugin that's faulty here.

In particular, weird effects where the titlebar has disappeared, and where the main,max, close buttons are not getting set to the correct colour, or are changing colour at the wrong time. 

Also inactive windows aren't being drawn in the inactive colours at all (or maybe very rarely) which again looks like a WSLg bug.

Such effects are probably worth testing, but we have three components that must work together:

1) The Wayland compositor, i.e. on Debian/Ubuntu usually 'mutter' (AFAICT) and in WSL obviously 'weston'.
2) The (Cairo) plugin
3) WSL/WSLg if that matters at all

I remember that Manolo found different behavior depending on the used compositor(s), particularly some bugs - or at least unexpected behavior - in weston vs. other compositor. I believe some of these bugs didn't exist in newer versions.

Can you find out which Weston version is on your WSL system?

[imm]

On Sun, 4 Dec 2022 at 16:43, Albrecht Schlosser wrote:
>
> To make clear what I did an intended: I used your (Ian's) complete file and removed all "(a)style" related changes. I used everything that would change the code for a potential patch.
>

Yes - I'm sorry about that: there was a lot of changes (like
"correcting" the white-space and adding {braces} around one-liners and
so on, that didn't alter the function at all, but were simply my OCD
coming into play.
FWIW, the latest version (attached below) will be even worse in this regard...

Anyway, I got Wayland going on my old Dell XPS-13 with Ubuntu 20.04
and did a range of tests. I assume the active compositor was mutter.

FWIW, pretty much everything worked properly - the peculiarities I was
struggling with yesterday all now appear to be WSLg artefacts and not
real problems at all.
I still need to do testing on this XPS laptop forcing Weston rather
than mutter, but that I haven't done yet.

> This includes "private" (FLTK) changes and potential upstream fixes. This was only meant to be used by FLTK devs for testing w/o all the confusing whitespace (including tabs) and '{' ... '}' changes which wouldn't have a chance to be accepted upstream.
>
> In short words: make a minimal patch that includes all changes done by Ian for further testing.

Which is more useful than what I generated, which has a lot of non-changes...
If we decide to keep a fltk-specific version, I vote for mine, as it's
tidier and better commented; but I doubt they'd accept my cosmetic
changes upstream.

>> 3) patched "case SHADOW" as given by Ian:
>> looks useful *NOT* to draw drop shadows if the window is maximized,
>> comment: /* FLTK - Fix (?) */
>
> I'm cautious about this; a feature of the plugin is that it uses the logic that computes the shadow region to also detect the grabbable borders, e.g. for resizing the window.
> So if we always suppress the shadow, it then means we can't resize the window by grabbing an edge...

I was not clear enough here: What I meant was that if we enabled my
SUPPRESS macro at compile time, and suppress ALL drop-shadows, then
the grab borders are also removed making the windows not-sizeable. We
shouldn't do that.

>
> That said, maximized or tiled windows should not have drop shadows (and can't be resized by dragging) but under WSLg they do get shadows. I'm pretty sure that's a bug in WSLg though... Maybe...
>

> Note that I removed your extra macro SUPPRESS_DROP_SHADOWS and used only the resulting code as if it was not defined in your modified version. The only remaining change is:
>
> - if (frame_cairo->decoration_type != DECORATION_TYPE_TILED)
> + if (frame_cairo->decoration_type != DECORATION_TYPE_TILED &&
> + frame_cairo->decoration_type != DECORATION_TYPE_MAXIMIZED) /* FLTK - Fix (?) */
>
> i.e. the condition '!= DECORATION_TYPE_MAXIMIZED' which could make sense since, as you wrote above, "maximized or tiled windows should not have drop shadows".

We should not ever get the SHADOW event sent to a maximized or tiled
window, but under WSLg we do, causing the bug I observed.
Under mutter/Ubuntu, this Does Not Happen, so the guard I added never
comes into play.

Under WSLg, the guard I added doesn't even work 100%, as the SHADOW
event is often received with the window frame NOT tagged as maximised,
so the drop shadow is still drawn, despite the window clearly being
maximized on screen... There doesn't seem to be anything we can do
about that in the plugin either, it is a "system" issue.
I have NOT been able to make this fail under mutter, so I think this
is either a Weston or WSLg bug.

> The only modification would not call render_shadow() if maximized. I don't see how this would change the edge detection, but I can be wrong. In my case there's no edge that can be dragged in fullscreen mode. This may be different in WSL though.
>

Yes - I was not clear in my earlier post: If we entirely disable
drop-shadows, that breaks the border grab too, which is bad. But we do
not have to do that as the drop-shadow bug seems ot be WSLg, not
something we can work around easily (or even need to...)

> In later testing I've been seeing some other odd behaviours, with the plugin getting "unexpected" window states sent from the WSLg system. I need to test elsewhere, but I suspect it's not the plugin that's faulty here.
>
> In particular, weird effects where the titlebar has disappeared, and where the main,max, close buttons are not getting set to the correct colour, or are changing colour at the wrong time.
>
> Also inactive windows aren't being drawn in the inactive colours at all (or maybe very rarely) which again looks like a WSLg bug.
>

I can not reproduce *any* of these failing behaviours on my
Ubuntu/mutter set-up, so I think they must be WSLg (or maybe Weston)
features...
That being so, we should not try to fix them here, they need to be
fixed upstream.

> Can you find out which Weston version is on your WSL system?

Will try, but don't have the necessary here just now.

[imm]

Hmm, initial testing with Weston on Ubuntu, and the drop-shadows issue
is not visible (which is good) but the title bar buttons are not
showing their mouseover colours, and the titlebar does not change
colour when the window is inactive, so at least some of the
misbehaviour I see with WSLg appear to be Weston bugs.

That said, the loss of the mouseover colours and inactive title bar
colour do not affect the usability too much, so it is still usable,
just not quite what it ought to be.
The only serious misfeature is the spurious drop-shadows, and that
appears to be peculiar to the WSLg environment, so not something we
can (or should) fix!

[imacarthur]

I did some further testing on my Ubutnu XPS laptop, with both mutter and weston used as the compositor.

The upshot is that, other then the titlebar font adjustment, *no* other change is *needed* to the cairo decorator, it works pretty well. 

Under mutter, it works fully (as best I can determine) and under weston, it works "well enough". 

Under weston, some features of the decorator (e.g. mouseover colours on the titlebar buttons, inactive window titlebar colours) do not seem to work right, but the difficulties seem to be cosmetic, the actual operation of the window system seems fine.

Under WSL/WSLg I see lots more issues - some of which are manifestations of the weston issues noted, but others seem more serious; this may be because WSLg uses an older version of weston, or may be because WSLg itself is flawed.

The only change that we would "need" to upstream, then, is the proposed titlebar font amendment, none of my other changes appear useful here.

[Albrecht Schlosser]

On 12/5/22 10:39 imacarthur wrote:
> I did some further testing on my Ubutnu XPS laptop, with both mutter
> and weston used as the compositor.
>
> The upshot is that, other then the titlebar font adjustment, *no*
> other change is *needed* to the cairo decorator, it works pretty well.

> ...

> The only change that we would "need" to upstream, then, is the
> proposed titlebar font amendment, none of my other changes appear
> useful here.

That's great findings, thanks for testing.

Ian, would you like to create a GitLab "MR" for libdecor yourself?

If not: Manolo, since you already succeeded in pushing MR's, could you
do it again?

Any volunteers to create a GitLab MR for libdecor/Cairo-plugin?

...

Whatever we do, I propose to use this one-line patch in our bundled
Cairo plugin until it's hopefully fixed upstream. This would make the
Cairo plugin look much better (kinda "normal") and users wouldn't need
to install gtk development files.

See attached patch 'cairo-plugin-fontsize.patch'.


+1 for the patch

[imacarthur]

On Monday, 5 December 2022 at 13:08:55 UTC Albrecht Schlosser wrote:

Ian, would you like to create a GitLab "MR" for libdecor yourself?

I'll take a look, but I don't think I've an account for GitLab and I've certainly never used their tools, so it might take me a while!

If not: Manolo, since you already succeeded in pushing MR's, could you
do it again?

Any volunteers to create a GitLab MR for libdecor/Cairo-plugin?

...

Whatever we do, I propose to use this one-line patch in our bundled
Cairo plugin until it's hopefully fixed upstream. This would make the
Cairo plugin look much better (kinda "normal") and users wouldn't need
to install gtk development files.

See attached patch 'cairo-plugin-fontsize.patch'.


+1 for the patch

Or as an alternative, we just ship a patched (and renamed) version alongside the stock version - it doesn't seem to change much so maintaining a distinct copy might not be that onerous.

We pull this file in via our fl_libdecor-plugins.c wrapper anyway, so we can call it anything we like. 

Also, probably, in the short term folks that have gtk3 installed will get the "other" built-in decorator anyway, though I do wonder if we should drop that. 

I'm not keen on us effectively "hard-coding" in a dependency on gtk3 just to support a fallback decorator... 

If I build fltk on a host that has gtk3, but subsequently try to run the code on a target machine that does not have gtk3, and it has no other decorator available (quite likely in the short term, I think) then the built-in decorator may fail.

If we only ever ship a Cairo based decorator as our fall-back, then that "has to" work, since it only needs elements that fltk itself would need on that target (i.e. Cairo)

[Bill Spitzak]

I think FLTK should only include the patched fallback cairo version. Somebody should confirm that if a desktop has installed it's own plugin the fltk programs use that one instead of the fallback.

It also sounds like it uses strange colors, it probably should be patched to only use gray and black, with one of the grays being identical to the default gray FLTK uses.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/a20182b1-6a48-4d0f-be37-21b41f93afc2n%40googlegroups.com.

[Manolo]

Le lundi 5 décembre 2022 à 15:15:57 UTC+1, imacarthur a écrit :

On Monday, 5 December 2022 at 13:08:55 UTC Albrecht Schlosser wrote:

Ian, would you like to create a GitLab "MR" for libdecor yourself?

I'll take a look, but I don't think I've an account for GitLab and I've certainly never used their tools, so it might take me a while!

No gitlab account is needed,  because gitlab allows to login using one's github account.

 

[Manolo]

Le lundi 5 décembre 2022 à 18:50:03 UTC+1, Bill a écrit :

I think FLTK should only include the patched fallback cairo version. Somebody should confirm that if a desktop has installed it's own plugin the fltk programs use that one instead of the fallback.

I confirm. But, again, only the cairo plugin is part of any Linux package as of today, and only in recent Linux versions.

[imacarthur]

So, just to summarize (for my own benefit, really!):  

We are thinking that for the built-in decorator, we should use a (possibly slightly modified) version of the Cairo decorator. The gtk3 decorator {can | should | must} be dropped because it may cause a hard dependency on GTK3, which we do not want in our fall-back code. (This is a simple change to our file "fl_libdecor-plugins.c" to drop the GTK3 option and affects no other code.)

IF the system provides a decorator, we expect that this will be used at runtime in preference to our built-in. 

We expect that, at that point, IF the system offers the GTK3 decorator as an option, it may be used (since it sets a higher selection priority than the stock Cairo decorator plugin.) Also, Manolo reports that most systems that offer a decorator plugin at all, seem to only have the Cairo decorator at present.

For our built-in decorator, we derive from the Cairo decorator, but (at least in the short term) we apply the title bar font size correction (until we get the fix upstreamed...)

Beyond these items, there are some changes that may be more contentious:

We might also consider fixing the colour scheme for our built-in decorator, to make it more "neutral" in appearance?

For those who have not seen it in action, under mutter (where the Cairo decorator plugin works "fully") the colour scheme works roughly as follows:

An active window has a very dark grey (almost black) title bar, with (almost) white text. The min, max, close buttons are also this colour, but on mouseover they "light up" yellow, green, red respectively.

An inactive window is a mid grey colour, as are the buttons - on mouseover the buttons "light up" a slightly less dark grey.

This colour scheme is not terrible, it just seems a bit at odds with the norm - on my systems the active title bar is light, the inactive title bar is dark, so the colour scheme described here just seems to be "back to front" to me. 

The buttons lighting up on mouseover is OK, and somewhat consistent with other "modern" schemes, so I'm inclined to keep it... I quite like it, TBH.

Also, in my tests, under Weston (rather than mutter) I seldom see the title bar go the inactive colour, and I never see the button mouseover colours "light up", but the window decorations still function normally otherwise.

(Under WSLg is whole other story, but we can't fix that here!)

I might be inclined to adjust the default colours to be more "neutral" choices, and with a lighter colour for active vs dark for inactive windows? But that means maintaining additional deltas from upstream of course. 

Thoughts?

FWIW, there is an XDG settings option for "color-scheme" which I thought we might be able to read, under "org.freedesktop.portal.Settings" as "org.freedesktop.appearance color-scheme" but it turns out that only returns codes for "No preference", "Use dark colours" or "Use light colours" and does not actually define what those colours are, so looks to be of limited use to us here...

[Manolo]

Le mardi 6 décembre 2022 à 11:48:52 UTC+1, imacarthur a écrit :

So, just to summarize (for my own benefit, really!):  

We are thinking that for the built-in decorator, we should use a (possibly slightly modified) version of the Cairo decorator. The gtk3 decorator {can | should | must} be dropped because it may cause a hard dependency on GTK3, which we do not want in our fall-back code. (This is a simple change to our file "fl_libdecor-plugins.c" to drop the GTK3 option and affects no other code.)

IF the system provides a decorator, we expect that this will be used at runtime in preference to our built-in. 

We expect that, at that point, IF the system offers the GTK3 decorator as an option, it may be used (since it sets a higher selection priority than the stock Cairo decorator plugin.) Also, Manolo reports that most systems that offer a decorator plugin at all, seem to only have the Cairo decorator at present.

For our built-in decorator, we derive from the Cairo decorator, but (at least in the short term) we apply the title bar font size correction (until we get the fix upstreamed...)

I'm utterly against the proposal of removing the GTK libdecor plugin from the FLTK source code for the following reasons

- It does not introduce a hard dependency on GTK because this plugin is used only optionally, the default being not to

use it when package libgtk-3-dev is not present on the build system. Any developer reluctant to install package libgtk-3-dev

can build FLTK apps with the cairo plugin. Any developer willing not to use libgtk even if package libgtk-3-dev is present

on the build system can do so with "cmake -DOPTION_ALLOW_GTK_PLUGIN:Off".

- Supposing an FLTK app was built with the gtk-based plugin option set to on, the app is dynamically linked to libgtk.so

which is present in all systems recent enough to support Wayland. Package libgtk-3-dev is necessary at build time,

but not at run time.

- The GTK-based plugin has been recently included in the libdecor git repo. It will therefore be part of the next public

libdecor release and subsequently enter Linux packages. At that point, FLTK's libdecor bundle will become unneeded.

FLTK's libdecor bundle therefore exists only transiently, although it may probably survive to support Linux releases

recent enough to support Wayland but too old to contain libdecor and its plugins.

- Before supporting the Wayland platform, FLTK used X window manager-provided title bars for its apps, and this

allowed FLTK apps to inherit any desktop changes. With Wayland, the desktop draws window titlebars in some cases

(KDE) but not always (Gnome works in CSD - client-side decoration - mode). Libdecor provides the solution for apps

to inherit desktop customizations and evolutions, by its plugin mechanism.

- The GTK-based libdecor plugin uses only GTK-functions to construct and draw window titlebars. It therefore

automatically supports all customizations of the gnome desktop (e.g., buttons on left or right side) without libfltk having

to support it.

- Overall, the GTK-based plugin is the true solution for FLTK apps not to appear as aliens on the Gnome desktop

(consider that with the KDE deskop, no libdecor plugin is needed because KDE works in SSD - server-side decoration- 

mode).

- The integration of FLTK apps in the desktop is important for the future of the FLTK project.

[imacarthur]

On Tuesday, 6 December 2022 at 13:27:25 UTC Manolo wrote:

I'm utterly against the proposal of removing the GTK libdecor plugin from the FLTK source code for the following reasons

- It does not introduce a hard dependency on GTK because this plugin is used only optionally, the default being not to

use it when package libgtk-3-dev is not present on the build system. Any developer reluctant to install package libgtk-3-dev

can build FLTK apps with the cairo plugin. Any developer willing not to use libgtk even if package libgtk-3-dev is present

on the build system can do so with "cmake -DOPTION_ALLOW_GTK_PLUGIN:Off".

- Supposing an FLTK app was built with the gtk-based plugin option set to on, the app is dynamically linked to libgtk.so

which is present in all systems recent enough to support Wayland. Package libgtk-3-dev is necessary at build time,

but not at run time.

OK - but: If FLTK is built on a system that has the gtk3-dev files available (as most of mine do) this then means that fltk ONLY has the gtk plugin built-in, the Cairo decorator will not be included (our build selects one or other to build in at compile time, it is not selected at run time.)

If code built against that FLTK is then deployed on a system that does not have gtk3 at all (which is still very possible) and is run on a system that provides no other decorator (still very likely just now) then it will not work as intended and a fallback to X11 must be used. Which is OK, but not ideal.

If we *only* build in the Cairo decorator, it will work "everywhere" that fltk can work (since the default build of fltk now needs Cairo).

Any system that provides gtk3 and also provides a client-side decorator will use that anyway, rather than our built-in, and I assume that at some point (hopefully fairly soon) that will be the default and our built-in decorator will become rarely used. Our built-in decorator is only intended as a last-resort, not at the "best option". 

So on that basis I do not think we should strive to make it too gnome-compatible; any desktop distro that strives for gnome compatibility will presumably provide a gtk-client-side decorator and that is what will be used at runtime, rather than our built-in. (Or they might even switch to server-side decoration like KDE and save us all the hassle!)

I think that our built-in is very much the "decorator of last resort", and on that basis we should make it have as few other dependencies as possible.

Or I may be missing the point.

[Manolo]

My angle of view is to put FLTK 1.4 in the best possible situation for acceptance of its new Wayland/X11 hybrid platform by current and prospective users. Therefore, why not arranging for it to appear as it will do when the next release of libdecor will have made its way into a linux package? Why present it as an alien app relatively to the gnome desktop when we know how to do better ?

Furthermore, I'm skeptic about the existence of any linux system with Wayland and Pango and Cairo required by FLTK independently of what draws titlebars and without the GTK shared libraries.

[Albrecht Schlosser]

On 12/6/22 15:28 imacarthur wrote:

On Tuesday, 6 December 2022 at 13:27:25 UTC Manolo wrote:

I'm utterly against the proposal of removing the GTK libdecor plugin from the FLTK source code for the following reasons

- It does not introduce a hard dependency on GTK because this plugin is used only optionally, the default being not to

use it when package libgtk-3-dev is not present on the build system. Any developer reluctant to install package libgtk-3-dev

can build FLTK apps with the cairo plugin. Any developer willing not to use libgtk even if package libgtk-3-dev is present

on the build system can do so with "cmake -DOPTION_ALLOW_GTK_PLUGIN:Off".

- Supposing an FLTK app was built with the gtk-based plugin option set to on, the app is dynamically linked to libgtk.so

which is present in all systems recent enough to support Wayland. Package libgtk-3-dev is necessary at build time,

but not at run time.

So far, so good. I agree basically with Manolo.

OK - but: If FLTK is built on a system that has the gtk3-dev files available (as most of mine do) this then means that fltk ONLY has the gtk plugin built-in, the Cairo decorator will not be included (our build selects one or other to build in at compile time, it is not selected at run time.)

Good point - if that is true, and I don't doubt that it is because you (Ian) worked on this recently.

If code built against that FLTK is then deployed on a system that does not have gtk3 at all (which is still very possible) and is run on a system that provides no other decorator (still very likely just now) then it will not work as intended and a fallback to X11 must be used. Which is OK, but not ideal.

I wouldn't even say that this is OK. However, devs deploying executables built on one system to other (user) systems should know what they are doing and test compatibility anyway. They ought to know if they must build different binaries for different target systems.

If we *only* build in the Cairo decorator, it will work "everywhere" that fltk can work (since the default build of fltk now needs Cairo).

Any system that provides gtk3 and also provides a client-side decorator will use that anyway, rather than our built-in, and I assume that at some point (hopefully fairly soon) that will be the default and our built-in decorator will become rarely used. Our built-in decorator is only intended as a last-resort, not at the "best option". 

So on that basis I do not think we should strive to make it too gnome-compatible; any desktop distro that strives for gnome compatibility will presumably provide a gtk-client-side decorator and that is what will be used at runtime, rather than our built-in. (Or they might even switch to server-side decoration like KDE and save us all the hassle!)

I think that our built-in is very much the "decorator of last resort", and on that basis we should make it have as few other dependencies as possible.

I don't think that it's a "simple" decision. Yes, our bundled libdecor should only be used for a limited time, but users may use pretty old systems that we don't think of now. Think of the long time support (LTS) versions of some distros.

That said, I believe that - if portability is an issue - we should strive to do it similar to the gist of libdecor: our library (FLTK + libdecor) should be able to load any suitable libdecor plugin, even ones that don't exist yet. And to be most flexible we could build both the Cairo and GTK plugins (and maybe a shareable libdecor) that can be installed somewhere together with the libdecor plugins to support old(er) systems.

On more modern systems (distros) we should be able to load an installed (shareable) libdecor with (one of) many plugins installed on that system. AFAICT the system manager would set up the user's login session such that an environment variable points to the plugin directory depending on the user session type (for instance you can select KDE *or* Gnome login sessions on the same system).

[Bill Spitzak]

I do not think any GTK code should be included with fltk. FLTK will automatically use an "installed" gtk libdecor plugin, giving you ALL your claimed benefits.

The fallback plugin is included in case libdecor cannot load a plugin, which appears to be a very common case today. It is common enough that making it look reasonably attractive is a good idea. But it should be absolutely minimal with the smallest system requirements and linked libraries possible. Using Cairo is ok because Wayland-FLTK needs that anyway.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/4d9cc55d-ef6d-d5bf-5e68-6e186a136e4e%40online.de.

[Sanel Zukan]

AFAIK most light-weight distros [1] tries to stay away from GTK/Qt if
possible. E.g. TinyCore [2] was shipping a minimal distro without GTK
shared libraries - I think they might be happy to jump in Wayland
bandwagon, but won't be happy if you tell them that GTK is mandatory :)

[1] https://en.wikipedia.org/wiki/Light-weight_Linux_distribution
[2] http://tinycorelinux.net/

Best,
Sanel

[Manolo]

Le mardi 6 décembre 2022 à 18:14:33 UTC+1, sanelz a écrit :

No problem at all. FLTK uses GTK if it's installed on the build system. When it's not,

as in a propspective Wayland-enabled TinyCore system,  FLTK is happy without GTK.

[Bill Spitzak]

The problem is that if you compile on a system with GTK the result won't work on a system that does not have GTK.

Cairo of course has the same problem, but since the program won't work anyway this is much less of a concern.

I'm also wondering if the "fallback" can actually be in the fltk library, rather than a separate file. This is a real pita for statically-linked applications because the extra file is needed for them to work. What would happen is libdecor fails to load a plugin then it would be set to call the already included code. May require the code to be changed to avoid a name collision with symbols in the plugins.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/380138f7-abd3-4453-8164-8a008b01e006n%40googlegroups.com.

[Greg Ercolano]

On 12/6/22 11:31, Bill Spitzak wrote:

The problem is that if you compile on a system with GTK the result won't work on a system that does not have GTK.

    Perhaps Manolo's using runtime dynamic loads for gtk.
    He started using that to support the native file browser stuff, so I imagine it's the same for this..?

    In which case it should be fine, as that's a pure runtime thing, not compile time.

[Manolo]

Le mardi 6 décembre 2022 à 23:41:13 UTC+1, Greg a écrit :

    Perhaps Manolo's using runtime dynamic loads for gtk.

No.

Consider the X11 platform and libXinerama. FLTK links to it when package libxinerama-dev is present and doesn't use

it if absent. It's exactly the same for the hybrid Wayland/X11 platform and libgtk-3-dev.

[imacarthur]

On Tuesday, 6 December 2022 at 19:32:02 UTC Bill wrote:

The problem is that if you compile on a system with GTK the result won't work on a system that does not have GTK.

Cairo of course has the same problem, but since the program won't work anyway this is much less of a concern.

I'm also wondering if the "fallback" can actually be in the fltk library, rather than a separate file. This is a real pita for statically-linked applications because the extra file is needed for them to work. What would happen is libdecor fails to load a plugin then it would be set to call the already included code. May require the code to be changed to avoid a name collision with symbols in the plugins.

Our current implementation does link the plugin code into the static lib; such that our fallback decorator is always available and is not loaded actually loaded as a plugin. All the symbols are static anyway exported through a plugin struct, so collisions should not occur.

This does mean we are "carrying around" a chunk of code (albeit not huge) that I hope we seldom have to use! (And is partly why I'm not keen on building in both fallback options, as that becomes more overhead.)

[imacarthur]

On Tuesday, 6 December 2022 at 16:02:41 UTC Manolo wrote:

My angle of view is to put FLTK 1.4 in the best possible situation for acceptance of its new Wayland/X11 hybrid platform by current and prospective users. Therefore, why not arranging for it to appear as it will do when the next release of libdecor will have made its way into a linux package? Why present it as an alien app relatively to the gnome desktop when we know how to do better ?

I know I keep banging on about this, and I really don't want to come across as being an arse about it, but I still do not get it:

Yes, making fltk look consistent is important, but if the user has a system that is making heavy use of Wayland windows, then they presumably already have a system-provided decorator? (Either server or client side.)

In that case, fltk will be using that decorator anyway and there is no problem?

If they do not already have a system provided decorator, then it seems likely that their windows will have inconsistent decorations, and so fltk looks "no worse" than anything else?

So my concept of this is that we provide a fallback decorator that is "good enough" and which is likely to work "everywhere" , but in the expectation that (in the very near future, if not now) it will never be needed on most systems anyway.

Or I'm missing something key here?

[Manolo]

Le mercredi 7 décembre 2022 à 11:42:13 UTC+1, imacarthur a écrit :

I know I keep banging on about this, and I really don't want to come across as being an arse about it, but I still do not get it:

Yes, making fltk look consistent is important, but if the user has a system that is making heavy use of Wayland windows, then they presumably already have a system-provided decorator? (Either server or client side.)

In that case, fltk will be using that decorator anyway and there is no problem?

You write "fltk will be using that decorator anyway". That will happen in the future, when the GTK-based libdecor

plugin (and possibly others) will have made its/their way into Linux packages. But that's not possible today, because

this plugin is not yet packaged (it won't be for sure until the next public libdecor release).

My current understanding is that there are today 4 solutions to decorate Wayland windows on a CSD desktop:

1) build a GTK app;

2) build a Qt app;

3) use the approach proposed by libdecor where system plugins decorate windows, but the GTK plugin

intended for the gnome desktop is not yet a Linux package;

4) draw your own titlebars which is equivalent to duplication of libdecor + libdecor-cairo.

Today, all Wayland-enabled apps I know of are either GTK-based (all apps of the gnome suite) or Qt-based

(all apps of the KDE suite, cmake-gui) and are integrated to the desktop via libgtk*.so or libQt*.so.

The GTK plugin is the solution for FLTK apps to become well behaved in the gnome desktop since it uses the same

solution, libgtk*.so, as other gnome apps do.

Since the KDE desktop opted for SSD, FLTK apps need no help to get proper titlebars there.

If they do not already have a system provided decorator, then it seems likely that their windows will have inconsistent decorations, and so fltk looks "no worse" than anything else?

I would be curious to know about any Wayland-enabled Linux app that uses neither GTK nor Qt (nor FLTK) and see how

are its window titlebars. That would be an app that "does not already have a system provided decorator".

 

So my concept of this is that we provide a fallback decorator that is "good enough" and which is likely to work "everywhere" , but in the expectation that (in the very near future, if not now) it will never be needed on most systems anyway.

For sure, the Cairo plugin would work everywhere, but it would make FLTK apps appear alien, today, on the gnome desktop, although we know, today, how to do better. The Cairo plugin remains useful for those other systems without libgtk*.so

or those developers opposed to use it for whatever reason.

[Manolo]

I have prepared a Merge Request to the libdecor cairo plugin as discussed, that is, with the single change

pango_font_description_set_size ----> pango_font_description_set_absolute_size

 See:      https://gitlab.freedesktop.org/libdecor/libdecor/-/merge_requests/110

Also, notice that libdecor recently moved from gitlab.gnome.org/jadahl/libdecor to gitlab.freedesktop.org/libdecor/libdecor

[imacarthur]

Cool, thanks Manolo.

FWIW, rather than raising a PR/MR, I had filed an issue the other day:  https://gitlab.freedesktop.org/libdecor/libdecor/-/issues/46

We might be able to tie them together? Or not...

[Manolo]

Sorry, I had not seen it.
I've now mentionned in my MR that it's the same as what is suggested in your issue.

You could, may be, act symetrically with your issue ?

[imacarthur]

OK - but not from here (office)  as the weird firewall means I can see but not write gitlab from here...