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.
I'd like to invite fellow FLTK developers to vote about
adding a Wayland platform to the FLTK library.
The new code contains no change to platform-independent FLTK code;
it's therefore completely compatible with extant FLTK user code.
* 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.
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 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?
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.
* 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.
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.
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.
--
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.
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.
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.
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?
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/cf756acd-8dcb-465e-a874-a99eba1a9125n%40googlegroups.com.
--
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.
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?
--
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.
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.
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.
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?
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.
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.
It's now clear that Wayland is the future of Linux desktops, even if it's also clear that X11 clients willbe 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.
--
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.
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.
--
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.
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?
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/ffbe886b-0768-476a-90d4-debb4b7d1869n%40googlegroups.com.
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/4bb47d18-0d77-4f02-96e7-4cd2fedae749n%40googlegroups.com.
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/bfe6920b-3344-4531-94a5-78f27c613ff4n%40googlegroups.com.
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.
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.
--
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.
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.
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.
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?
--
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.
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/7a672a3f-19a2-40c5-b430-27758f9b19c3n%40googlegroups.com.
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.
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, ...
--
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.
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.
--
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.
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/6b4dc011-f96a-4599-a6e2-3bb0d5720457n%40googlegroups.com.
I followed the Debian/Ubuntu instructions but cannot see a Wayland
protocol on log-in. I only have Ubuntu and Gnome.
I get the following when running make:
=== making libdecor/build ===
make[1]: wayland-scanner: Command not found
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.
Never mind. I did a git pull and all is now fine.
On 21/1/22 05:00, Manolo wrote:
The same app run with 2 values of the environment var LIBDECOR_PLUGIN_DIRI am having trouble obtaining and compiling libdecor. I went to fltk's libdecor build directory and run make and I got:
so FLTK dlopen()'s either libdecor-cairo.so (left) or lidbdecor-gtk.so (right).
--
../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.
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]
[..]
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_DIRI am having trouble obtaining and compiling libdecor. I went to fltk's libdecor build directory and run make and I got:
so FLTK dlopen()'s either libdecor-cairo.so (left) or lidbdecor-gtk.so (right).
--
../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?
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.
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
[..]
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
On 1/27/22 11:48, Manolo wrote:
1) libdecoration and libdecor and 2 different things
Ah, good to know -- thanks!
On 27/1/22 17:03, Albrecht Schlosser wrote:
When I compiled the new fltk with my program,
What are your errors?
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.
On 28/1/22 13:58, Albrecht Schlosser wrote:
On 1/28/22 17:10 Gonzalo Garramuño wrote:Ok. I have my fltk install in /usr/local. However, with NO_MODULE set no libraries are found.
On 28/1/22 12:08, Manolo wrote:
You should use `fltk-config --cxxflags --ldflags` within your makefile.Okay, but how do I run that from a CMakeLists.txt file?
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.
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.
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.
That worked for fltk-x11, but it is confusing that FLTK_LIBRARIES is always empty.
But again, you can avoid that if you use the FLTK build folder for your testing directly.
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.
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?
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.
--
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.