fltk 1.5 on linux configured with -D FLTK_GRAPHICS_CAIRO=ON leaves FLTK_HAVE_CAIRO unset

[Klaus Rudolph]

I have configured fltk 1.5 with:

cmake . -B mybuild -D FLTK_GRAPHICS_CAIRO=ON -D CMAKE_BUILD_TYPE=Debug -D FLTK_BUILD_EXAMPLES=ON -D CMAKE_INSTALL_PREFIX:PATH=/home/krud/external_repos/fltk-1.5.x_cairo/myinstall

As a result this enables using transparency which was successful as discussed in an older thread.

But if I look into

include/FL/fl_config.h

 94 /*
 95  * FLTK_HAVE_CAIRO
 96  *
 97  * Do we have Fl_Cairo_Window support?
 98 */
 99
100 /* #undef FLTK_HAVE_CAIRO */
101
102
103 /*
104  * FLTK_HAVE_CAIROEXT
105  *
106  * Do we have the Cairo library available and want extended Cairo use in FLTK ?
107  * This implies to link cairo.lib in all FLTK based apps.
108 */
109
110 /* #undef FLTK_HAVE_CAIROEXT */

It looks that I can not use any function which gives me the cairo context.

What I am doing wrong?

[imm]

On Sat, 15 Nov 2025, 14:34 'Klaus Rudolph wrote:

But if I look into

include/FL/fl_config.h

 94 /*
 95  * FLTK_HAVE_CAIRO
 96  *
 97  * Do we have Fl_Cairo_Window support?
 98 */
 99
100 /* #undef FLTK_HAVE_CAIRO */
101
102
103 /*
104  * FLTK_HAVE_CAIROEXT
105  *
106  * Do we have the Cairo library available and want extended Cairo use in FLTK ?
107  * This implies to link cairo.lib in all FLTK based apps.
108 */
109
110 /* #undef FLTK_HAVE_CAIROEXT */

It looks that I can not use any function which gives me the cairo context.

What I am doing wrong?

Possibly nothing. Fl_Cairo_Window is orthogonal to whether or not the fltk back end uses Cairo for rendering and has little to do with whether you can have a valid Cairo context or not.

Rather, it was introduced long before the fltk back end had any Cairo support, as a means (modelled somewhat after FL_GL_Window) of doing Cairo rendering in an otherwise non-Cairo build.

But TBH I never felt it worked very well (I, and others, were already doing Cairo based drawing in "conventional" fltk windows anyway by that time) and I'm not sure how useful it really is these days...

So depending on what you actually want to do, it may not be useful to you; what is it that you actually want to do?

--

Ian

From my Fairphone FP3

   

[Klaus Rudolph]

I want to switch of antialiasing for some of my drawing operations.

The fl_antialias() function did not change the behaviour. I simply can call it with 1 or 0 and I can't see any changes. Not for lines, not for text.

My idea was to get the current cairo context and use the cairo functions:

               cairo_set_antialias(cr, CAIRO_ANTIALIAS_NONE); - Disables anti-aliasing for paths and shapes.

               cairo_font_options_set_antialias(options, CAIRO_ANTIALIAS_NONE); - Disables anti-aliasing for text.

But to get these functions to work, I need the cairo context.

But if FLTK_HAVE_CAIRO is not set, I can't get any context, as non of the cairo support function is available.

BTW:

How to get cairo context in fltk 1.5... currently I am digging through the headers... 

[imm]

On Sat, 15 Nov 2025, 15:06 'Klaus Rudolph' wrote:

I want to switch of antialiasing for some of my drawing operations.

The fl_antialias() function did not change the behaviour. I simply can call it with 1 or 0 and I can't see any changes. Not for lines, not for text.

My idea was to get the current cairo context and use the cairo functions:

               cairo_set_antialias(cr, CAIRO_ANTIALIAS_NONE); - Disables anti-aliasing for paths and shapes.

               cairo_font_options_set_antialias(options, CAIRO_ANTIALIAS_NONE); - Disables anti-aliasing for text.

But to get these functions to work, I need the cairo context.

But if FLTK_HAVE_CAIRO is not set, I can't get any context, as non of the cairo support function is available.

BTW:

