Please vote: add a Wayland platform to FLTK

[Manolo]

I'd like to invite fellow FLTK developers to vote about
adding a Wayland platform to the FLTK library.
++++++++++++++++
Manolo


The candidate code 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 install on any Wayland-running Linux system.
It's been tested on Debian and Ubuntu.
The new code contains no change to platform-independent FLTK code;
it's therefore completely compatible with extant FLTK user code.

Major features of the Wayland branch
====================================

* FLTK uses the Wayland protocol for its windowing,
Cairo or OpenGL (EGL, really) for its drawing, Pango for font handling and text drawing.
Copy/paste of text or images, and drag-n-drop of text are supported.

* Both CMake-based and configure-based building methods are possible.
With both, the install and build shared libs options are possible.

* All test/ and examples/ apps build and run.

* CJ(K?) text input methods, dead keys (important with some keyboard layouts) and
compose keys are supported.

* Wayland integrates a support for HighDPI displays in the form of an integer-valued
scale factor (typically, 200 % on a standard HighDPI display) recognized by FLTK.
In addition, the user can scale all FLTK windows up and down with ctrl/+/-/ keys.

* The code has been tested using 3 distinct Wayland implementations:
Mutter (that of Gnome), Weston (which is extremely rudimentary and has bugs), and KDE.

* User applications should build and run under the Wayland platform without
source code change. 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 :
#include <FL/fl_config.h>
#if defined(FLTK_USE_X11)
... X11-specific code ...
#endif
which is the new, correct way to identify X11-specific code in 1.4

* `fltk-config --cxxflags --ldflags` can be used in makefiles as usual.

* OpenGL and GLUT are supported as for other FLTK platforms. OpenGL3 is supported too,
but a minor source code change is required after the glewInit() call :
  GLenum err = glewInit(); // defines pters to functions of OpenGL V 1.2 and above
#ifdef FLTK_USE_WAYLAND
  if (err == GLEW_ERROR_NO_GLX_DISPLAY) err = GLEW_OK;
#endif
That's because glewInit() returns an error code value in the Wayland context.

