--
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/afea7bae-6563-4f83-a95a-48ea45ca8022n%40googlegroups.com.
It's possible to compile both the Wayland and the X11/Xlib driver source filesand to put all of them inside libfltk. With some additional tweaks, the result isan FLTK library that makes any FLTK app use Wayland when the Wayland compositor
is available, or the X11 server when it's not, without any change to the app orthe library. That puts FLTK apps in the same position as GTK apps in that respect.
That's for test in the wayland branch of my FLTK fork:(caution: that's a new wayland branch, delete your old one if any)
Some rather dirty hacks are required, though, to make everything work,especially for platform-specific types which normally differ for Waylandand for X11.
I believe a better solution for that, yet to be defined, is needed.
As for Fluid, I can offer to change Fluid, so it compiles as a pure command line app as well as a GUI app. It already avoids calling any graphics calls, but if it helps the cause, I would implement a pure .fl to .cpp translator.
…
What to do in FLTK 1.4?
In FLTK 1.4.0 with Wayland support we must ensure that the "Operating System Issues" are documented in a clean and future proof way and that typedefs and globals are not shared between X11 and Wayland modes. Rather than using the globals fl_display etc. we should define functions to access the platform specific variables and objects as required (see suggestion above).
Note that we *MUST* IMHO do this before FLTK 1.4.0 gets released because we couldn't easily go back once it is documented and published.
Defining new, similar functions for the X11 and other platforms would be optional in FLTK 1.4.0 but could be done as well. The "old interface" with typedefs and globals would be deprecated (for legacy applications) and new applications or those that want to be "hybrid" as well and still use platform specific code would have to use the "new interface".
So far my thoughts but this is probably far from complete. It should be a beginning...
Comments and suggestions appreciated.
--
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/34c51f3f-59d3-429d-780e-04b44bf78a18%40online.de.
As for Fluid, I can offer to change Fluid, so it compiles as a pure command line app as well as a GUI app. It already avoids calling any graphics calls, but if it helps the cause, I would implement a pure .fl to .cpp translator.
I see no reason you cannot use global variables instead of function calls for these pointers.
The variables are there entirely so that other platform-specific code can use them. You should be able to rename them because all the users of them can change the names as well.
I would very very much like to get rid of this idea that the platform is supported by virtual functions, and return to a state where it is controlled by ifdefs which can change how fltk functions are implemented, either by using completely diffferent versions of the functions, or ifdefs inside their internals, which is a very useful feature we lost with this virtual function idea. In particluar it would allow x-only, wayland-only, and the hybrid version to use the same source code.
In addition it is absolutely required that the X11 version be changed to use Cairo rendering.
On 3/22/22 18:26 Bill Spitzak wrote:
I see no reason you cannot use global variables instead of function calls for these pointers.
Yes, generally you can use global variables but those used today (one name for all platforms) can't be used further because different platforms require different types. As long as you had only one platform active in the build at any time this was no problem (although it made things sometime very complicated).
I've also seen too often that global variables exposed to user ode make later changes almost impossible. The existing global variables (e.g. fl_display) are also user-writable IIRC. All these points are reasons to use accessor functions instead.
The variables are there entirely so that other platform-specific code can use them. You should be able to rename them because all the users of them can change the names as well.
Yes, we can do this. But if we rename them in one step backwards compatibility is gone. We'd have to keep at least both variable names for some time. Exporting accessor functions to these variables makes sure we have full control (read-only) and we can change the function later if required.
I would very very much like to get rid of this idea that the platform is supported by virtual functions, and return to a state where it is controlled by ifdefs which can change how fltk functions are implemented, either by using completely diffferent versions of the functions, or ifdefs inside their internals, which is a very useful feature we lost with this virtual function idea. In particluar it would allow x-only, wayland-only, and the hybrid version to use the same source code.
No, it wouldn't. In the classic style you have only one platform enabled during compilation. In the future (with a "hybrid" FLTK lib) we'd have more than one platform concurrently. #if ... #elif ... #elif ... #endif does no longer work. We would have to use #if platform-1 (code1) #endif, #if platform-2 (code2) #endif and both platform-1 and platform-2 expressions (e.g. X11 and Wayland) could be active at the same time.
That said, and as I already wrote before: we made a conscious decision to go away from the #ifdef ... style and use the current driver model. This is not going to be reverted. I'm sorry to say that to you, Bill, but that's a fact. One of the main persons in this decision process was Matthias, and the decision was mainly driven by the fact that the old style wouldn't scale to more platforms (we had three at that time).
Meanwhile we removed some experimental platforms (SDL, Pico, Android) and added Wayland. Note that the removal of the experimental platforms was done in minutes, mainly by removing entire directories and editing the two platform specific header files. It would likely have taken days to remove platform specific code from the old-style #ifdef structure by editing all necessary files. This is modularity that helps to maintain the library. The inverse process to add Wayland was mostly done by adding the Wayland specific driver directories with their own virtual driver methods. The only code that was required to support it was a design decision to split the driver base so we had another Fl_Unix_Driver but that's another point.
In addition it is absolutely required that the X11 version be changed to use Cairo rendering.
This is work in progress and will be done.
PS: Bill, please don't top-post here. It's hard to keep the context.
On Tue, Mar 22, 2022 at 8:14 AM Albrecht Schlosser <Albrech...@online.de> wrote:
On 3/22/22 15:42 Manolo wrote:
Le lundi 21 mars 2022 à 20:31:53 UTC+1, Albrecht Schlosser a écrit :
…
What to do in FLTK 1.4?
In FLTK 1.4.0 with Wayland support we must ensure that the "Operating System Issues" are documented in a clean and future proof way and that typedefs and globals are not shared between X11 and Wayland modes. Rather than using the globals fl_display etc. we should define functions to access the platform specific variables and objects as required (see suggestion above).
Note that we *MUST* IMHO do this before FLTK 1.4.0 gets released because we couldn't easily go back once it is documented and published.
Defining new, similar functions for the X11 and other platforms would be optional in FLTK 1.4.0 but could be done as well. The "old interface" with typedefs and globals would be deprecated (for legacy applications) and new applications or those that want to be "hybrid" as well and still use platform specific code would have to use the "new interface".
So far my thoughts but this is probably far from complete. It should be a beginning...
Comments and suggestions appreciated.
I appreciate very much this input on this topic because I see it's very important and also complex to solve.
I will look into these proposals and try to implement the beginning for 1.4.0
Thanks for doing this, but please keep in mind that my suggestions are so far only thoughts and theoretical. We'll need to find out if this theory works and then find a migration path for future versions.
I'll try to look into it further to see if I can improve my ideas, but please go ahead, you may know better than I what to do.
--
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/c4e4f9ab-474c-586c-8d79-f1731e000deb%40online.de.
On Tue, Mar 22, 2022 at 1:42 PM Albrecht Schlosser <AlbrechtS...> wrote:
On 3/22/22 18:26 Bill Spitzak wrote:
I see no reason you cannot use global variables instead of function calls for these pointers.
Yes, generally you can use global variables but those used today (one name for all platforms) can't be used further because different platforms require different types. As long as you had only one platform active in the build at any time this was no problem (although it made things sometime very complicated).
I've also seen too often that global variables exposed to user ode make later changes almost impossible. The existing global variables (e.g. fl_display) are also user-writable IIRC. All these points are reasons to use accessor functions instead.
The current design that attempted to reuse the X11 symbol names for similar symbols in other systems is almost certainly a mistake.
In particular it means you don't get a linking error if you attempt to use a different backend than fltk was compiled for.
What I propose is renaming the symbols to be different for each platform. I don't think the fact that people can write values to them is very important, and fltk itself has to write the value for these somewhere, leaving another global variable that a user can malicioulsly write over anyway.
The variables are there entirely so that other platform-specific code can use them. You should be able to rename them because all the users of them can change the names as well.
Yes, we can do this. But if we rename them in one step backwards compatibility is gone. We'd have to keep at least both variable names for some time. Exporting accessor functions to these variables makes sure we have full control (read-only) and we can change the function later if required.
I would very very much like to get rid of this idea that the platform is supported by virtual functions, and return to a state where it is controlled by ifdefs which can change how fltk functions are implemented, either by using completely diffferent versions of the functions, or ifdefs inside their internals, which is a very useful feature we lost with this virtual function idea. In particluar it would allow x-only, wayland-only, and the hybrid version to use the same source code.
No, it wouldn't. In the classic style you have only one platform enabled during compilation. In the future (with a "hybrid" FLTK lib) we'd have more than one platform concurrently. #if ... #elif ... #elif ... #endif does no longer work. We would have to use #if platform-1 (code1) #endif, #if platform-2 (code2) #endif and both platform-1 and platform-2 expressions (e.g. X11 and Wayland) could be active at the same time.
That said, and as I already wrote before: we made a conscious decision to go away from the #ifdef ... style and use the current driver model. This is not going to be reverted. I'm sorry to say that to you, Bill, but that's a fact. One of the main persons in this decision process was Matthias, and the decision was mainly driven by the fact that the old style wouldn't scale to more platforms (we had three at that time).
I agree the current code structure is necessary, where the implementations each live in their own file. The old fltk scheme basically was the X11 version with ifdefs added to it to patch in alternative versions where needed. Instead this should be done like the fltk 2.0 code, where X11 would be in it's own source file, and ifdefs are almost exclusively used to switch which #include statement is compiled, and all the platform code is in that included file. However that platform code *directly* defines the public fltk function.
Using a virtual function table has the annoying fact that it will link all the code into the program whether it is used or not.
But more importantly it puts decisions, such as how to modularize the platform-specific code, into public header files and the fltk binary api. This is not a good idea.
Here is a complete proposal for a hybrid Wayland/X11 FLTK library ready for release with FLTK 1.4,along the line sketched by Albrecht above.
It's available in branch wayland of
It contains support for an environment variable FLTK_BACKEND to pilot what is used at run-time:- if FLTK_BACKEND is undefined, the library uses wayland if available and x11 otherwise;- if FLTK_BACKEND = wayland, the library uses Wayland if possible and exits with error otherwise;- if FLTK_BACKEND = x11, the library uses X11 even if Wayland is available;- if FLTK_BACKEND has another value, the library exits with an error message.
It contains also function fl_disable_wayland(), to be called early in main(), to force an app to useX11 without using the FLTK_BACKEND variable, as Albrecht suggested.
--
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/5d50a22e-beb0-99e6-37c1-34d54267533b%40gmail.com.
Here is a complete proposal for a hybrid Wayland/X11 FLTK library ready for release with FLTK 1.4,along the line sketched by Albrecht above.
It's available in branch wayland of
It contains support for an environment variable FLTK_BACKEND to pilot what is used at run-time:- if FLTK_BACKEND is undefined, the library uses wayland if available and x11 otherwise;- if FLTK_BACKEND = wayland, the library uses Wayland if possible and exits with error otherwise;- if FLTK_BACKEND = x11, the library uses X11 even if Wayland is available;- if FLTK_BACKEND has another value, the library exits with an error message.
It contains also function fl_disable_wayland(), to be called early in main(), to force an app to useX11 without using the FLTK_BACKEND variable, as Albrecht suggested.
Here is a very detailed (and very long) description of changes, their reason, their impact,for all platform-dependent types and global variables which are part of the FLTK 1.3 public API.OLD means the public API of FLTK 1.3; NEW means the public API of FLTK 1.4.
Functions fl_<platform>_find() are put in files
scr/drivers/<platform>/fl_<platform>_platform_init.cxx.
For the hybrid Wayland/X11 library, both fl_wl_find() and fl_x11_find() functions are
in file src/drivers/Wayland/fl_wayland_platform_init.cxx
Platform-specific code in FLTK 1.3 app that did, for example
#include <FL/platform.H>
#if FLTK_USE_X11
Window xwin = fl_window;
X11_function_with_Window_typed_argument(xwin);
#endif
remains possible.
FL_SOCKET, fl_intptr_t and fl_uintptr_t <=== no change needed
I'm picking only a few statements where I have questions or annotations for my comment(s) below. Everything else looks good and clear so far from reading.
Functions fl_<platform>_find() are put in files
scr/drivers/<platform>/fl_<platform>_platform_init.cxx.
For the hybrid Wayland/X11 library, both fl_wl_find() and fl_x11_find() functions are
in file src/drivers/Wayland/fl_wayland_platform_init.cxx
I'm wondering why these functions are not in separate, i.e. their own per-platform files. However, I did not look at the code yet...
Platform-specific code in FLTK 1.3 app that did, for example
#include <FL/platform.H>
#if FLTK_USE_X11
Window xwin = fl_window;
X11_function_with_Window_typed_argument(xwin);
#endif
remains possible.
In FLTK 1.3 we didn't have FLTK_USE_X11 yet. As I described before user code would very likely handle the X11 platform in the #else clause which has been a big problem of FLTK up to 1.3.x (IIRC Bill wrote that this was solved for 2.0 as well).
So, what we need to have would be that code like the following would still work:
#if defined(_WIN32)
... windows code
#elif defined (__APPLE__)
... macOS code
#else
... X11 specific code
#endif
Such "legacy programs" would presumably need to call fl_disable_wayland() which would definitely be a (minor) source code change, but then ... would they work w/o other changes if they only used X11 specific code like in 1.3 in the #else clause?
This would be a great achievement for migration from 1.3 to 1.4 while still being able to use a hybrid FLTK library.
My main comment is that I think "region" is part of the rendering, and you don't seem to have the Cairo version. It may also be ok to scrap support for regions that are not rectangles.
I also feel that part of this would be to make it use Cairo for both X11 and Wayland, and scrap all xlib drawing and especially any API to get at them. This will also remove the need to have server-side offscreen buffers which are completely obsolete and never used by any other software. Cairo (and Windows and Mac) can draw into local memory buffers and these should be used.
On Wed, 30 Mar 2022 01:48:40 -0700 (PDT)
Manolo wrote:
> Indeed, the hybrid Wayland/X11 library could use cairo-only rendering for
> its X11 backend.
> Let's see what other developers think.
Is it any large maintenance overhead, the X drawing? In the interest of
size, we'd like to keep X drawing available and cairo not mandatory.
(We'd of course also disable wayland)
--
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/ca8a5000-d9a2-4778-809f-0568841f1f55n%40googlegroups.com.
On Wednesday, 30 March 2022 at 15:51:57 UTC+1 Lauri wrote:
On Wed, 30 Mar 2022 01:48:40 -0700 (PDT)
Manolo wrote:
> Indeed, the hybrid Wayland/X11 library could use cairo-only rendering for
> its X11 backend.
> Let's see what other developers think.
Is it any large maintenance overhead, the X drawing? In the interest of
size, we'd like to keep X drawing available and cairo not mandatory.
(We'd of course also disable wayland)
Lauri makes a fair point - I too have a handful of "embedded" systems running some or other cut-down Linux, and in general they only have X11 as a render option (at least one actually has an xf86 server, albeit now running on arm, but I think that gives a sense of how "old" some of these environments are...)
So losing the X11 backend would not be ideal, though of course I still have 1.3...
--
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/40409d83-62d4-4f4c-27b0-04d0a021e7d9%40online.de.
--
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/20d2c4ee-762d-4629-aba8-ad1910e132acn%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/f4c36b80-6de3-c3d8-646f-c6637ec2fa33%40online.de.
--
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/bf5c2357-e721-463e-82b4-4624dec43b3cn%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/E60F81CE-66F2-4930-AA12-F13562E6A0F8%40gmail.com.
What are "Cairo window wrappers"?
This sounds like exactly what is needed and wanted. I might change the second option name to OPTION_USE_CAIRO for consistency with the others
On Tue, Apr 5, 2022 at 6:14 AM Manolo <manol...@gmail.com> wrote:
[...]
This sounds like exactly what is needed and wanted. I might change the second option name to OPTION_USE_CAIRO for consistency with the others
I have renamed the option which is now OPTION_USE_CAIRO and tried to improve the description of Cairo-related options.
This leaves us with 3 cairo-related options :
OPTION_CAIRO add support for Fl_Cairo_Window
OPTION_CAIROEXT use FLTK code instrumentation for Cairo extended use
OPTION_USE_CAIRO all drawing to X11 windows uses Cairo
Since OPTION_CAIRO is really nothing but opening support for class Fl_Cairo_Window, I would propose to rename itOPTION_FL_CAIRO_WINDOW. OPTION_CAIROEXT could become OPTION_FL_CAIRO_WINDOW_EXT.This would hopefully improve understanding the difference between the options.
Comments ?