| |
| |
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.
[ Direct Link to Message ] | |
|
| |