* The Wayland protocol accomodates either client-based or server-based window
decoration. The Gnome and Weston Wayland implementations do not contain server-based
window decoration and instead expect each client program to decorate its windows.
For that reason, the FLTK library is extended by a library, libdecor,
(see https://gitlab.gnome.org/jadahl/libdecor) 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.
The CMake-based build method has an option to use the system-level
libdecor package available on recent Linux distributions. FLTK uses by default a
copy of libdecor bundled into its source tree.

* The FLTK/Cairo interface is unchanged : test/cairo_test runs OK.

* Some platform-related code is identical for the Wayland and X11 platforms.
Timeout support is in that case.
The new code defines a new class, Fl_Nix_System_Driver, where all such code is located.
After inclusion of the Wayland branch, the X11-platform code will also use
class Fl_Nix_System_Driver.

* The complete FLTK drawing API is implemented using Cairo (plus Pango for text).
This opens the possibility to define in the future a new option for the X11 platform
of FLTK where all drawing would be Cairo-based, and thus antialiased.


Known limitations of the Wayland branch
=======================================

* It's not yet been tested on a setting with several displays, but should accomodate
that in principle.

* Wayland, deliberately as a security measure, keeps client programs ignorant
of the position of a window in a display or of whether it is minimized.
Consequently, Fl_Window::position(x, y) has no effect except for subwindows and
menu and tooltip windows, and Fl_Window::show() has no effect on a minimized window.

* When running Fl_Native_File_Chooser, the GTK file chooser window is not made
transient for the originating FLTK window, as it should, because the GTK API necessary
for that doesn't exist or has not been identified.

[Greg Ercolano]

On 1/4/22 8:07 AM, Manolo wrote:

I'd like to invite fellow FLTK developers to vote about
adding a Wayland platform to the FLTK library.

Sounds +1 to me. Would be good to have it as an option so folks
who use wayland can test at any time.

Can you think of any possible downsides to adding it?

As long as it's an option, it sounds like a great addition that didn't
involve changing any of the platform independent code, so the changes
sound like they'd be off unless enabled.

[Albrecht Schlosser]

On 1/4/22 5:07 PM Manolo wrote:

I'd like to invite fellow FLTK developers to vote about
adding a Wayland platform to the FLTK library.

I'm basically +1 on adding Wayland but I'd like to test before I can make my final vote.

The new code contains no change to platform-independent FLTK code;
it's therefore completely compatible with extant FLTK user code.

I see a conflict with changes I'm currently doing to consolidate timeout functions. I'm going to check the implications.

* Some platform-related code is identical for the Wayland and X11 platforms.
Timeout support is in that case.
The new code defines a new class, Fl_Nix_System_Driver, where all such code is located.
After inclusion of the Wayland branch, the X11-platform code will also use
class Fl_Nix_System_Driver.

This is an area where your and my changes conflict. I need to evaluate the changes...


BTW, for curiosity: what does Fl_*Nix*_System_Driver mean, is there something we can use to describe it? Does it have to do with Unix, Posix, or something like this?

[Evan Laforge]

> BTW, for curiosity: what does Fl_*Nix*_System_Driver mean, is there something we can use to describe it? Does it have to do with Unix, Posix, or something like this?

At work I use a package manager / build system called nix, and at home
a linux distro called NixOS so that name would make me think it's a
driver for some special variant of X11 that NixOS uses... which it
doesn't as far as I know.

[Manolo]

Le mardi 4 janvier 2022 à 20:12:52 UTC+1, Albrecht Schlosser a écrit :

On 1/4/22 5:07 PM Manolo wrote:

I'd like to invite fellow FLTK developers to vote about
adding a Wayland platform to the FLTK library.

I'm basically +1 on adding Wayland but I'd like to test before I can make my final vote.

I fully understand some time is  necessary before the vote.

I see a conflict with changes I'm currently doing to consolidate timeout functions. I'm going to check the implications.

* Some platform-related code is identical for the Wayland and X11 platforms.
Timeout support is in that case.
The new code defines a new class, Fl_Nix_System_Driver, where all such code is located.
After inclusion of the Wayland branch, the X11-platform code will also use
class Fl_Nix_System_Driver.

This is an area where your and my changes conflict. I need to evaluate the changes...

OK. Let me know if I could help by any change within the Wayland code.

BTW, for curiosity: what does Fl_*Nix*_System_Driver mean, is there something we can use to describe it? Does it have to do with Unix, Posix, or something like this?

The goal here is to name a class that would be used by the X11 and Wayland platforms

to contain code useful to both. This means, used on Unix and Linux but not on macOS.

'Posix' is already used to name a class shared by the X11 and macOS platforms (+ Wayland, eventually).

The net result is this class hierarchy :

Fl_System_driver
++++ Fl_Posix_System_driver
++++++++ Fl_Nix_System_driver
++++++++++++ Fl_X11_System_driver
++++++++++++ Fl_Wayland_System_driver
++++++++ Fl_Darwin_System_driver
++++ Fl_WinAPI_System_driver

I've proposed Fl_Nix_System_driver following the practivce to name *Nix the Unix+Linux OS collection.

Aternative name suggestions are very welcome.

[Sanel Zukan]

Manolo <manol...@gmail.com> writes:
> Fl_System_driver
> ++++ Fl_Posix_System_driver
> ++++++++ Fl_Nix_System_driver
> ++++++++++++ Fl_X11_System_driver
> ++++++++++++ Fl_Wayland_System_driver
> ++++++++ Fl_Darwin_System_driver
> ++++ Fl_WinAPI_System_driver
>
> I've proposed Fl_Nix_System_driver following the practivce to name *Nix the
> Unix+Linux OS collection.
>
> Aternative name suggestions are very welcome.

Why not simply Fl_X_System_driver, as Wayland is "successor" of X11? It
would also match (sort of) FL/x.H, which was "display calls on unix/linux".

I though Fl_Nix_System_driver would run or communicate with nix as well :D

Best,
Sanel

[Sanel Zukan]

+1 looking forward to test it in the future (waiting for Slackware
upgrade first).

Best,
Sanel

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/53ecaf4c-39ff-4513-b4c5-e8e0136839b3n%40googlegroups.com.

[Albrecht Schlosser]

On 1/5/22 6:53 AM Manolo wrote:

Le mardi 4 janvier 2022 à 20:12:52 UTC+1, Albrecht Schlosser a écrit :

On 1/4/22 5:07 PM Manolo wrote:

I'd like to invite fellow FLTK developers to vote about
adding a Wayland platform to the FLTK library.

I'm basically +1 on adding Wayland but I'd like to test before I can make my final vote.

I fully understand some time is  necessary before the vote.

Here are my first results (I'll continue testing later). I tested on Ubuntu 20.04 with Wayland desktop.

(1) The window title fonts are way too large (obviously in CSD mode). Can we reduce the font size?

(2) There doesn't seem to be an appropriate double clicks timeout. You can click twice with a delay of 5 seconds and the second click is still recognized as a double click.

* Some platform-related code is identical for the Wayland and X11 platforms.

Timeout support is in that case.
The new code defines a new class, Fl_Nix_System_Driver, where all such code is located.
After inclusion of the Wayland branch, the X11-platform code will also use
class Fl_Nix_System_Driver.

This is an area where your and my changes conflict. I need to evaluate the changes...

OK. Let me know if I could help by any change within the Wayland code.

I'm looking into it...

FYI: I rewrote the entire timeout handling code which is now almost platform independent. The platform specific code calls only a few methods of the new internal class Fl_Timeout. I still need to solve some minor problems though, I'll let you know how to proceed as soon as I have a stable solution.

The goal here is to name a class that would be used by the X11 and Wayland platforms

to contain code useful to both. This means, used on Unix and Linux but not on macOS. [...]

The net result is this class hierarchy :

Fl_System_driver
++++ Fl_Posix_System_driver
++++++++ Fl_Nix_System_driver
++++++++++++ Fl_X11_System_driver
++++++++++++ Fl_Wayland_System_driver
++++++++ Fl_Darwin_System_driver
++++ Fl_WinAPI_System_driver

I've proposed Fl_Nix_System_driver following the practivce to name *Nix the Unix+Linux OS collection.

Aternative name suggestions are very welcome.

I don't know a better name, I wouldn't mind if we kept it, although I'm also open for better suggestions.

[Greg Ercolano]

On 1/10/22 9:27 AM, Albrecht Schlosser wrote:

Fl_System_driver

++++ Fl_Posix_System_driver
++++++++ Fl_Nix_System_driver
++++++++++++ Fl_X11_System_driver
++++++++++++ Fl_Wayland_System_driver
++++++++ Fl_Darwin_System_driver
++++ Fl_WinAPI_System_driver

I've proposed Fl_Nix_System_driver following the practivce to name *Nix the Unix+Linux OS collection.

Aternative name suggestions are very welcome.

I don't know a better name, I wouldn't mind if we kept it, although I'm also open for better suggestions.

    I think in light of Evan's comments regarding confusion with NixOS,
    and I myself think "Nix" is not a good mneumonic for Unix/Linux, I'd suggest
    just going with Fl_Unix_System_Driver, since linux is a unix derivative.

    Or if for some reason Fl_Unix_xxx is being avoided, Fl_UnixOS_xxx?

    I just think using Unix is clearer, and linux is unix, just as FreeBSD, IRIX, SunOS etc.

[Bill Spitzak]

Darwin is pretty much a Unix as well.

I am unclear what exactly is in Nix and not in Posix. It seems to me that all this code can be put into Posix and then (if necessary) the Darwin one can override anything it needs to change.

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/ba952c8e-7dd5-ac5f-5ebf-53d430b9fea1%40seriss.com.

[Greg Ercolano]

On 1/10/22 12:59 PM, Bill Spitzak wrote:

Darwin is pretty much a Unix as well.

I am unclear what exactly is in Nix and not in Posix. It seems to me that all this code can be put into Posix and then (if necessary) the Darwin one can override anything it needs to change.

    +1 if that's the case.

    But I figure there must be a reason, perhaps the commonality of POSIX
    support, what little there problem is, on e.g. Windows. But I'm not sure..

[Greg Ercolano]

    Ugh -- don't know how the word "problem" got in there.. that was meant to be:

        ..perhaps the commonality of POSIX  support, what little there is, on e.g. Windows.

[Albrecht Schlosser]

On 1/10/22 7:08 PM Greg Ercolano wrote:

On 1/10/22 9:27 AM, Albrecht Schlosser wrote:

Fl_System_driver

++++ Fl_Posix_System_driver
++++++++ Fl_Nix_System_driver
++++++++++++ Fl_X11_System_driver
++++++++++++ Fl_Wayland_System_driver
++++++++ Fl_Darwin_System_driver
++++ Fl_WinAPI_System_driver

I've proposed Fl_Nix_System_driver following the practivce to name *Nix the Unix+Linux OS collection.

Aternative name suggestions are very welcome.

I don't know a better name, I wouldn't mind if we kept it, although I'm also open for better suggestions.

    I think in light of Evan's comments regarding confusion with NixOS,
    and I myself think "Nix" is not a good mneumonic for Unix/Linux, I'd suggest
    just going with Fl_Unix_System_Driver, since linux is a unix derivative.

+1

If I had to choose between Fl_Nix_System_driver and Fl_Unix_System_Driver my choice would be Fl_Unix_System_Driver.

But we should check if we really need this extra driver as Bill wrote elsewhere in this thread.

[Manolo]

Le lundi 10 janvier 2022 à 18:27:16 UTC+1, Albrecht Schlosser a écrit :

Here are my first results (I'll continue testing later). I tested on Ubuntu 20.04 with Wayland desktop.

(1) The window title fonts are way too large (obviously in CSD mode). Can we reduce the font size?

We sure can if we use libdecor as bundled in FLTK. By the way, libdecor had smaller font before and increased it at some point to be in line with gnome I believe.

But it might be impossible then to use libdecor as a system package available in recent Linux versions, which is desirable I believe.

(2) There doesn't seem to be an appropriate double clicks timeout. You can click twice with a delay of 5 seconds and the second click is still recognized as a double click.

I'll look into that.

[Manolo]

Le lundi 10 janvier 2022 à 21:59:57 UTC+1, spi...@gmail.com a écrit :

Darwin is pretty much a Unix as well.

I am unclear what exactly is in Nix and not in Posix. It seems to me that all this code can be put into Posix and then (if necessary) the Darwin one can override anything it needs to change.

Putting everything  in Fl_Posix_System_Driver and having what is macOS-specific overriden by member functions of a derived class, Fl_Darwin_System_Driver is an interesting suggestion. I see two potential issues :

- the macOS libfltk would be slightly increased in size because it would contain 2 versions of the Fl_Darwin_System_Driver member functions;

- could present or future Fl_Posix_System_Driver member functions not be supported by macOS ?

[Bill Spitzak]

I think we need to seriously fix this misuse of virtual functions. As you note, this often requires it to compile code that will never be used, and may not compile on a given platform. The other problem is it pretty much links in *everything* to the vtab table so fltk ends up as a monolithic library.

It also requires any differences to be split at the function level, rather than just putting #if around some statements which could greatly reduce the size of the differences.

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/cf756acd-8dcb-465e-a874-a99eba1a9125n%40googlegroups.com.

[Albrecht Schlosser]

On 1/11/22 11:58 PM Bill Spitzak wrote:
> I think we need to seriously fix this misuse of virtual functions.

What you consider a misuse has been a design decision many years ago
(but after your active participation). The advantage is to be open for
an unlimited number of "platforms" which turned out to be no longer
maintainable with the old three-platform #ifdef stuff.

I've just today compared new code with the old #ifdef code of 1.3.x -
although the new code is sometimes more difficult to understand the old
code was horrible to read for me. All that grown platform specific stuff
(handling of platform specific config directories) was way too
complicated - for only three platforms! Android is under development and
there's now Wayland, we have preparations for SDL(2), and the exotic
'pico' drivers. All in one code base would not be maintainable.

But we do know that the new strategy comes with a price we have to pay...

> As you note, this often requires it to compile code that will never be
> used, and may not compile on a given platform.

Normally this is not a problem because the drivers for each platform are
only compiled on the respective platforms. As Manolo mentioned, this new
split of Wayland from the common base used in parts for Unix/Linux and
macOS is much more complicated to do it right.

> The other problem is it pretty much links in *everything* to the vtab
> table so fltk ends up as a monolithic library.

All unused driver code is not compiled at all, such classes are not
known to the compiler and that makes it not link in *everything* to the
vtab table.

> It also requires any differences to be split at the function level,
> rather than just putting #if around some statements which could
> greatly reduce the size of the differences.

I agree, that's a valid point. But there's another option: splitting the
code in simpler functions where only the mostly very short platform
specific parts are splitted off. This has not always been done optimally
yet so that one can find (too) large parts of copied code in different
platform drivers. Admittedly, this is a problem we have now, but this is
IMHO not the design but just not (yet) optimal work in some parts. But
this can be improved.

[Bill Spitzak]

The problem with the old code was that the "base" was the X11 version and everything else was ifdefs alternatives. The fltk2.0 code rearranged this so that "#if X11" worked and thus the X11 code could be put into it's own files where you don't have to see it if working on another platform, and also the attempts to make other platforms look like X11 (like #define things to XWindow, etc) were removed.

You are correct that another fix was to not try to merge different implementations excessively. But I do like that it can be done occasionally. I don't like having the lower-level functions exist because nothing is stopping client code from calling them directly and then we are stuck with the implementation.

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/2a603665-1949-fd4b-e61f-c261c6b430d7%40online.de.

[Albrecht Schlosser]

On 1/11/22 4:52 PM Manolo wrote:

Le lundi 10 janvier 2022 à 18:27:16 UTC+1, Albrecht Schlosser a écrit :

Here are my first results (I'll continue testing later). I tested on Ubuntu 20.04 with Wayland desktop.

(1) The window title fonts are way too large (obviously in CSD mode). Can we reduce the font size?

We sure can if we use libdecor as bundled in FLTK. By the way, libdecor had smaller font before and increased it at some point to be in line with gnome I believe.

But it might be impossible then to use libdecor as a system package available in recent Linux versions, which is desirable I believe.

What exactly is the problem? Can we not adjust the font size when using libdecor on the application level? Is it hard coded into libdecor?

FWIW, I'm attaching a screenshot from my Ubuntu 20.04 with Wayland desktop (isn't this "Gnome" based?) with (from top to bottom):

- desktop title bar ("XTerm")
- fluid - X11 (normal "Untitled.fl")
- fluid - Wayland (large "Untitled.fl")
- xterm

The examples show the difference but if you have a smaller window and a longer title it may be more obvious that the title text may easily overflow the existing space - at least much earlier than with the normal size.

Another observation is that the system title bar is much taller although the title font is smaller. I wouldn't care about the title bar height though, but the font looks way to large - and ugly IMHO.

[Manolo]

Le mercredi 12 janvier 2022 à 02:08:56 UTC+1, Albrecht Schlosser a écrit :

What exactly is the problem? Can we not adjust the font size when using libdecor on the application level? Is it hard coded into libdecor?

It's hardcoded into libdecor's cairo plugin which is conceived as a plugin which could be one of several libdecor plugins providing

window title service. There's no API to change this fontsize.

[Bill Spitzak]

It does look like they made the font too big, but this is much better than making the titlebar too thick which is what I thought was going on. May need to live with this for now. FLTK could draw the entire titlebar itself, though, especially if there does not appear to be any attempt to make this plugin replaceable so the appearance is customized to match the desktop.

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/58fc69c1-1ebd-43bb-a2f9-8fb2fa8ab65dn%40googlegroups.com.

[Manolo]

Le lundi 10 janvier 2022 à 18:27:16 UTC+1, Albrecht Schlosser a écrit :

Here are my first results (I'll continue testing later). I tested on Ubuntu 20.04 with Wayland desktop.

(1) The window title fonts are way too large (obviously in CSD mode). Can we reduce the font size?

As I wrote before, I would prefer not to modify libdecor because it's packaged in recent distros.

But, libdecor is constructed as a host for plugins which draw titlebars :

"It aims to provide multiple backends that implement the decoration drawing."

Only one plugin I know of exists now, libdecor-cairo, which hardcodes the fontsize used for window titles.

But, other libdecor plugins might appear in the future.

(2) There doesn't seem to be an appropriate double clicks timeout. You can click twice with a delay of 5 seconds and the second click is still recognized as a double click.

That should be fixed now in the git repo, as well as line selection with triple click that didn't work with Fl_Text_Display.

[Manolo]

Le mardi 11 janvier 2022 à 14:13:04 UTC+1, Albrecht Schlosser a écrit :

    I think in light of Evan's comments regarding confusion with NixOS,
    and I myself think "Nix" is not a good mneumonic for Unix/Linux, I'd suggest
    just going with Fl_Unix_System_Driver, since linux is a unix derivative.

+1

If I had to choose between Fl_Nix_System_driver and Fl_Unix_System_Driver my choice would be Fl_Unix_System_Driver.

I take this vote to be related to the class name only, not to the vote asked for in this thread.
So, I keep waiting for your vote about adding the Wayland platform. No hurry.

[Manolo]

Le mardi 4 janvier 2022 à 19:23:14 UTC+1, er...@seriss.com a écrit :

On 1/4/22 8:07 AM, Manolo wrote:

I'd like to invite fellow FLTK developers to vote about
adding a Wayland platform to the FLTK library.

Sounds +1 to me. Would be good to have it as an option so folks
who use wayland can test at any time.

Many thanks Greg for your positive vote.

Can you think of any possible downsides to adding it?

There's no change to any previous platform-specific code nor to any platform-independent code.

Thus adding Wayland support should not create problems.

Wayland is presently written under the assumption that class Fl_Nix_System_Driver will

be created (now we know it will probably be called Fl_Unix_System_Driver, really) to host

code used both by the X11 and Wayland platforms. Thus, Albrecht's WIP changes to this code

in relation to timeouts will interfere with this assumption. But it will be easy to reconcile Wayland

with these changes because Wayland does nothing but use the same code as X11 for timeouts.

Adding the Wayland platform to FLTK is some sort of moral engagement to maintain it, even

if the Android platform has been for years mostly dormant in the FLTK master git repo

without trouble.

It's now clear that Wayland is the future of Linux desktops, even if it's also clear that X11 clients will

be kept working via  X-servers as Wayland clients.

The FLTK Wayland platform improves on the X11 platform by drawing everything antialiased.

Conceivably, this benefit could be transferred to the X11 platform reusing

Fl_Wayland_Graphics_Driver which is a complete Cairo-based graphics driver.

[Albrecht Schlosser]

On 1/14/22 10:14 AM Manolo wrote:

Le lundi 10 janvier 2022 à 18:27:16 UTC+1, Albrecht Schlosser a écrit :

Here are my first results (I'll continue testing later). I tested on Ubuntu 20.04 with Wayland desktop.

(1) The window title fonts are way too large (obviously in CSD mode). Can we reduce the font size?

As I wrote before, I would prefer not to modify libdecor because it's packaged in recent distros.

I understand and I agree. It's at least good as a start.

But, libdecor is constructed as a host for plugins which draw titlebars :

"It aims to provide multiple backends that implement the decoration drawing."

Only one plugin I know of exists now, libdecor-cairo, which hardcodes the fontsize used for window titles.

But, other libdecor plugins might appear in the future.

How complicated would it be to ...

(a) write everything needed directly in FLTK as Bill suggested (IIRC) ?

(b) write a plugin for libdecor if that's easier than (a) ?

Don't understand me wrong, it's only a question.

Theoretically I would prefer to use (a) rather than relying on libdecor if (when) we need to use client-side decorations and we don't need to care anyway on platforms that use server-side decorations.

[Albrecht Schlosser]

On 1/14/22 10:18 AM Manolo wrote:

Le mardi 11 janvier 2022 à 14:13:04 UTC+1, Albrecht Schlosser a écrit :

If I had to choose between Fl_Nix_System_driver and Fl_Unix_System_Driver my choice would be Fl_Unix_System_Driver.

I take this vote to be related to the class name only, not to the vote asked for in this thread.

Yep, that's what I meant.

[Albrecht Schlosser]

On 1/14/22 10:42 AM Manolo wrote:

It's now clear that Wayland is the future of Linux desktops, even if it's also clear that X11 clients will

be kept working via  X-servers as Wayland clients.

The FLTK Wayland platform improves on the X11 platform by drawing everything antialiased.

Conceivably, this benefit could be transferred to the X11 platform reusing

Fl_Wayland_Graphics_Driver which is a complete Cairo-based graphics driver.

This would be a very interesting new feature.

However, if we're talking about X11 I believe also that in the future all systems that provide X11 will also provide Wayland so users can choose between X11 (maybe faster but not antialiased) and Wayland (maybe slower but antialiased).

The only situation where you can't use Wayland and need X11 instead would be a remote X11 display [1] which Wayland does not support.

[1] i.e. usually a remote application with the local display (server) where the user is located.

It would still be interesting whether there's a noticeable difference in drawing speed (local Wayland/Cairo vs. local X11) of normal GUI operations.

[Bill Spitzak]

It does sound like the intention is that libdecor is supposed to be replaced by desktops to make a consistent appearance. It might be best to wait to see if anybody does that before giving up on it. It does sound at least like libdecor is provided on any Wayland system, the main concern is that we would need a fallback if it is missing.

IMHO the screenshot looks a lot better than typical modern ssd (having just updated Linux Mint and it looks like they went with thick titles with curved top corners, why???).

The belief that users will be "confused" if title bars don't match each other is complete nonsense and easily disproven.

Quick impression from this is that it would be better use of time to improve the implementation, primarily to remove what appears to be extra intermediate buffers for the window image. You should be able to get libdecor and fltk to draw into the same window image, rather than fltk drawing into another. I also think it is pretty important to switch the plain X11 version to Cairo, and to fix any graphics errors in Cairo (in particular to avoid unwanted antialiasing).

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/e866ed70-b26c-bda7-19e4-d1b2255bd335%40online.de.

[Manolo]

Le samedi 15 janvier 2022 à 17:35:00 UTC+1, Albrecht Schlosser a écrit :

How complicated would it be to ...

(a) write everything needed directly in FLTK as Bill suggested (IIRC) ?

Quite complicated.  I don't plan to do that because libdecor does it very well

and has been included in Linux distros.

(b) write a plugin for libdecor if that's easier than (a) ?

A would-be FLTK libdecor plugin would ultimately be a minor variation of the extant

libdecor-cairo.cxx. So, this solution is nearly identical to a modification of

the bundled libdecor part of FLTK.

Don't understand me wrong, it's only a question.

Theoretically I would prefer to use (a) rather than relying on libdecor if (when) we need to use client-side decorations and we don't need to care anyway on platforms that use server-side decorations.

The gitlab repo of libdecor has already committed a change I proposed via a

Merge Request to fix a crash when several windows are created and deleted.

Another one about window shades remaining under Weston on the display after minimization has

been committed to the Weston repo after I mentionned to libdecor's author this problem .

It's not been released yet, but I see a beta version of the next public Weston version

has been created 3 days ago.

I expect a third one to be committed to libdecor very soon, about a bug in the support

of minimum window sizes.

Therefore, it would make sense to propose a change in the fontsize used by libdecor-cairo

if there's a good case for it.

 

[Bill Spitzak]

I'm a little confused, FLTK is including a libdecor plugin? If there is another one installed on the machine, will that one be used in preference to the fltk one? Also we cannot just assume the plugin exists?

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/f219df21-effd-4506-a235-3f8eba122f9bn%40googlegroups.com.

[Manolo]

Le lundi 17 janvier 2022 à 01:37:20 UTC+1, spi...@gmail.com a écrit :

I'm a little confused, FLTK is including a libdecor plugin?

Yes. The libdecor source code is copied, partially but unchanged, to the FLTK source tree in libdecor/

[What is not copied is source code for meson-based building wich FLTK doesn't use.]

If there is another one installed on the machine, will that one be used in preference to the fltk one?

See below how to use the system-level libdecor when it's present on the system.

When it's not present or when we don't want to use the system version of libdecor,

libdecor is searched in the FLTK source tree, so there's no ambiguity if another

libdecor source tree exists elsewhere. That code is compiled and included in libfltk.

If the system contains an installed libdecor, turn on option OPTION_USE_SYSTEM_LIBDECOR in

CMake, and all resulting FLTK apps will be dynamically linked to the system's libdecor shared lib.

 

Also we cannot just assume the plugin exists?

We could, but libdecor is  available only in quite recent Linux distros, not yet in the current long term support Ubuntu

I believe. I concluded it would be unwise to do that at this time.

@Bill: Let me know if you'd prefer another approach.

[Manolo]

Le lundi 17 janvier 2022 à 01:37:20 UTC+1, spi...@gmail.com a écrit :

Also we cannot just assume the plugin exists?

Let's be very explicit about what "plugin" does or may mean here.

1) If FLTK is built using the bundled libdecor, everything related to titlebars is inserted in

libfltk.a (or libfltk.so). With configure, there's no other way to proceed.

2) If FLTK is built with CMake and OPTION_USE_SYSTEM_LIBDECOR,

all apps get dynamically linked to libdecor-0.so.0 which belongs to package libdecor-0-0.
That package recommends another package, libdecor-0-plugin-1-cairo, containing

libdecor-cairo.so that libdecor-0.so.0 calls upon to draw all window titlebars.

This last dynamic library is what libdecor calls its plugin, and is what may, in the future,

be provided by other, alternative means.

If libdecor-0.so.0 is not found by CMake, OPTION_USE_SYSTEM_LIBDECOR gets turned off,

so the FLTK library follows case 1) above.

[Manolo]

I'd have written "premature" instead of "unwise".

The libdecor packages are available in the testing and unstable Debian versions but not in stable.

As for Ubuntu, they're only in Jammy, the next release.

[imacarthur]

So... I don't know anything about Wayland, really, so what follows may be irrelevant or nonsense but...

In my (scant) understanding I had somehow imagined that libdecor allowed to fltk to do window decorations IFF the active WM was not doing them - but that is not the case?

- If the WM is doing window decoration - how does that interact with fltk using libdecor? 

- If fltk is compiled *with* libdecor, will it use that for window decoration regardless of what the WM is doing? Does that mean the window decorations will then *not match* the WM styling?

- Or, regardless of whether fltk "has" libdecor compiled in or not, will it detect and use the host WM decoration service, IF it is available?

I obviously have not grasped this yet!

[Manolo]

That's what FLTK, or libdecor really, does.

- When the Wayland compositor (there's no longer a WM with Wayland) proposes to draw window titlebars, libdecor and FLTK

rely on the compositor for all titlebars. This happens with KDE.

- When the compositor doesn't provide this service, FLTK uses libdecor (which itself relies on its libdecor-cairo plugin)

to draw all window titlebars. This happens with the gnome compositor named Mutter,  and with Weston.

The choice between these 2 behaviours is independent from whether libdecor is bundled in libfltk or is a system shared lib.

The choice is done at run-time : a single binary will adopt one of the 2 behaviours when run in presence of different Wayland compositors.

[Bill Spitzak]

I'm still thoroughly confused, as there are dlload calls in the fltk code for wayland titlebars. This implies it is code to LOAD a "plugin". If it is not capable of loading a system-provided plugin that draws the titlebars then something is seriously wrong. This should not be a compile-time option if one of the options contains a dlload call.

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/ffbe886b-0768-476a-90d4-debb4b7d1869n%40googlegroups.com.

[Manolo]

Le lundi 17 janvier 2022 à 21:16:23 UTC+1, spi...@gmail.com a écrit :

I'm still thoroughly confused, as there are dlload calls in the fltk code for wayland titlebars. This implies it is code to LOAD a "plugin". If it is not capable of loading a system-provided plugin that draws the titlebars then something is seriously wrong. This should not be a compile-time option if one of the options contains a dlload call.

I've a hard time understanding the meaning of this paragraph. Does it refer to the dlopen() call at line 1383 of

file <FLTK source tree>/libdecor/src/libdecor.c ?

The relationship between FLTK and libdecor is exactly the same as that with libpng or libjpeg. FLTK can be built relying on

the system to provide libpng.so or libjpeg.so. Or, if that is not desired for any reason, it can be built using a built-in version

of any of these 2 libs.

If FLTK uses its built-in copy of libdecor, the code path doesn't go to the dlopen() call mentionned above. The code path goes

always to the built-in libdecor-cairo.c which draws all window titlebars and shades.

If FLTK uses the system-provided libdecor shared lib, obviously libdecor.so determines what happens. Libdecor uses a plugin

mechanism to load, via the dlopen() call seen above, another shared lib that implements a small libdecor-defined

API and that does the titlebar drawing job. There's also a libdecor-defined mechanism to determine where libdecor.so

searches for this plugin. At present and to the best of my knowledge, no other shared lib exists than libdecor-cairo.so

which uses Cairo to draw titlebars (with a big fontsize, too big according to some).

At present, the net result is the same in terms of window titlebars because ultimately libdecor-cairo.c does

the drawing in both cases.

If the running Wayland compositor provides SSD (server-side decoration), and independently of whether the system

or the built-in libdecor versions run, no plugin is necessary because the compositor draws titlebars. That can be

put in action running FLTK with the KDE desktop.

[Bill Spitzak]

I would call anything you dlopen a "plugin". What I call a "library" is directly named by the executable (you can list them on Linux with ldd) and is loaded before the executable is run.

The fact that this plugin when run then dlopen's even more files (as it's own internal plugin system) is not relevant for fltk.

I think the proper behavior for fltk is it should try to load this plugin (what you call the system-provided libdecor, I think). In theory a desktop would customize this file if they think it is important for titlebars to be consistent. If not found, fltk could fallback to drawing the titlebar itself, though I would like an investigation as to whether any proper wayland implementation is missing a plugin.

I do not understand why any of this is a compile-time option, unless one of the options is to *remove* the dlopen and use the fallback always. Even if that is the case, the no-plugin case should not be the default.

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/4bb47d18-0d77-4f02-96e7-4cd2fedae749n%40googlegroups.com.

[Manolo]

Le mardi 18 janvier 2022 à 18:40:43 UTC+1, spi...@gmail.com a écrit :

I would call anything you dlopen a "plugin". What I call a "library" is directly named by the executable (you can list them on Linux with ldd) and is loaded before the executable is run.

I fully agree.  With FLTK and Wayland, we have the same situation as with PNG: either the PNG code is compiled and put

into libfltk_png.a or .so, or the system's libpng.so is used. No dlopen involved. Thus, the libdecor code is either compiled and put into

libfltk.a or .so or the system's libdecor.so is used. No dlopen involved. Only static or dynamic linking done at build time.

The fact that this plugin when run then dlopen's even more files (as it's own internal plugin system) is not relevant for fltk.

Yes, at the FLTK level, there's no plugin, no dlopen called by FLTK. It's only when FLTK links to libdecor.so that dlopen is called

by libdecor.so to recruit another shared lib, libdecor-cairo.so.

 

I think the proper behavior for fltk is it should try to load this plugin (what you call the system-provided libdecor, I think). In theory a desktop would customize this file if they think it is important for titlebars to be consistent. If not found, fltk could fallback to drawing the titlebar itself, though I would like an investigation as to whether any proper wayland implementation is missing a plugin.

My understanding is that the Gnome people have decided to stop thinking about a system-level titlebar when they decided to go for CSD

(client-side decoration) : the client decorates its own windows. Gnome provides a toolkit that allows to construct CSD-adapted windows. If you use another toolkit, and FLTK is in that case, you're on your own: Gnome offers no decoration you could use without entering in GTK.

That's where libdecor is convenient because it fills this hole proposing to decorate windows.

I believe Gnome is a proper Wayland implementation that contains no plugin to decorate consistently windows. Only very recent Debian

versions have the libdecor package (it's not yet in Ubuntu) which decorates windows but not especially consistently with the desktop.

My understanding is also that this is not intrinsic to Wayland, because the KDE people have decided to go for SSD : KDE provides

a consistent decoration to windows. Libdecor is aware of that and calls on the Wayland compositor whien it runs on KDE.

It's enough for FLTK to use properly the libdecor API to itself adopt SSD when run on KDE.

 

I do not understand why any of this is a compile-time option, unless one of the options is to *remove* the dlopen and use the fallback always. Even if that is the case, the no-plugin case should not be the default.

Dynamically linking libfltk with libdecor is an option because, as I wrote, libdecor is present only on some extremely recent Linux versions, not yet on any released Ubuntu version. We could make this option ON by default instead of OFF because the option turns itself OFF when

libdecor-0-0.so isn't found at build time. There were also issues about bugs in libdecor that I could fix using the bundled libdecor version,

but this should be fixed soon in the libdecor gitlab repository..

 

[Bill Spitzak]

Since it is on Linux, it may be safe to just have libdecor be a build requirement for fltk, assuming it is available as a project that the user can build on systems that it is missing from.

I would very much like to get rid of the copy of jpeg and png code that is in fltk. This is a very bad idea. Better solutions for Windows are to statically link them along with fltk into executables, or to rewrite fltk so on Windows it does not use these libraries, Windows has it's own libraries for reading image files.

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/bfe6920b-3344-4531-94a5-78f27c613ff4n%40googlegroups.com.

[Manolo]

Le mardi 18 janvier 2022 à 22:28:49 UTC+1, spi...@gmail.com a écrit :

Since it is on Linux, it may be safe to just have libdecor be a build requirement for fltk, assuming it is available as a project that the user can build on systems that it is missing from.

 The problem with making libdecor a build requirement for fltk is that libdecor is to be built using ninja and meson,

so this makes 2 large additional requirements. My view was that adding a few .c and .h files to the FLTK source tree

was preferable. What do you think?

[Lauri Kasanen]

On Tue, 18 Jan 2022 13:28:36 -0800
Bill Spitzak <spi...@gmail.com> wrote:

> Since it is on Linux, it may be safe to just have libdecor be a build
> requirement for fltk, assuming it is available as a project that the user
> can build on systems that it is missing from.

Please no. Nobody uses Wayland yet (statistically), and you want to
force a wayland-only dep on X11 platforms.

I also agree with Manolo on its onerous build system requirements.

- Lauri

[Albrecht Schlosser]

I agree that bundling the source files is preferable, at least as long as libdecor is not yet stable (enough) and we can't be sure that it is available on all Wayland platforms.

[Manolo]

Le mercredi 19 janvier 2022 à 09:01:37 UTC+1, ca...@gmx.com a écrit :

On Tue, 18 Jan 2022 13:28:36 -0800
Bill Spitzak <spi...@gmail.com> wrote:

> Since it is on Linux, it may be safe to just have libdecor be a build
> requirement for fltk, assuming it is available as a project that the user
> can build on systems that it is missing from.

Please no. Nobody uses Wayland yet (statistically), and you want to
force a wayland-only dep on X11 platforms.

There might be a misunderstanding here. What is discussed is a potential build

requirement for the Wayland platform of FLTK. In all scenarios, the X11 platform

of FLTK remains unchanged and unconcerned.

[Bill Spitzak]

Okay I think I understand. "libdecor" is code that is supposed to load a plugin, and this is the code included with fltk. That seems acceptable, in particular because it allows libdecor to be modified to fit better with fltk (I would like to see whatever changes are necessary so the fltk and titlebar are drawn into the same image buffer). It is unfortunate there is only one plugin to test it against so initially it is probably safest to not modify libdecor much, but it can be done in the future.

It is possible that a version that supports Wayland, but can use X11 when Wayland is not available (for instance on a remote display), would be what is most useful. Still need compile-time options to make only-X11 and only-Wayland versions but this may be the best "Wayland" version. The first step is to make the X11 version use Cairo though.

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/1e57e34a-b741-48e5-800b-788f15da2d4en%40googlegroups.com.

[Albrecht Schlosser]

On 1/19/22 7:14 PM Bill Spitzak wrote:

It is unfortunate there is only one plugin to test it against so initially it is probably safest to not modify libdecor much, but it can be done in the future.

Christian Rauch wrote in the FLTK channel on Matrix (or IRC),
Link: https://matrix.to/#/!eTrnuPUpwfBOSUEOyI:matrix.org/$nKLX0FRIntQ6kQjEHJH7clmI7FFNDyja2fK_anpwcLE?via=grin.hu&via=matrix.org&via=systemtest.tk

```
Hey, I saw the "announcement" that there is Wayland support in progress. I am contributing to libdecor and I thought I might be able to answer some questions here.
There seems to be some confusion what a libdecor plugin and what it does. The idea behind the plugins is that desktop environments can provide plugins that match the visual style of the desktop. Right now, we only have the desktop agnostic "cairo" plugin. But there is a GTK plugin (https://gitlab.gnome.org/jadahl/libdecor/-/merge_requests/43) on the way that is then supposed to be used for GTK based desktops, such as GNOME Shell. This plugin will integrate visually much better in GNOME than the cairo plugin.

GTK plugin the cairo way (!43) · Merge requests · Jonas Ådahl / libdecor - GitLab
```
(End of citation).

I'm not sure how much and in what timeframe this may help, but anyway. I looks like there will be a GTK plugin available in the future.
 

It is possible that a version that supports Wayland, but can use X11 when Wayland is not available (for instance on a remote display), would be what is most useful. Still need compile-time options to make only-X11 and only-Wayland versions but this may be the best "Wayland" version. The first step is to make the X11 version use Cairo though.

I agree that it would be good to have a "hybrid" FLTK library that can choose between Wayland and X11 but the first step (sic!) would be to integrate Wayland support as a build-time option.

As Manolo wrote this would offer the FLTK Cairo driver "for free" because it's use by the Wayland port. If it is doable then this would enable us to switch between X11 drawing and Cairo drawing in the "X11 build". Again, I think in a first step as a build option and maybe later as the default or only option (I mean: using Cairo on X11).

The problem in using Cairo under X11 is very likely that some platforms (embedded systems) might not be able to use Cairo for some reasons. Some platforms do not even use full X11 but use nano-X or similar. I don't think that we want to remove FLTK support from these platforms.

But anyway, the "first step" can not be "to make the X11 version use Cairo".

[Manolo]

The wayland branch has now been extended with Christian Rauch's GTK-based titlebar drawing machinery mentionned above.

To activate it, leave CMake's OPTION_USE_SYSTEM_LIBDECOR off, and build FLTK.

The result shows in the attached screenshot.

[Manolo]

Here is how unchanged FLTK apps draw window titlebars with 3 Gnome appearances

(appearances are set via the Tweaks utility) :

[Bill Spitzak]

Sorry I really don't understand what is going on. What I expect is simply causing this GTK libdecor plugin to *exist* on your machine would cause it to be used. There absolutely should not be any need to recompile fltk. And I would think the option "USE_SYSTEM_LIBDECOR" is irrelevant, as either the code in fltk or the code in the shared library should load the plugin. Can anybody explain just what is happening here?

On Thu, Jan 20, 2022 at 7:21 AM Manolo <manol...@gmail.com> wrote:

Here is how unchanged FLTK apps draw window titlebars with 3 Gnome appearances

(appearances are set via the Tweaks utility) :

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/5e05fa4f-780f-46a6-9bcd-b0bc9b1927d1n%40googlegroups.com.

[Manolo]

Le jeudi 20 janvier 2022 à 19:47:06 UTC+1, spi...@gmail.com a écrit :

Sorry I really don't understand what is going on. What I expect is simply causing this GTK libdecor plugin to *exist* on your machine would cause it to be used. There absolutely should not be any need to recompile fltk. And I would think the option "USE_SYSTEM_LIBDECOR" is irrelevant, as either the code in fltk or the code in the shared library should load the plugin. Can anybody explain just what is happening here?

Today, the code for GTK-style titlebar drawing exists only as Merge Request #43 to the gitlab repository of libdecor.

We just can't expect any FLTK user to have it in the form of a shared library on her computer.

In order for me, and others, to see how it works and whether FLTK is ready to draw window titlebars with it,

I have downloaded the code and copied to <fltk source tree>/libdecor the single relevant change,

the new file libdecor/src/plugins/gtk/libdecor-gtk.c. I have further arranged for FLTK to use this code

instead of the previous in libdecor/src/plugins/cairo/libdecor-cairo.c to draw titlebars.

That is the solution I found that is compatible with the present state of this new piece of code.

In the future :

1) hopefully, Merge Request #43 will be accepted by libdecor's author and merged into the libdecor master

branch;

2) at some time point later, the libdecor Linux packages will be updated following libdecor's update

and FLTK users will be able to turn ON OPTION_USE_SYSTEM_LIBDECOR and rebuild FLTK

and get the same result, GTK-styled window titlebars.

This solution allows FLTK to get the final result without having to wait for these events.

We can plan to, when the libdecor package and its GTK plugin will be available to Linux systems,

make OPTION_USE_SYSTEM_LIBDECOR be ON by default and to make libdecor a recommended

dependance of the Wayland platform of FLTK.

[Bill Spitzak]

What I don't understand is why you are not actually testing a *plugin*. The code for drawing using GTK should not be part of fltk. IMHO the code in fltk should look for the libdecor plugin and if found load it and use it. If not found then there could be a fallback, probably using a copy of the decor-cairo code, or even something simpler using fltk drawing functions.

Unless we are actually loading plugins that dlload code is *not* being tested and that is wrong.

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/f2537cfd-60da-4a77-98a6-c97043155f38n%40googlegroups.com.

[Manolo]

Le jeudi 20 janvier 2022 à 21:51:55 UTC+1, spi...@gmail.com a écrit :

What I don't understand is why you are not actually testing a *plugin*. The code for drawing using GTK should not be part of fltk. IMHO the code in fltk should look for the libdecor plugin and if found load it and use it. If not found then there could be a fallback, probably using a copy of the decor-cairo code, or even something simpler using fltk drawing functions.

Unless we are actually loading plugins that dlload code is *not* being tested and that is wrong.

It works. I did this :

- build with meson + ninja the libdecor software containing the libdecor-gtk.c addition;

- this creates 3 shared libs: libdecor-0.so, libdecor-cairo.so, libdecor-gtk.so.

The last 2 are plugins, one of which is loaded by dlopen() by the 1st shared lib.

- define environment var LIBDECOR_PLUGIN_DIR to the directory containing libdecor-gtk.so

(this variable is the means for libdecor to discover its plugin)

- re-build FLTK with OPTION_USE_SYSTEM_LIBDECOR set to ON

- run an FLTK app: its window appears in GTK-style.

Events are :

libfltk calls libdecor which is found in libdecor-0.so, that from the Debian package libdecor-0;

libdecor-so loads with dlopen() the plugin it finds in $LIBDECOR_PLUGIN_DIR,

this plugin, libdecor-gtk.so, draws a GTK-styled window titlebar.

I believe that's not a procedure adequate for public use because it requires to download a modified

version of libdecor according to a pending Merge Request and to use meson + ninja.

That procedure should become practical once the code in the merge request will have found its way

up into Linux packages.

[Bill Spitzak]

It sounds like the GTK required a modification to libdecor, I'm guessing they wanted the API to the plugin altered? Was it a major change, or only a minor addition?

My vague impression is the best method for fltk is to implement this api (by including the source code to libdecor) on the assumption that it will be able to load more plugins than the unmodified one. However I don't think fltk should include any plugins, instead there should be a compiled-in fallback that is used if the plugin could not be found or does not load. This will allow a statically-linked fltk program to be distributed as a single executable. This fallback probably should be extremely simple though it should draw the window title text at least.

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/7a672a3f-19a2-40c5-b430-27758f9b19c3n%40googlegroups.com.

[Manolo]

Le vendredi 21 janvier 2022 à 06:33:55 UTC+1, spi...@gmail.com a écrit :

It sounds like the GTK required a modification to libdecor, I'm guessing they wanted the API to the plugin altered? Was it a major change, or only a minor addition?

The 2 plugins use exactly the same API in their communication with libdecor.

The single change to libdecor was the addition of one source file libdecor-gtk.c.

That's reflected in the fact that FLTK with OPTION_USE_SYSTEM_LIBDECOR to ON, which uses the libdecor-0.so of the Debian package

and dlopen's libdecor-gtk.so of the GTK-extended modified libdecor source code, runs well.

My vague impression is the best method for fltk is to implement this api (by including the source code to libdecor) on the assumption that it will be able to load more plugins than the unmodified one. However I don't think fltk should include any plugins, instead there should be a compiled-in fallback that is used if the plugin could not be found or does not load.

We agree on that, for a future situation when GTK-styled plugins will be available to FLTK users.

This will allow a statically-linked fltk program to be distributed as a single executable. This fallback probably should be extremely simple though it should draw the window title text at least.

I'd say that libdecor-cairo.c  does an excellent fallback mechanism.

There remains an issue. FLTK needs access to the pixel array of the titlebar to implement features that draw decorated windows.
That's not part of the libdecor public API.

I've put in libfltk a function that gives access to this pixel array for the cairo-style titlebars and another one for the GTK-style ones.
The problem is that libfltk needs to know which one to use.

Practically, access to the pixels of window titlebars doesn't work now with OPTION_USE_SYSTEM_LIBDECOR to ON and with the

GTK-style plugin because it uses the function adequate for the other plugin. Everythink works with OPTION_USE_SYSTEM_LIBDECOR

turned OFF.

The ideal solution for us would be for libdecor to add one piece to its public API: access to the pixel array of a window titlebar.

[Manolo]

The same app run with 2 values of the environment var LIBDECOR_PLUGIN_DIR

so FLTK dlopen()'s either libdecor-cairo.so (left) or lidbdecor-gtk.so (right).

[Albrecht Schlosser]

On 1/21/22 6:33 AM Bill Spitzak wrote:

It sounds like the GTK required a modification to libdecor, I'm guessing they wanted the API to the plugin altered? Was it a major change, or only a minor addition?

Bill, I posted a description from Christian Rauch (libdecor contributor) and links ~2 days ago.
https://gitlab.gnome.org/jadahl/libdecor/-/merge_requests/43

From what I remember the libdecor plugin does not only draw the title bar, it also needs to react on events (highlighting the buttons etc.) which seems to have been a not so minor addition. The primary merge request has been created 11 months ago and they are still working on it. There have been several commits since ...

My vague impression is the best method for fltk is to implement this api (by including the source code to libdecor) on the assumption that it will be able to load more plugins than the unmodified one. However I don't think fltk should include any plugins, ...

From what I read I think the intention of the libdecor developers is that distributions or desktop systems provide plugins that integrate with different themes of the desktop system. However, as we can see, there's only one plugin yet (Cairo) and we know of one additional plugin (GTK) in development.

What Manolo is doing now is to try to get FLTK going with Wayland and libdecor in its current state. I'm sure this can be modified later.

In the future, when Wayland is more common and more desktop environments have implemented their own libdecor plugins I'm sure that we can use (load) such plugins if they are available on the user's system, and as Manolo demonstrated, the plugin loading mechanism works in his test environment.

I agree 100% with Manolo that we need a first step to get us going. Bundling the (modified) libdecor with FLTK is IMHO absolutely appropriate until we have a better solution.

@Manolo: Great job, thanks.

[Manolo]

I've now tried libdecor-gtk with the KDE compositor which provides titlebars

(Server-Side Decoration, a.k.a.SSD mode).

My conclusion is that libdecor-gtk is not compatible with SSD at this point.

This has several consequences

1) libdecor-cairo is to be used in SSD situation (e.g., with the KDE desktop)

2) libdecor-gtk can be used only as a plug-in loaded by dlopen(), because

