On Mon, 22 Dec 2025 21:42:08 +0100 ichthyo wrote:
I see two quite different approaches....
- we could say, we just require that Cairo support from now on,
and thus open a bug for Manjaro and maybe other distros which
still miss that.
- or, going into the other direction, we could add a further
macro and branching to the code, which triggers if we have
FLTK>= 1.4 but not defined FLTK_HAVE_CAIRO
On 22/12/2025 22:05, Will Godfrey wrote:
Difficult!
I've had very little contact with the Manjaro people apart from giving them
a nudge a couple of times when they were well out of date with Yoshimi.
On the other hand I've found Arch to generally be very co-operative.
I've also no idea if any other distros are affected.
The best compromise I can think of is to put the fallback into place,
but at the same time, send a brief report to the console at startup
that this has been done and the reason.
Lorenzo pointed out that David Runge is both the maintainer of FLTK and
Yoshimi in Arch Linux, and Manjaro is seemingly just a downstream consumer
of the Arch package in this case. I have now contacted David Runge.
Regarding that idea of a fallback: indeed, it seems very reasonably that
we should somehow handle the situation in a way that users do not have
to face a breakage.
So basically we have several cases now:
- building with FLTK <= 1.3 -- no Wayland support in the Toolkit.
The application always rund on XLib (and thus possibly on XWayland).
==> Nothing to do, use the legacy code.
- buidling with FLTK>= 1.4 AND FLTK has been configured to provide
the "Cairo bridge", i.e. the "Fl_Cairo_Window support" as it is marked
in the configure results.
==> we can use the Fix worked out by Jesper and do not have to care
if we run on top of X11 or Wayland, since FLTK handles all these
graphics platform stuff transparently
- building with FLTK>= 1.4 BUT no "Cairo bridge" available in FLTK.
==> *what to do now* ??
I could think of two different solutions.
(1) we could skip our custom drawing code and just invoke the
inherited draw() function. And we could disable the bandwidth
diagram for Subsynth. That implies, the UI will be slightly
degraded.
(2) we could use the internal API of FLTK at start-up to force
FLTK into using the X11 backend. Yoshimi will then run on top
of XWayland, even while it would be technically capable of
running natively on Wayland.
In addition, we could print a warning into STDERR.
But who cares to look at the console?
If we choose to follow the path (2) then the whole topic will go
unnoticed by the users. Until some years into the future, where
it might happen that support for XWayland starts to crumble.
But maybe this isn't much of a problem. Maybe we have way
more serious problems some years into the future, than
custom drawing with libCairo...
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
