On 6/6/21 11:40 AM Manolo wrote:
> I'd like to invite fellow FLTK developpers to discuss the possibility of
> adding a Wayland platform to the FLTK library.

We've been asked (not many, but a few, countable) times about our plans
to add Wayland support to FLTK. I was about to look how this would be
done a few times, but now I see you did it. Awesome!

> My proposal is in branch "wayland" of https://github.com/ManoloFLTK/fltk
> See file README.Wayland.txt therein for installation instructions,
> including
> a short list of required Debian packages.
> That software should hopefully install on any Wayland-running Linux
> system.
> It's been tested on Debian and Ubuntu.
> At this time, the wayland branch is not complete but quite advanced :
> all test/ and examples/ apps build and run.

I'll try that ASAP, but likely not tomorrow because I need to do some
other stuff.

> The "wayland" branch doesn't require any change to the
> platform-independent FLTK
> code. It's expected that any FLTK app should link and mostly run as a
> Wayland client
> program. `fltk-config --cxxflags --ldflags` can be used in makefiles
> as usual.
> Nevertheless, X11-specific code delimited by
> #if !defined(__APPLE__) && !defined(_WIN32)
> ... X11-specific code ...
> #endif
> will choke at compile-time because it will expose X11-specific
> function calls. Such
> source code should be changed to
> #if !defined(__APPLE__) && !defined(WIN32) && !defined(__WAYLAND__)
> ... X11-specific code ...
> #endif

Thanks for your notes. This could turn out helpful.

Regarding the code changes: WOW, that's a lot of code! The following is
just for my curiosity:

I'm seeing also that much code has been copied which might not be needed
due to the driver structure. What are your plans, will you do a mass
cleanup when the Wayland code is (almost) finished? I'm asking because
I'm concerned about duplicated code. One example seems to be timer
related code which could be reused rather than duplicated etc. etc.. I
take it that you first copied the entire driver code and are now working
on fleshing out the needed changes and what doesn't need to be changed.
Is that about correct?

> The Wayland protocol accomodates either client-based or server-based
> window
> decoration. The Gnome Wayland implementation does not contain server-based
> window decoration and instead expects each client program to decorate
> its windows.
> For that reason, the FLTK library is extended in my proposal by a
> library, libdecor,
> (see https://gitlab.gnome.org/jadahl/libdecoration) which produces
> window decoration
> for each FLTK client program. That library is governed by the MIT
> license which
> allows unrestricted use, even in a commercial setting, but asks for a
> copy of the
> license to be included in any copy of the software.

Interesting. I see that you added the library to the FLTK repo. Are
there plans to (finally) bundle it or would we take it as a prerequisite
to be installed by developers? Generally I'd prefer the latter, but I
don't know how well it is supported by (Linux) distros. Can you share
your thoughts about this?

> I believe it's too early at this point for you, fellow developers, to
> send "this
> doesn't work" messages, but expect messages about attempts to install
> the new branch
> and to build full-size FLTK apps, and about the opportunity of a
> Wayland FLTK platform.

Looking forward to install and test! I'll let you know about my results
and hopefully others will try as well.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/2f54295b-a4d4-ecb2-c62b-14668d0fd70f%40online.de.