it's not possible to link both libdecor-cairo and libdecor-gtk in the same executable

since they define at least once the same symbol. Thus, libdecor-gtk can be used only

with CMake  OPTION_USE_SYSTEM_LIBDECOR turned ON. Thus it can't be a public

option for FLTK users, only something for development of the Wayland platform.

3) Ultimately, it won't be possible to show nice GTK-style FLTK window titlebars

until libdecor-gtk is made compatible with the SSD mode by its author.

Alternatively,  build with OPTION_USE_SYSTEM_LIBDECOR should create

2 shared objects, libdecor-cairo.so and libdecor-gtk.so and environment var

LIBDECOR_PLUGIN_DIR could be used for libfltk to find and dlopen() one of them.

4) I still have to find how to prevent libdecor-gtk.so from being loaded when

the compositor is SSD.

[Bill Spitzak]

IMHO fltk should just include linked-in fallback code to draw titlebars if it is unable to load the libdecor plugin, which it should try to locate using whatever rules libdecor specifies for finding it. It sounds like the cairo version is close enough to be used as the first version of the fallback.

It also seems like libdecor should deal with SSD *before* loading the plugin, it should not matter what the plugin does if SSD is being used. May want to check what is going wrong there.

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/b67c7600-c624-44e4-84ac-48ca4dac762dn%40googlegroups.com.

