Wayland

[ghost]

What

Do you have an idea how to support Wayland in build.zig? Maybe it's difficult to mirror what we have with cargo features.

Why

I run a pure Wayland desktop and don't have Xwayland installed.

[ghost]

I would repeat the question for Gl(u)Window feature, but didn't start a separate thread.

[MoAlyousef]

I've added an option zfltk-use-wayland.
So you could do zig build -Dzfltk-use-wayland=true

The other option is using Sdk.init_with_opts()

const sdk = Sdk.init_with_opts(b, .{ .use_wayland = true });

I've also added GlutWindow. Not all the methods were added yet.

[ghost]

Thanks! Is GlutWindow linking enabled unconditionally and up to the window creation code to choose whether it's used?

[ghost]

That was quick, highly appreciated!! While we're at it, what do you think of mirroring fltk-rs/fltk-rs#1429?

[ghost]

I've also added GlutWindow. Not all the methods were added yet.

Thanks. I'll try it again once the missing methods are there. For now, as expected, all you can get is a black window.

[ghost]

For the record, re-running the build (and using cmake cache) works around the dbus.h issue until cfltk is updated. I've seen that your fix has been merged by Manolo, but no rush. Thanks a lot.

[MoAlyousef]

Thanks! Is GlutWindow linking enabled unconditionally and up to the window creation code to choose whether it's used?

Yes. Recent Zig versions don't support older Windows versions so OpenGL is assumed to always be present. In Rust it's not the situation since on Windows 7, OpenGL support is patchy, and Rust still supports Windows 7. On Linux, OpenGL support requires the installation of a library, so it's always possible, even without hardware acceleration support.

what do you think of mirroring fltk-rs/fltk-rs#1429?

Zfltk doesn't link libgtk on wayland already. fltk-rs used to link it because it was previously required by libdecor.

For now, as expected, all you can get is a black window.

I haven't tried it yet, but OpenGL drawing should be supported. The default is a black window, unless you setBox(.flat) and setColor() to something:

// modified simple example
const zfltk = @import("zfltk");
const app = zfltk.app;
const GlutWindow = zfltk.GlutWindow;
const Button = zfltk.Button;
const Box = zfltk.Box;
const Color = zfltk.enums.Color;

fn butCb(but: *Button(.normal), data: ?*anyopaque) void {
    var box = Box.fromRaw(data.?);

    box.setLabel("Hello World!");

    but.setColor(Color.fromName(.cyan));
}

pub fn main() !void {
    try app.init();
    app.setScheme(.gtk);

    var win = try GlutWindow.init(.{
        .w = 400,
        .h = 300,

        .label = "Hello",
    });

    win.setBox(.flat);
    win.setColor(Color.fromName(.background));
    win.begin();

    var but = try Button(.normal).init(.{
        .x = 160,
        .y = 220,
        .w = 80,
        .h = 40,

        .label = "Click me!",
    });

    but.setDownBox(.flat);

    var box = try Box.init(.{
        .x = 10,
        .y = 10,
        .w = 380,
        .h = 180,

        .boxtype = .up,
    });

    box.setLabelFont(.courier);
    box.setLabelSize(18);

    win.end();
    win.show();

    but.setCallbackEx(butCb, box);
    try app.run();
}

[ghost]

I had forgotten to call win.begin() 🤦. It builds and runs correctly.

[ghost]

On Linux, OpenGL support requires the installation of a library, so it's always possible, even without hardware acceleration support.

Specifically libGLU. Despite being called GlutWindow, it doesn't require GLUT, or is maybe optional.

[ghost]

I'm asking a lot without contributing code, so if you'll allow me, I want to put this idea out there: what do you think of exposing --disable-x11 (in fltk-rs and zfltk)?

[MoAlyousef]

Specifically libGLU. Despite being called `GlutWindow', it doesn't require GLUT, or is maybe optional.

It's optional.

what do you think of exposing --disable-x11 (in cfltk and therefore fltk-rs plus zfltk)?

It's supported in fltk-rs via setting an env variable CFLTK_WAYLAND_ONLY which will basically set FLTK's OPTION_WAYLAND_ONLY=OFF during the build. Zfltk doesn't have such an option yet.

[ghost]

lddtree Python script from pax-utils confirms it's pulled in by cairo. It's unimportant, but I'm thinking out loud: would you expect a GlutWindow-only FLTK build (not what we have) to drop all Cairo use, or is it maybe used in shared code paths?

[ghost]

lddtree output:

    libcairo.so.2 => /usr/lib/libcairo.so.2
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1
            libexpat.so.1 => /usr/lib/libexpat.so.1
        libXext.so.6 => /usr/lib/libXext.so.6
        libXrender.so.1 => /usr/lib/libXrender.so.1
        libxcb-render.so.0 => /usr/lib/libxcb-render.so.0
        libxcb-shm.so.0 => /usr/lib/libxcb-shm.so.0
        libpixman-1.so.0 => /usr/lib/libpixman-1.so.0

[MoAlyousef]

would you expect a GlutWindow-only FLTK build (not what we have) to drop all Cairo use, or is it maybe used in shared code paths?

It’s possible for x11 via enable-glwindow,no-pango.

For wayland, cairo is used:

• for decorations via libdecor.
• for font rasterization via pangocairo.

[ghost]

Out of curiosity, not that it makes sense in production code, I gave no-pango a try and saw link errors for missing cairo symbols:

ld.lld: error: undefined symbol: cairo_clip
    >>> referenced by Fl_Wayland_Graphics_Driver.cxx
    >>> <long line>
    >>> referenced by Fl_Cairo_Graphics_Driver.cxx
...
ld.lld: error: undefined symbol: cairo_get_target
    >>> referenced by Fl_Wayland_Graphics_Driver.cxx
    >>> <long line>
    >>> referenced by Fl_Wayland_Graphics_Driver.cxx
    >>> <long line>
    >>> referenced by fl_wayland_clipboard_dnd.cxx

[MoAlyousef]

Yeah no-pango won’t work on use-wayland. Actually no-pango is a bit of a misnomer, it should probably be renamed to no-pango-cairo or something like that.