How to get cairo context in fltk 1.5... currently I am digging through the headers... 

Is it a Wayland compositor? If so then fl_wl_gc() may be all that's needed?

[Klaus Rudolph]

How must fltk compiled to make that function available?

if I include "FL/platform.h"

I got:

../canvas.h:91:27: error: 'fl_wl_cc' was not declared in this scope
   91 |             cairo_t* cr = fl_wl_cc();

[Klaus Rudolph]

Sorry,

typo from me

but also fl_wl_gc() reports the same error. Looks like that FLTK_USE_X11 is active, if I read the platform.h correctly.

As also mentioned in all my other questions:

My requirement is:

I want to run a single binary on linux with X11 and also with wayland if this is possible.

My understanding was, that this IS possible.

Maybe we can go the other way around:

How can I compile fltk 1.5 to have FLTK_HAVE_CAIRO is set.

I already set  -D FLTK_GRAPHICS_CAIRO=ON

And this already switched transparent colors on. So from my side it looks like that cairo is in use. But maybe only partly?

It is all a bit hard to understand from a "user only" perspective. I am not very familiar with all the wayland/X11 specific things and how compiling fltk results in a more or less compatible version. I am still in hope that I had not to deal so much with all the differences between both of them myself.

I know, I already asked several questions regarding the specific X11 vs. wayland stuff. But I can't catch the point how to get it run? Sorry!

[Greg Ercolano]

'Klaus Rudolph' via fltk.general wrote:

I want to run a single binary on linux with X11 and also with wayland if this is possible.

My understanding was, that this IS possible.

    Read through the fltk 1.5 README.Cairo.txt for info, as that will go into the details you need to know about this.
    Note in particular the comments in that file regarding these other cmake variables you appear to not be using currently:

FLTK_OPTION_CAIRO_WINDOW     -- lets you make a window that can use cairo drawing calls directly
FLTK_OPTION_CAIRO_EXT        -- lets you access cairo context
FLTK_GRAPHICS_CAIRO          -- enables cairo for all fltk drawing under X11 (instead of using x11 functions to draw)

    Disclaimer: Those are my hastily written summary comments; best to read the paragraphs describing each of those carefully, as it goes into x11 vs wayland specifics and describes it better.

 fl_wl_gc() reports the same error

    I'm not an expert on this subject but  I try to keep up, and it sounds like you might need to enable the two cmake options FLTK_OPTION_CAIRO_WINDOW and FLTK_OPTION_CAIRO_EXT

I have configured fltk 1.5 with:

cmake . -B mybuild -D FLTK_GRAPHICS_CAIRO=ON -D CMAKE_BUILD_TYPE=Debug -D FLTK_BUILD_EXAMPLES=ON -D CMAKE_INSTALL_PREFIX:PATH=/home/krud/external_repos/fltk-1.5.x_cairo/myinstall

[..]

But if I look into include/FL/fl_config.h

/* #undef FLTK_HAVE_CAIRO */
[..]
/* #undef FLTK_HAVE_CAIROEXT */

    Regarding that.. again, not an expert on this, but I think there might be a typo:

        -D CMAKE_INSTALL_PREFIX:PATH=/home/krud/external_repos/fltk-1.5.x_cairo/myinstall

    That bit with the ":' (between PREFIX and PATH) seems wrong, and should probably just be an underbar instead, e.g.

        -D CMAKE_INSTALL_PREFIX_PATH=/home/krud/external_repos/fltk-1.5.x_cairo/myinstall

    This may in fact be a bug in one of our README files, e.g.

$ grep CMAKE_INSTALL_PREFIX README.CMake.txt
../README.CMake.txt:-D CMAKE_INSTALL_PREFIX:PATH=...

    (Albrecht: is that a typo in the README? I think that :PATH bit might be incorrect)

    If that's the problem, then your 'make install' is probably not updating that /home/krud... path correctly, leaving stale fl_config.h files behind from previous successful builds without cairo enabled.

[Greg Ercolano]

On 11/15/25 10:07, Greg Ercolano wrote:

'Klaus Rudolph' via fltk.general wrote:

I have configured fltk 1.5 with:

cmake . -B mybuild -D FLTK_GRAPHICS_CAIRO=ON -D CMAKE_BUILD_TYPE=Debug -D FLTK_BUILD_EXAMPLES=ON -D CMAKE_INSTALL_PREFIX:PATH=/home/krud/external_repos/fltk-1.5.x_cairo/myinstall

    Regarding that.. again, not an expert on this, but I think there might be a typo:

        -D CMAKE_INSTALL_PREFIX:PATH=/home/krud/external_repos/fltk-1.5.x_cairo/myinstall

    That bit with the ":' (between PREFIX and PATH) seems wrong, and should probably just be an underbar instead, e.g.

        -D CMAKE_INSTALL_PREFIX_PATH=/home/krud/external_repos/fltk-1.5.x_cairo/myinstall

    Actually that might be wrong too..
    Looking into it, I think the word PATH maybe shouldn't be in there at all, and it should just be:

        -D CMAKE_INSTALL_PREFIX=/some/path

    and no _PATH= or :PATH= suffix on the end of that.  The actual cmake docs seem to say the same:
    https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX.html

    This may in fact be a bug in one of our README files, e.g.

$ grep CMAKE_INSTALL_PREFIX README.CMake.txt
../README.CMake.txt:-D CMAKE_INSTALL_PREFIX:PATH=...

    (Albrecht: is that a typo in the README? I think that :PATH bit might be incorrect)

    I'll open an issue for this.

[Albrecht Schlosser]

On 11/15/25 19:07 Greg Ercolano wrote:

    Regarding that.. again, not an expert on this, but I think there might be a typo:

        -D CMAKE_INSTALL_PREFIX:PATH=/home/krud/external_repos/fltk-1.5.x_cairo/myinstall

    That bit with the ":' (between PREFIX and PATH) seems wrong, and should probably just be an underbar instead, e.g.

        -D CMAKE_INSTALL_PREFIX_PATH=/home/krud/external_repos/fltk-1.5.x_cairo/myinstall

    This may in fact be a bug in one of our README files, e.g.

$ grep CMAKE_INSTALL_PREFIX README.CMake.txt
../README.CMake.txt:-D CMAKE_INSTALL_PREFIX:PATH=...

    (Albrecht: is that a typo in the README? I think that :PATH bit might be incorrect)

No, it's not a typo. CMake uses a ':TYPE' notation for all its variables. Usually you don't need to specify it, but often it is better to do it (for clarity).

You can see all these variables with the type suffix for instance in CMakeCache.txt of the build folder.

Note: I'll reply to the original question in another message.

[Greg Ercolano]

On 11/15/25 10:22, 'Albrecht Schlosser' via fltk.general wrote:

No, it's not a typo. CMake uses a ':TYPE' notation for all its variables. Usually you don't need to specify it, but often it is better to do it (for clarity).

    Ah, OK -- I closed the issue and referenced your reply.

[Albrecht Schlosser]

On 11/15/25 16:55 'Klaus Rudolph' via fltk.general wrote:

As also mentioned in all my other questions:

My requirement is:

I want to run a single binary on linux with X11 and also with wayland if this is possible.

My understanding was, that this IS possible.

Yes, it is. See below for details.

Maybe we can go the other way around:

How can I compile fltk 1.5 to have FLTK_HAVE_CAIRO is set.

I already set  -D FLTK_GRAPHICS_CAIRO=ON

And this already switched transparent colors on. So from my side it looks like that cairo is in use. But maybe only partly?

Yes, unfortunately, yes. Historically we had two Cairo related options since FLTK 1.3 (with different names than the current ones). These options were related to using Cairo on the user's side, mainly with Fl_Cairo_Window. These options were and are still platform independent and must be switched on explicitly:

1. FLTK_OPTION_CAIRO_WINDOW - default OFF
    Enable support of class Fl_Cairo_Window (all platforms, requires the Cairo library) - see README.Cairo.txt.

This is the recommended option if you want to use Cairo drawing functions in your draw() method. To do this your window should be of class Fl_Cairo_Window.

Note that this is only for convenience. It's not strictly necessary to use Cairo drawings, but it has been implemented for a reason (see also README.Cairo.txt). 

