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.