[Manolo]

Le samedi 22 janvier 2022 à 18:57:18 UTC+1, Manolo a écrit :

I've now tried libdecor-gtk with the KDE compositor which provides titlebars

(Server-Side Decoration, a.k.a.SSD mode).

My conclusion is that libdecor-gtk is not compatible with SSD at this point.

That conclusion was too hasty. libdecor-gtk.c has been now made compatible

with SSD mode and with Weston. With that, FLTK windows get GTK-style titlebars

by default.

[Bill Spitzak]

Does that plugin link in GTK?

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/c3af013c-1e66-4ce5-b152-7f5679b6f712n%40googlegroups.com.

[Manolo]

Le mardi 25 janvier 2022 à 21:29:56 UTC+1, spi...@gmail.com a écrit :

Does that plugin link in GTK?

Yes. The GTK plugin uses libgtk-3.0.so . If GTK is absent at build time, the cairo plugin is used instead

which does not use libgtk.

[Bill Spitzak]

My preference is that it should load this plugin if it is found in it's correct installed location. Code for the gtk plugin not be included in fltk. The plugin should be provided by the desktop environment.

It should also load the cairo plugin if it is found in it's correct installed location and fltk should not compile this code as a plugin.

There has to be some fallback code if the plugins are missing. It sounds like it is easiest to use the cairo code for this, but it can't be a plugin, since it may be missing just like any other one. A statically-linked fltk program must still work if the executable file by itself is copied to another machine (it can require various shared libraries to be installed on that machine, but no other fltk code). So the fallback must be code actually linked in the fltk library.