2. FLTK_OPTION_CAIRO_EXT - default OFF
    Enable extended libcairo support. Setting this to ON is not recommended, see README.Cairo.txt.

This option would create a Cairo context on *all* windows (not only Fl_Cairo_Window's) which is not recommended for typical usage of Cairo drawing.

Both options can be used (as written above) on all platforms, including Windows and macOS where FLTK does not use Cairo internally for drawing widgets etc..


3. The third build option FLTK_GRAPHICS_CAIRO is new since FLTK 1.4 and is (currently) only used on Unix/Linux platforms, i.e. those that use either X11 or Wayland. If it is set ON, then all FLTK drawing calls use Cairo internally. However, this is an implementation detail and is NOT reflected in the compiler macro FLTK_HAVE_CAIRO that is set only if one of the first two options above is enabled.

Unfortunately this is pretty complicated from a user's point of view, but these are really two different ("orthogonal") cases and caused by platform differences.

It is all a bit hard to understand from a "user only" perspective. I am not very familiar with all the wayland/X11 specific things and how compiling fltk results in a more or less compatible version. I am still in hope that I had not to deal so much with all the differences between both of them myself.

I know, I already asked several questions regarding the specific X11 vs. wayland stuff. But I can't catch the point how to get it run? Sorry!

OK, to sum it up:

1. If you want to build a "hybrid" FLTK library, i.e. one that includes both X11 and Wayland drawing code (for Linux), then it's sufficient to use all the default options - presuming that all required libraries and their '-dev' packages are installed. You should check the build log and the summary at its end to see if anything is missing. You should particularly see these two lines (or similar):

-- Use Wayland                    Yes (can also run as X11 client)
-- All drawing uses Cairo         Yes

2. If you want to use Cairo drawing inside your FLTK window (or widget) you must also set `FLTK_OPTION_CAIRO_WINDOW:BOOL=ON` (I intentionally included optional ':BOOL' here). This will set the macro `FLTK_HAVE_CAIRO = 1` in fl_config.h which indicates that you can use Cairo for your own drawing calls (on all platforms, not only on Linux/Unix). If you did this you'll see a line like the following in the build summary:

-- Fl_Cairo_Window support        Yes (standard)

3. Forget option FLTK_OPTION_CAIRO_EXT for now, it's for special cases and usually not necessary. If you enable it, even a simple hello-world program on Windows and macOS will depend on (and must be linked with) Cairo libraries which is not usually what you want.


Final note for now: I noticed that Debian 13 (Trixie) includes option FLTK_OPTION_CAIRO_EXT in the supplied FLTK 1.4 libs. This is OK for a system library, but I don't recommend it for a library built by a user unless it's absolutely required for reasons stated above.

Please feel free to ask further questions if you need more help.

[Manolo]

Le samedi 15 novembre 2025 à 16:06:45 UTC+1, Klaus Rudolph a écrit :

I want to switch of antialiasing for some of my drawing operations.

The fl_antialias() function did not change the behaviour. I simply can call it with 1 or 0 and I can't see any changes. Not for lines, not for text.

Please, notice that fl_antialias() is documented to have effect only under the Windows platform.

The solution, under Wayland or X11 is to use function fl_wl_gc() as Ian suggested  before.
Here is an example:

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Widget.H>
#include <FL/Fl_Box.H>
#include <FL/fl_draw.H>
#include <FL/platform.H>
#include <cairo/cairo.h>

class plot : public Fl_Widget {
public:
  plot(int x, int y, int w, int h) : Fl_Widget(x,y,w,h,NULL) {
    color(FL_WHITE);
    box(FL_DOWN_BOX);
  }
  void draw() override {
    draw_box();
    fl_line_style(0, 5);
    fl_color(FL_BLACK);
    cairo_t *cr = fl_wl_gc();
    cairo_set_antialias(cr, CAIRO_ANTIALIAS_NONE);
    fl_line(x(),y(), x()+w(), y()+h());
    cairo_set_antialias(cr, CAIRO_ANTIALIAS_DEFAULT);
    fl_color(FL_RED);
    fl_line(x(),y() + 10, x()+w(), y()+h()+10);
    fl_line_style(0);
  }
};

int main(int argc, char **argv) {
  Fl_Window *window = new Fl_Window(340, 180);
  new plot(5,5,window->w()-10, window->h()-10);
  window->end();
  window->show();
  return Fl::run();
}

This code produces a non-antialiased black line and an antialised red line.

[Klaus Rudolph]

I still run against a big wall :-)