It was still useful to check if the gtk plugin works however.

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/6b4dc011-f96a-4599-a6e2-3bb0d5720457n%40googlegroups.com.

[Gonzalo Garramuño]

On 4/1/22 13:07, Manolo wrote:
> I'd like to invite fellow FLTK developers to vote about
> adding a Wayland platform to the FLTK library.
> ++++++++++++++++
> Manolo
>
>
> The candidate code 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 install on any Wayland-running Linux system.
> It's been tested on Debian and Ubuntu.
> The new code contains no change to platform-independent FLTK code;
> it's therefore completely compatible with extant FLTK user code.
>
> Major features of the Wayland branch
I followed the Debian/Ubuntu instructions but cannot see a Wayland
protocol on log-in.   I only have Ubuntu and Gnome.

[Manolo]

Le mercredi 26 janvier 2022 à 16:20:49 UTC+1, ggar...@gmail.com a écrit :

I followed the Debian/Ubuntu instructions but cannot see a Wayland
protocol on log-in.   I only have Ubuntu and Gnome.

In a reasonably recent Ubuntu version, Wayland is installed by default.
But you have to make sure you don't use the traditional, no-wayland version of gnome.

For this, you have to click on your name in the login window, then, before entering the password

click the small wheel at bottom right. This opens a popup where you should select Ubuntu.
At that point, you're good.

You just have to git clone my fork of fltk, git checkout its wayland branch, and type

autoconf -f

./configure --enable-wayland

make

[Gonzalo Garramuño]

On 26/1/22 15:54, Manolo wrote:
> In a reasonably recent Ubuntu version, Wayland is installed by default.
> But you have to make sure you don't use the traditional, no-wayland
> version of gnome.

I had Ubuntu 20.04 beta upgraded to latest (as Ubuntu 20.04.3 would not
work on my nvidia card) and Ubuntu 21.10 (impish). Neither have the
login button you mention.

[Albrecht Schlosser]

I checked my wayland related packages and I believe you need to install
gnome-session-wayland if it is not installed.

$ apt list --installed | grep wayland

$ sudo apt install gnome-session-wayland


If it is installed on your system, ISTR that there was a conflict in a
system setup file but I don't remember the details. I do remember though
that I found a solution by internet search that resulted in removing or
renaming a symbolic link related to Gnome and/or Wayland or X "session".
This may be good keywords for a search.

Maybe this link can help too:
https://stackoverflow.com/questions/31213773/how-to-start-gnome-wayland-session-from-command-line-tty

Good luck!

All testers are welcome!

[Gonzalo Garramuño]

On 26/1/22 21:33, Albrecht Schlosser wrote:
> On 1/27/22 01:10 Gonzalo Garramuño wrote:
>>
>> On 26/1/22 15:54, Manolo wrote:
>>> In a reasonably recent Ubuntu version, Wayland is installed by default.
>>> But you have to make sure you don't use the traditional, no-wayland
>>> version of gnome.
>>
>> I had Ubuntu 20.04 beta upgraded to latest (as Ubuntu 20.04.3 would
>> not work on my nvidia card) and Ubuntu 21.10 (impish). Neither have
>> the login button you mention.
>>
>
> I checked my wayland related packages and I believe you need to
> install gnome-session-wayland if it is not installed.
>