I did:

cmake . -B mybuild -D FLTK_GRAPHICS_CAIRO=ON -D CMAKE_BUILD_TYPE=Debug -D FLTK_BUILD_EXAMPLES=ON -D CMAKE_INSTALL_PREFIX:PATH=/home/krud/external_repos/fltk-1.5.x_cairo/myinstall

got:

-- Use Wayland                    No (X11 is used)

-- All drawing uses Cairo         Yes

-- Use Pango                      Yes

-- Fl_Cairo_Window support        Yes (standard)

-- CMAKE_CXX_STANDARD             11
-- CMAKE_CXX_STANDARD_REQUIRED    Yes
-- CMAKE_CXX_EXTENSIONS           No

In my code I tried a lot variants to get the cairo context. None works!

            //cairo_t* cr = fl_cairo_get_context(); // function not defined
            //cairo_t* cr = Fl::cairo_cc ();  // returns nullptr
            //cairo_t* cr = fl_wl_gc();  // fl_wl_gc function not defined!
            //fl_cairo_make_current(this); // function not defined!

@Manolo: I can't get your code to run simply because fl_wl_gc(); is only available for wayland. But my cmake tells me ( see above ) -- Use Wayland                    No (X11 is used)

I also have derived my Widget from Fl_Cairo_Window. Same result, got nullptr from cairo_t* cr = Fl::cairo_cc ();

To use fl_wl_gc I expect wl  means wayland, I need to have explicit wayland support. But this seems to switched off by the parameters I used for build with cmake.

There is another missing step here.... can you please take again a look on my stupid tries please!

Sorry for all the questions!

Klaus

[Klaus Rudolph]

I found the problem regarding missing wayland support:

On my system ( linux/fedora 6.17.7-200.fc42.x86_64 )

I had installed 

wayland-devel.x86_64                                 1.24.0-1.fc42

but to get cmake happy to find wayland libs it also needs:

wayland-protocols-devel.noarch                       1.45-1.fc42

I found it by comparing two installations where on one it builds with wayland support and on the other not.

Now I can get the cairo context with fl_wl_gc() and it is not nullptr!

and setting aliasing on/off takes effect for graphic shapes.

But:

It did not take effect for text drawn with fl_draw();

                cairo_font_options_t *options = cairo_font_options_create();
                cairo_font_options_set_antialias(options, CAIRO_ANTIALIAS_NONE);
                cairo_set_font_options(cr, options);
                cairo_font_options_destroy(options);

// drawing text with cairo shows effect of setting antialias of

                cairo_show_text(cr, "Hello, Cairo!");

// but if I use fl_draw() the text is still drawn with antialiasing.

Did fl_draw() not draw with cairo?

How can I set antialiasing off for text for fl_draw in this case? Not important, as I can draw with cairo directly, but maybe interesting for others two.

Thanks a lot for your support!

[Matthias Melcher]

Klaus Rudolph schrieb am Montag, 17. November 2025 um 20:00:34 UTC+1:

On my system ( linux/fedora 6.17.7-200.fc42.x86_64 )

I had installed 

wayland-devel.x86_64                                 1.24.0-1.fc42

but to get cmake happy to find wayland libs it also needs:

wayland-protocols-devel.noarch                       1.45-1.fc42

The list of packages that need to be installed to compile for Wayland are listed in README.Wayland.txt. Chapter 3.2 lists the packages required for Fedora.

[Manolo]

Le lundi 17 novembre 2025 à 20:00:34 UTC+1, Klaus Rudolph a écrit :

Did fl_draw() not draw with cairo?

How can I set antialiasing off for text for fl_draw in this case? Not important, as I can draw with cairo directly, but maybe interesting for others two.

fl_draw draws text with Pango and Pango uses pango_cairo to draw to the cairo context.

I've no idea what Pango does about antialiasing.

Pango is absolutely necessary for FLTK that needs to support Unicode text.