Okay.   Here's what I had to do.  I had to do a fresh install of Ubuntu
20.04.3 making sure the custom drivers were disabled (so that it would
not mess with my nvidia card).  After that, I indeed got the button
inviting me to Wayland.

I can now begin my testing.  Thanks to all that participated.

[Gonzalo Garramuño]

On 26/1/22 15:54, Manolo wrote:

I get the following when running make:

=== making libdecor/build ===

make[1]: wayland-scanner: Command not found
make[1]: *** [Makefile:46: ../../src/xdg-shell-protocol.c] Error 127
make: *** [Makefile:22: all] Error 1

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/0013e444-b09a-4c2b-b993-7aa69a1b37a3n%40googlegroups.com.

[Gonzalo Garramuño]

On 26/1/22 15:54, Manolo wrote:

Never mind.  I did a git pull and all is now fine.

[Gonzalo Garramuño]

> --
>
I am having trouble obtaining and compiling libdecor.   I went to fltk's
libdecor build directory and run make and I got:

../src/plugins/cairo/libdecor-cairo.c:44:10: fatal error:
pango/pangocairo.h: No such file or directory

#include <pango/pangocairo.h>

I have libpangocairo-1.0-0, but there's no -dev package I could find.

[Albrecht Schlosser]

On 1/27/22 19:36 Gonzalo Garramuño wrote:

On 21/1/22 05:00, Manolo wrote:

The same app run with 2 values of the environment var LIBDECOR_PLUGIN_DIR
so FLTK dlopen()'s either libdecor-cairo.so (left) or lidbdecor-gtk.so (right).
-- 

I am having trouble obtaining and compiling libdecor.   I went to fltk's libdecor build directory and run make and I got:

../src/plugins/cairo/libdecor-cairo.c:44:10: fatal error: pango/pangocairo.h: No such file or directory

You shouldn't need to do this nor are you expected to do it. This should be done automatically in the build process.

#include <pango/pangocairo.h>

I have libpangocairo-1.0-0, but there's no -dev package I could find.

$ egrep 'pango|cairo' README.Wayland.txt
- libpango1.0-dev
- libcairo2-dev

Did you install all required packages from the list in README.Wayland.txt?

PS: I recommend strongly to build the wayland branch using CMake rather than configure/make when you're testing the wayland branch. Dependencies in configure/make builds are always flawed and incomplete in our current branches. This is particularly true if you are building FLTK on the bleeding edge! CMake however has its own built-in and reliable dependency system.

[Greg Ercolano]

On 1/27/22 10:36, Gonzalo Garramuño wrote:

I have libpangocairo-1.0-0, but there's no -dev package I could find.

    Based on my ubuntu 20.x box, perhaps this is what you need? (not sure)

$ apt search libpango | grep dev
[..]
libpango1.0-dev/focal,now 1.44.7-2ubuntu4 amd64 [installed,automatic]
[..]

[Gonzalo Garramuño]

On 27/1/22 16:05, Albrecht Schlosser wrote:

On 1/27/22 19:36 Gonzalo Garramuño wrote:

On 21/1/22 05:00, Manolo wrote:

The same app run with 2 values of the environment var LIBDECOR_PLUGIN_DIR
so FLTK dlopen()'s either libdecor-cairo.so (left) or lidbdecor-gtk.so (right).
-- 

I am having trouble obtaining and compiling libdecor.   I went to fltk's libdecor build directory and run make and I got:

../src/plugins/cairo/libdecor-cairo.c:44:10: fatal error: pango/pangocairo.h: No such file or directory

You shouldn't need to do this nor are you expected to do it. This should be done automatically in the build process.

But it isn't.  libdecor/ ends up being an empty directory with three subdirs (build, src and demo).

#include <pango/pangocairo.h>

I have libpangocairo-1.0-0, but there's no -dev package I could find.

$ egrep 'pango|cairo' README.Wayland.txt
- libpango1.0-dev
- libcairo2-dev

Did you install all required packages from the list in README.Wayland.txt?

Yes.

PS: I recommend strongly to build the wayland branch using CMake rather than configure/make when you're testing the wayland branch. Dependencies in configure/make builds are always flawed and incomplete in our current branches. This is particularly true if you are building FLTK on the bleeding edge! CMake however has its own built-in and reliable dependency system.

Okay.  I built it like that, but there's no libdecor anywhere to be found.

[Greg Ercolano]

On 1/27/22 11:17, Gonzalo Garramuño wrote:

Okay.  I built it like that, but there's no libdecor anywhere to be found.

    Just a guess from the sidelines:

$ apt search libdecor | grep libdecor
[..]
libdecoration0-dev/focal 1:0.9.14.1+20.04.20200211-0ubuntu1 amd64
[..]

[Gonzalo Garramuño]

No, it's different.

[0/1] Re-running CMake...
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Checking for module 'libdecor-0'
--   No package 'libdecor-0' found

[Manolo]

1) libdecoration and libdecor and 2 different things

2) don't try to search a libdecor package under Ubuntu. It doesn't exist yet. It's available

under very recent Debian.

3) That's why libdecor is also bundled in the FLTK source tree. FLTK uses that version of libdecor

when building.

4) I just repeated now under Ubuntu 21.10 this :

git clone    https://github.com/ManoloFLTK/fltk.git    fltk

cd fltk

git checkout wayland

autoconf -f

./configure --enable-wayland

make

and all ran well.

[Albrecht Schlosser]

On 1/27/22 20:17 Gonzalo Garramuño wrote:
> On 27/1/22 16:05, Albrecht Schlosser wrote:
>> On 1/27/22 19:36 Gonzalo Garramuño wrote:
>>>
>>> On 21/1/22 05:00, Manolo wrote:
>>>> The same app run with 2 values of the environment var
>>>> LIBDECOR_PLUGIN_DIR
>>>> so FLTK dlopen()'s either libdecor-cairo.so (left) or
>>>> lidbdecor-gtk.so (right).
>>>> --
>>>>
>>> I am having trouble obtaining and compiling libdecor.   I went to
>>> fltk's libdecor build directory and run make and I got:
>>>
>>> ../src/plugins/cairo/libdecor-cairo.c:44:10: fatal error:
>>> pango/pangocairo.h: No such file or directory
>>
>> You shouldn't need to do this nor are you expected to do it. This
>> should be done automatically in the build process.
>>
> But it isn't.  libdecor/ ends up being an empty directory with three
> subdirs (build, src and demo).
>

libdecor is not built as a distinct library, all required files are
compiled into libfltk. You can see the result running this after the build

$ nm --demangle lib/libfltk.a | grep libdecor

which yields 176 hits in my Debian/FLTK/Wayland build.

What are your errors?

[Greg Ercolano]

On 1/27/22 11:48, Manolo wrote:

1) libdecoration and libdecor and 2 different things

    Ah, good to know -- thanks!

[Gonzalo Garramuño]

On 27/1/22 17:03, Albrecht Schlosser wrote:
> libdecor is not built as a distinct library, all required files are
> compiled into libfltk. You can see the result running this after the
> build
>
> $ nm --demangle lib/libfltk.a | grep libdecor
>
> which yields 176 hits in my Debian/FLTK/Wayland build.
>
> What are your errors?
>

Ah, I see. No errors then.  Just that I don't see the difference of
compiling with libdecor and without.

[Gonzalo Garramuño]

On 27/1/22 17:03, Albrecht Schlosser wrote:
>

> What are your errors?
>
I get the following error upon running my appplication:

Xlib:  extension "MIT-SCREEN-SAVER" missing on display ":0".

[Gonzalo Garramuño]

On 27/1/22 17:03, Albrecht Schlosser wrote:
>
> What are your errors?
>

When I compiled the new fltk with my program, I got the following errors:

23 | extern struct wl_display *fl_display;
      |               ^~~~~~~~~~
../../../../mrViewer/src/gui/mrvMainWindow.cpp:191:16: error: cannot
convert ‘wl_display*’ to ‘Display*’ {aka ‘_XDisplay*’}
  191 |     XSendEvent(fl_display,
      |                ^~~~~~~~~~
      |                |
      |                wl_display*
In file included from /usr/include/X11/extensions/scrnsaver.h:33,
                 from ../../../../mrViewer/src/gui/mrvMainWindow.cpp:34:
/usr/include/X11/Xlib.h:3136:5: note:   initializing argument 1 of ‘int
XSendEvent(Display*, Window, int, long int, XEvent*)’
 3136 |     Display*  /* display */,

In file included from /usr/local/include/FL/platform.H:41,
                 from ../../../../mrViewer/src/gui/mrvMainWindow.cpp:49:
/usr/local/include/FL/wayland.H:23:15: note: class type ‘wl_display’ is
incomplete
   23 | extern struct wl_display *fl_display;

In file included from /usr/include/X11/Xlib.h:44,
                 from /usr/include/GL/glxew.h:98,
                 from ../../../../mrViewer/src/video/mrvGLEngine.cpp:75:
/usr/include/X11/X.h:96:13: error: conflicting declaration ‘typedef XID
Window’
   96 | typedef XID Window;

[Albrecht Schlosser]

That's an unexpected error. 'Xlib' and 'display ":0" ' seem to indicate
that you're running an X application rather than one built for Wayland.

How did you configure your CMake build? It should contain "-D
OPTION_USE_WAYLAND=ON" or a similar command line option. Or you can set
this option in the graphical CMake interface (ccmake or cmake-gui).

OTOH, it may be possible that even the Wayland build needs some X
features (although I would personal hope that this is not the case).
Manolo wrote in README.Wayland.txt:

"These packages are necessary, in addition to those for usual X11-based
platforms..."

I noticed in my own tests (where I deliberately not installed X
libraries) CMake required some libs unexpectedly. I believe this can be
fixed but anyway, it's a test and development branch, so can you please
configure a standard non-Wayland build with CMake (on the same branch)
and see how far this builds well?

I suggest a two-level build directory in the FLTK dir:

$ mkdir -p build/wayland
$ mkdir -p build/x11
$ cd build/wayland
$ cmake -D OPTION_USE_WAYLAND=ON ../..
$ cd ../x11
$ cmake ../..

If you get any errors (missing packages) please install these packages
or report the configure log here.

Here's an old list from one of my Docker files of the packages that may
be needed:

sudo apt update
sudo apt install build-essential autoconf ninja-build
sudo apt install cmake cmake-gui cmake-curses-gui
sudo apt install git gitk git-gui
sudo apt install libpango1.0-dev freeglut3-dev libglew-dev
sudo apt install libjpeg-dev libpng-dev
sudo apt install doxygen-latex

I'm using `ninja` to build (CMake: "-G Ninja") hence "ninja-build".
libjpeg and libpng are optional, as well as doxygen-latex (only if you
want to build the PDF docs).

Anyway, the list above should provide most if not all of the required
packages to build the X11 variant of the FLTK lib.

[Albrecht Schlosser]

On 1/27/22 23:11 Gonzalo Garramuño wrote:

On 27/1/22 17:03, Albrecht Schlosser wrote:

What are your errors?

When I compiled the new fltk with my program,

Oh, does this mean that you could build the FLTK wayland branch successfully?

If yes, we'd be interested in feedback for tests of the standard FLTK test and demo programs. Do they work as expected? Do the window decorations look OK, and does everything behave as expected (maximizing and minimizing of window, resizing, whatever...).


... but then we're certainly also interested in experiences with user programs ...

This looks like your prog includes the wrong (X11) header files rather than the Wayland headers. I didn't try this yet, but here's a guess:

can you please define "FLTK_USE_WAYLAND" somehow on the compiler commandline or your build system?

This *should* be defined in the new file FL/fl_config.h like:

/*
 * FLTK_USE_WAYLAND
 *
 * Do we use Wayland for the current platform?
 *
 */

#define FLTK_USE_WAYLAND 1


Can you please check if you have this file in the FL/ include directory and if FLTK_USE_WAYLAND is defined?

Are you sure your build points at the correct FLTK dirs?

[Albrecht Schlosser]

On 1/27/22 23:32  Albrecht Schlosser wrote:
> On 1/27/22 23:11 Gonzalo Garramuño wrote:
>
> ... but then we're certainly also interested in experiences with user
> programs ...
>
>> I got the following errors:
>>
>> 23 | extern struct wl_display *fl_display;
>>       |               ^~~~~~~~~~
>> ../../../../mrViewer/src/gui/mrvMainWindow.cpp:191:16: error: cannot
>> convert ‘wl_display*’ to ‘Display*’ {aka ‘_XDisplay*’}
>>   191 |     XSendEvent(fl_display,
>>       |                ^~~~~~~~~~
>>       |                |
>>       |                wl_display*
>> In file included from /usr/include/X11/extensions/scrnsaver.h:33,
>>                  from ../../../../mrViewer/src/gui/mrvMainWindow.cpp:34:
>> /usr/include/X11/Xlib.h:3136:5: note:   initializing argument 1 of
>> ‘int XSendEvent(Display*, Window, int, long int, XEvent*)’
>>  3136 |     Display*  /* display */,

Looking closer at this error it seems that your program uses platform
specific code for the X11 platform which is not expected to work in a
Wayland environment.

This will need to be changed but I can't tell what you will need to do.
The best bet for now would be to find those X11 specific pieces or the
code and to comment them out or replace them with something else - just
for testing.

[Albrecht Schlosser]

On 1/27/22 23:32 Albrecht Schlosser wrote:

> ... we're certainly also interested in experiences with user programs ...

[ building a simple user program against the Wayland FLTK lib ]

> I didn't try this yet, ...

OK, done now. I built a small program against the Wayland FLTK library
and it worked flawlessly.

This program is Greg's 'flruler' program
(https://github.com/erco77/flruler) which I'm using frequently. I had
the X11 version already installed on my build system and I can now have
both the X11 and the Wayland versions side by side on the screen.

Hint for testers: to see if a running program runs under X11 (XWayland)
or native Wayland you can run the standard X utility 'xeyes' (sudo apt
install x11-apps) and watch the eyes. If the cursor is inside an X11
window the eyes follow the cursor, otherwise (Wayland window) they don't.

[Gonzalo Garramuño]

On 27/1/22 19:37, Albrecht Schlosser wrote:
>
> This will need to be changed but I can't tell what you will need to
> do. The best bet for now would be to find those X11 specific pieces or
> the code and to comment them out or replace them with something else -
> just for testing.
>

Yes, I commented out all code.  However now I get a linking error:

/usr/bin/ld: /usr/local/lib/libfltk.a(Fl_Wayland_Graphics_Driver.cxx.o):
undefined reference to symbol 'pango_cairo_create_layout'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libpangocairo-1.0.so:
error adding symbols: DSO missing from command line

It seems there's a problem with my pango cairo plugin.

[Albrecht Schlosser]

Hmm, what is your "pango cairo plugin"?

The error message must be interpreted literally: "DSO missing from
command line" means that you need to include the DSO (dynamic shared
object), i.e. libpangocairo-1.0.so in your build command, something like
"-lpangocairo-1.0" or "-lpangocairo-1".

You may now be working with a "newer" system than you're used to and if
this missing DSO does not result from the new Wayland support then this
should be fixed in your "other" system as well. IIRC this error message
is a "new feature", older linkers ignored this.

Library order may also be an issue, link order matters!

[Gonzalo Garramuño]

On 27/1/22 22:50, Albrecht Schlosser wrote:
> On 1/28/22 02:20 Gonzalo Garramuño wrote:
>>
>> On 27/1/22 19:37, Albrecht Schlosser wrote:
>>>
>>> This will need to be changed but I can't tell what you will need to
>>> do. The best bet for now would be to find those X11 specific pieces
>>> or the code and to comment them out or replace them with something
>>> else - just for testing.
>>>
>> Yes, I commented out all code.  However now I get a linking error:
>>
>> /usr/bin/ld:
>> /usr/local/lib/libfltk.a(Fl_Wayland_Graphics_Driver.cxx.o): undefined
>> reference to symbol 'pango_cairo_create_layout'
>> /usr/bin/ld:
>> /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libpangocairo-1.0.so:
>> error adding symbols: DSO missing from command line
>>
>> It seems there's a problem with my pango cairo plugin.
>>
>
> Hmm, what is your "pango cairo plugin"?
>
> The error message must be interpreted literally: "DSO missing from
> command line" means that you need to include the DSO (dynamic shared
> object), i.e. libpangocairo-1.0.so in your build command, something
> like "-lpangocairo-1.0" or "-lpangocairo-1".
>

Yes, I know that.  However, that should be added automatically to my
link line, shouldn't it?

Anyway, I added it, like:

 pangocairo-1.0 pango-1.0 gobject-2.0 cairo glib-2.0

and got a huge list of errors like:

fl_libdecor.c:(.text+0x1e6): undefined reference to `wl_proxy_marshal'
/usr/bin/ld: fl_libdecor.c:(.text+0x1f2): undefined reference to
`wl_proxy_destroy'
/usr/bin/ld: /usr/local/lib/libfltk.a(fl_libdecor.c.o): in function
`xdg_wm_base_get_xdg_surface':
fl_libdecor.c:(.text+0x22e): undefined reference to
`wl_proxy_marshal_constructor'

Oh, well.  I am about to give up.

[Manolo]

You should use `fltk-config --cxxflags --ldflags` within your makefile.

That's the  way FLTK uses to provide a user makefile with flags that depend

on the platform being targeted. Moving from the X11 platform to the Wayland platform,

many flag changes occur.

[Manolo]

Le mercredi 26 janvier 2022 à 00:07:21 UTC+1, spi...@gmail.com a écrit :

My preference is that it should load this plugin if it is found in it's correct installed location. Code for the gtk plugin not be included in fltk. The plugin should be provided by the desktop environment.

It should also load the cairo plugin if it is found in it's correct installed location and fltk should not compile this code as a plugin.

There has to be some fallback code if the plugins are missing. It sounds like it is easiest to use the cairo code for this, but it can't be a plugin, since it may be missing just like any other one. A statically-linked fltk program must still work if the executable file by itself is copied to another machine (it can require various shared libraries to be installed on that machine, but no other fltk code). So the fallback must be code actually linked in the fltk library.

It was still useful to check if the gtk plugin works however.

This is the procedure now used to determine what plugin to use and where to find it :

 By default, FLTK modifies libdecor's libdecor_new() function to determine the plugin as follows :
 1) the directory pointed by environment variable LIBDECOR_PLUGIN_DIR or, in absence of this variable,
    by -DLIBDECOR_PLUGIN_DIR=xxx at build time is searched for a libdecor plugin;
 2) if this directory does not exist or contains no plugin, the built-in plugin is used.
    * if FLTK was built with package libgtk-3-dev, the GTK plugin is used
    * if FLTK was built without package libgtk-3-dev, the Cairo plugin is used
 
 If FLTK was built with OPTION_USE_SYSTEM_LIBDECOR turned ON,  the plugin-searching algorithm

 of libdecor_new() in libdecor-0.so is used.
 This corresponds to step 1) above and to use no titlebar is no plugin is found.
 
 N.B.: only the system package is built with a meaningful value of -DLIBDECOR_PLUGIN_DIR=
 so a plugin may be loaded that way only if FLTK was built with OPTION_USE_SYSTEM_LIBDECOR turned ON.
 

[Gonzalo Garramuño]

Okay, but how do I run that from a CMakeLists.txt file?

[Albrecht Schlosser]

You don't. If you build both FLTK and your own project with CMake you
should do it as described (or similar to that description) in
README.CMake.txt.

I attach my build log of Greg's pretty simle flruler project (one source
file) which includes my CMakeLists.txt (cat ...).

You can also see that I cleared the build directory (rm -rf *) to create
a fresh build and invoked CMake with
'-DFLTK_DIR="/home/albrecht/git/fltk/wayland/build/debug"' which is my
FLTK/Wayland build directory.

I built the project twice for demonstration:

 - with just 'ninja' (which replaces 'make')

- with 'ninja -v' to echo the full build commands.

All the required build flags are defined by the CMake config file
generated by the FLTK library build (with CMake).

This is IMHO the most comfortable and the recommended way to build user
projects using FLTK. It doesn't matter how FLTK was built but you may
need to add other FLTK libs like fltk_images if you need them.

[Gonzalo Garramuño]

On 28/1/22 13:58, Albrecht Schlosser wrote:
> On 1/28/22 17:10 Gonzalo Garramuño wrote:
>>
>> On 28/1/22 12:08, Manolo wrote:
>>> You should use `fltk-config --cxxflags --ldflags` within your makefile.
>>> That's the  way FLTK uses to provide a user makefile with flags that
>>> depend
>>> on the platform being targeted. Moving from the X11 platform to the
>>> Wayland platform,
>>> many flag changes occur.
>>>
>> Okay, but how do I run that from a CMakeLists.txt file?
>
> You don't. If you build both FLTK and your own project with CMake you
> should do it as described (or similar to that description) in
> README.CMake.txt.
>

> This is IMHO the most comfortable and the recommended way to build
> user projects using FLTK. It doesn't matter how FLTK was built but you
> may need to add other FLTK libs like fltk_images if you need them.
>

Ok.  I have my fltk install  in /usr/local.  However, with NO_MODULE set
no libraries are found.


set( FLTK_DIR "/usr/local/" CACHE FILEPATH "FLTK installation or build
dir" )
FIND_PACKAGE( FLTK  REQUIRED NO_MODULE  )    # for window management

if (1)
  message (STATUS "--- Project: ${CMAKE_PROJECT_NAME} ---")
  message (STATUS "FLTK_INCLUDE_DIRS     = '${FLTK_INCLUDE_DIRS}'")
  message (STATUS "FLTK_LIBRARIES        = '${FLTK_LIBRARIES}'")
  message (STATUS "FLTK_FLUID_EXECUTABLE = '${FLTK_FLUID_EXECUTABLE}'")
  message (STATUS "FLTK_USE_FILE         = '${FLTK_USE_FILE}'")
endif ()


OUTPUT:

-- --- Project: Project ---
-- FLTK_INCLUDE_DIRS     =
'/usr/local/include;/usr/include/cairo;/usr/include/glib-2.0;/usr/lib/x86_64-linux-gnu/glib-2.0/include;/usr/include/pixman-1;/usr/include/uuid;/usr/include/freetype2;/usr/include/libpng16'

-- FLTK_LIBRARIES        = '' #### EMPTY
-- FLTK_FLUID_EXECUTABLE = 'fluid'
-- FLTK_USE_FILE         = '/usr/local/share/fltk/UseFLTK.cmake'

[Gonzalo Garramuño]

On 28/1/22 13:58, Albrecht Schlosser wrote:

> On 1/28/22 17:10 Gonzalo Garramuño wrote:
>>
>> On 28/1/22 12:08, Manolo wrote:
>>> You should use `fltk-config --cxxflags --ldflags` within your makefile.
>>> That's the  way FLTK uses to provide a user makefile with flags that
>>> depend
>>> on the platform being targeted. Moving from the X11 platform to the
>>> Wayland platform,
>>> many flag changes occur.
>>>
>

> This is IMHO the most comfortable and the recommended way to build
> user projects using FLTK. It doesn't matter how FLTK was built but you
> may need to add other FLTK libs like fltk_images if you need them.
>

Once I hard-code the libs: fltk, fltk_gl and fltk_images to my project,
the libraries show up.

-lXfixes  -lXcursor  -lXft  -lXrender  -lXss  -lm  -lfontconfig -lXi 
-ldl  -lX11  -lXext  -lpthread  -lXinerama  -lXfixes -lXcursor  -lXft 
-lXrender  -lXss  -lm  -lfontconfig  -lXi -lGLEW  -llzma  -lmp3lame 
-ltheoraenc  -ltheoradec  -ltheora -lvorbisenc  -lvorbis  -lx264  -lvpx 
/usr/local/lib/libfltk.a -ldl  -lpthread  -lpango-1.0  -lpangoxft-1.0 
-lcairo -lpangocairo-1.0  -lgobject-2.0  -lXft  -lfontconfig
-lwayland-egl -lEGL  -lwayland-cursor -lwayland-client -lxkbcommon -ldl
-ldbus-1  -lgtk-3  -lgdk-3  -lpangocairo-1.0  -lpango-1.0 -lharfbuzz 
-latk-1.0  -lcairo-gobject  -lcairo  -lgdk_pixbuf-2.0 -lgio-2.0 
-lgobject-2.0  -lglib-2.0  -no-pie  -lpng  -ljpeg  -lz -ltinyxml2 && :

However I get the following linking error:

Fl_Window.cxx:(.text+0xe09): undefined reference to
`Fl::cairo_make_current(Fl_Window*)'

[Albrecht Schlosser]

On 1/28/22 19:04 Gonzalo Garramuño wrote:

On 28/1/22 13:58, Albrecht Schlosser wrote:

On 1/28/22 17:10 Gonzalo Garramuño wrote:

On 28/1/22 12:08, Manolo wrote:

You should use `fltk-config --cxxflags --ldflags` within your makefile.
That's the  way FLTK uses to provide a user makefile with flags that depend
on the platform being targeted. Moving from the X11 platform to the Wayland platform,
many flag changes occur.

Okay, but how do I run that from a CMakeLists.txt file?

You don't. If you build both FLTK and your own project with CMake you should do it as described (or similar to that description) in README.CMake.txt.

This is IMHO the most comfortable and the recommended way to build user projects using FLTK. It doesn't matter how FLTK was built but you may need to add other FLTK libs like fltk_images if you need them.

Ok.  I have my fltk install  in /usr/local.  However, with NO_MODULE set no libraries are found.

Well, I assumed you used the build folder directly which I always recommend because you can easily change the FLTK build (`git pull; make') and rebuild your application with the changes. I would never install experimental software in the default system location, I'd rather use a separate development directory or whatever. You can specify the install directory in CMake if you really want to install FLTK.

That said, *if* you *install* FLTK in any directory the folder you need to specify is the folder where FLTKConfig.cmake is located (this is generally true, also for the build directory). I believe we need to fix this, but this is how CMake works.

In your case you should specify '/usr/local/share/fltk/' (verify that FLTKConfig.cmake is in that folder) and then it *should* work. Hopefully.

But again, you can avoid that if you use the FLTK build folder for your testing directly.

[Gonzalo Garramuño]

That did not work.

>
> But again, you can avoid that if you use the FLTK build folder for
> your testing directly.
>

That worked for fltk-x11, but it is confusing that FLTK_LIBRARIES is
always empty.  For wayland, I still cannot get a clean build. I get the

following linking error:

Fl_Window.cxx:(.text+0xe09): undefined reference to
`Fl::cairo_make_current(Fl_Window*)'

collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

[Albrecht Schlosser]

On 1/28/22 22:54 Gonzalo Garramuño wrote:

On 28/1/22 15:36, Albrecht Schlosser wrote:

On 1/28/22 19:04 Gonzalo Garramuño wrote:

In your case you should specify '/usr/local/share/fltk/' (verify that FLTKConfig.cmake is in that folder) and then it *should* work. Hopefully.

That did not work.

Why? What error messages do you see? Is the file /usr/local/share/fltk/FLTKConfig.cmake in that folder?

But again, you can avoid that if you use the FLTK build folder for your testing directly.

That worked for fltk-x11, but it is confusing that FLTK_LIBRARIES is always empty.

Yep, sorry, this is a known problem and on my todo list. You should only need to use "fltk" and maybe "fltk_images" which are CMake Targets if you use the NOMODULE approach as described.

I hope that I can fill FLTK_LIBRARIES as well to be backwards compatible.

For wayland, I still cannot get a clean build. I get the following linking error:

Fl_Window.cxx:(.text+0xe09): undefined reference to `Fl::cairo_make_current(Fl_Window*)'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

This is (currently, still) in the library fltk_cairo which you would also have to link but I don't know why this appears in your build. I configured FLTK/Wayland with and w/o (CMake option) OPTION_CAIRO and it didn't happen to me in my `flruler' example project.

Is it possible that your project requires the FLTK Cairo support for your own drawings? And if yes, do you set the FLTK_HAVE_CAIRO macro? If this is true then you might need to configure the FLTK build with OPTION_CAIRO as well and link with the fltk_cairo library.

But note that the fltk_cairo library will be removed soon (the Cairo support code will be in libfltk instead).

Sorry for the inconveniencies and thank you very much for your help. Your problems building your applicaton program will help us to develop FLTK further and help other users later,

Thanks

[Gonzalo Garramuño]

On 28/1/22 19:18, Albrecht Schlosser wrote:

On 1/28/22 22:54 Gonzalo Garramuño wrote:

On 28/1/22 15:36, Albrecht Schlosser wrote:

On 1/28/22 19:04 Gonzalo Garramuño wrote:

In your case you should specify '/usr/local/share/fltk/' (verify that FLTKConfig.cmake is in that folder) and then it *should* work. Hopefully.

That did not work.

Why? What error messages do you see? Is the file /usr/local/share/fltk/FLTKConfig.cmake in that folder?

Never mind me.  I tried it again and it worked just fine.

This is (currently, still) in the library fltk_cairo which you would also have to link but I don't know why this appears in your build. I configured FLTK/Wayland with and w/o (CMake option) OPTION_CAIRO and it didn't happen to me in my `flruler' example project.

Yes, once I added fltk_cairo to the list of fltk libraries, all compiled smoothly.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/b4e997e5-34d3-d029-312c-b13e7311195b%40online.de.

[Albrecht Schlosser]

Hi Gonzalo,

I got this private mail from you, probably unintentionally ?

I'm forwarding it to fltk.coredev where others can see it as well,
particularly Manolo, the main developer of the Wayland port.

I'm glad that I could help you building your app with Wayland and I
appreciate your test efforts.

Thanks


On 1/29/22 01:24 Gonzalo Garramuño wrote:
>
> Okay.  First impressions.  The titlebar is huge.  There's no icon
> shown neither in the titlebar nor in the dock (it shows as a
> cogwheel).  The alignment and size of the window is random and makes
> it appear off-screen.
>
> The area of my window where there's no drawings appear stripped white
> and gray.
>
> I got a crash on exit (not sure if my code or Wayland's, but seems egl)
>
> eglSwapBuffers() failed
>
> Got signal 11, faulty address is (nil), from 0x86c4f3
> [tb] Execution path:
> [tb]
> /media/gga/Datos/code/applications/mrv/BUILD/Linux-5.13.0-27-generic-64/Release/bin/mrViewer(_ZN20Fl_Gl_Overlay_Plugin7do_swapEP9Fl_Window+0x23)
> [0x86c4f3]
> [tb]
> /media/gga/Datos/code/applications/mrv/BUILD/Linux-5.13.0-27-generic-64/Release/bin/mrViewer(_ZN20Fl_Gl_Overlay_Plugin7do_swapEP9Fl_Window+0x23)
> [0x86c4f3]
> [tb]
> /media/gga/Datos/code/applications/mrv/BUILD/Linux-5.13.0-27-generic-64/Release/bin/mrViewer(_ZN24Fl_Wayland_Window_Driver5flushEv+0xf6)
> [0x834906]
> [tb]
> /media/gga/Datos/code/applications/mrv/BUILD/Linux-5.13.0-27-generic-64/Release/bin/mrViewer(_ZN2Fl5flushEv+0xba)
> [0x7b4b6a]
> [tb]
> /media/gga/Datos/code/applications/mrv/BUILD/Linux-5.13.0-27-generic-64/Release/bin/mrViewer(_ZN21Fl_Unix_System_Driver4waitEd+0x1c6)
> [0x83b2be]
> [tb]
> /media/gga/Datos/code/applications/mrv/BUILD/Linux-5.13.0-27-generic-64/Release/bin/mrViewer(_ZN24Fl_Wayland_Screen_Driver4waitEd+0x73)
> [0x831c85]
> [tb]
> /media/gga/Datos/code/applications/mrv/BUILD/Linux-5.13.0-27-generic-64/Release/bin/mrViewer(_ZN2Fl4waitEd+0x36)
> [0x7b480e]
> [tb]
> /media/gga/Datos/code/applications/mrv/BUILD/Linux-5.13.0-27-generic-64/Release/bin/mrViewer(_ZN2Fl3runEv+0x25)
> [0x7b4835]
> [tb]
> /media/gga/Datos/code/applications/mrv/BUILD/Linux-5.13.0-27-generic-64/Release/bin/mrViewer(main+0x1747)
> [0x53fb87]
> [tb] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)
> [0x7fd1ffd1f0b3]
> [tb]
> /media/gga/Datos/code/applications/mrv/BUILD/Linux-5.13.0-27-generic-64/Release/bin/mrViewer(_start+0x2e)
> [0x5411ce]
>

[Albrecht Schlosser]

On 1/29/22 01:24 Gonzalo Garramuño wrote:
>>
>> Okay.  First impressions.  The titlebar is huge.

If you have installed all required packages you should get the "libdecor
GTK plugin" automatically and the titlebar should be as large as it is
with other GTK applications, at least under Gnome. There can be
differences though, depending on the desktop environment you're using.

If you didn't install 'libgtk-3-dev' then you get the Cairo plugin which
uses a bigger font but whose height can smaller. Can you post a screenshot?

>> There's no icon shown neither in the titlebar nor in the dock (it
>> shows as a cogwheel).

Both plugins have in common that they don't show icons in the titlebar,
at least AFAICT.

I don't know how to show an icon in the dock or sidebar (Gnome:
Applications) or whatever. I noticed it but this is maybe also true for
most of the FLTK X11 applications. If you used X11 specific code to set
the application icon (which you commented out) then this can obviously
not work. Otherwise ... I'll check if I can test an application with an
icon.

Which desktop environment did you install on your Ubuntu system?

>> The alignment and size of the window is random and makes it appear
>> off-screen.

It is a well-known Wayland problem that user programs can't specify the
position of the window on the screen. Wayland selects "random"
positions. However, the window size should be as specified by your
program. You can run all FLTK test programs and see whether they work
correct WRT window sizes.

Another known issue is that popup windows (modal dialogs) can't be
placed on the screen where we (FLTK and the user) want it. Wayland does
not allow it. This has been discussed in this thread.

>> The area of my window where there's no drawings appear stripped white
>> and gray.

This is unexpected. As said above, the window size should be specified
by the program. If it is not, then something else must be wrong.

>> I got a crash on exit (not sure if my code or Wayland's, but seems egl)

Crashes on exit are often caused by the application program (destructors
etc.) but I don't exclude that it's a FLTK or Wayland problem. I can't
tell anything to this topic.


Thanks for testing and for your report.