RFC: Removal of FL_CFG_* macros and config_lib.h

[Albrecht Schlosser]

All (not only devs),

in another post I wrote:

> Generally I *believe* ...that all these
> FL_CFG_GFX_* definitions should not be necessary and
> *maybe* the entire [file] 'config_lib.h' could be
> removed. ... But that's something that needs some
> time for investigation...

First of all, a BIG THANK YOU to Manolo who reorganized the remaining
(?) driver stuff and removed the majority of the usages of these
FL_CFG_* config macros. It's obviously been a lot of work and many commits.

Today I removed the remaining references of config_lib.h except those in
src/Fl.cxx which are still needed to implement the static assignment of
runtime configuration variables (documented here):

https://www.fltk.org/doc-1.4/group__cfg__gfx.html
https://www.fltk.org/doc-1.4/group__cfg__prn.html
https://www.fltk.org/doc-1.4/group__cfg__win.html
https://www.fltk.org/doc-1.4/group__cfg__sys.html

I'd like to keep these runtime configuration /features/ but I'd prefer
to turn them into functions like, for instance

int Fl::cfg_gfx_cairo()

and

int Fl::cfg_gfx_opengl()

rather than referencing global (static) class variables. IMHO such
static variables lack C++ (i.e. OO) features, we'd be better with
private variables and corresponding getter methods which would enable us
to implement features we don't even know of yet.

These runtime configuration features *can* be useful although I'm not
sure what they can be used for exactly. There is only one example in the
FLTK sources in cube.cxx:

cube.cxx-234-
cube.cxx-235-#if HAVE_GL
cube.cxx-236- // try to overlay a button onto an OpenGL window
cube.cxx:237: if (Fl::cfg_gfx_opengl) {
cube.cxx-238- lt_cube->begin();
cube.cxx-239- Fl_Button *test = new Fl_Button(35, 105, 100, 30, "Test");
cube.cxx-240- test->box(FL_ROUND_UP_BOX);
cube.cxx-241- lt_cube->end();
cube.cxx-242- }
cube.cxx-243-#endif // HAVE_GL

As you can see the usage is inside "#if HAVE_GL" anyway, hence I think
it wouldn't make much difference if the runtime test was not available
in /this/ case.

But there may be other usages...

As always, all comments and suggestions would be very much appreciated. TIA.

Question 1: keep these runtime features?

Question 2: turn them into functions?

[Manolo]

On Thursday, February 18, 2021 at 1:52:08 PM UTC+1 Albrecht Schlosser wrote:

All (not only devs),

in another post I wrote:

> Generally I *believe* ...that all these
> FL_CFG_GFX_* definitions should not be necessary and
> *maybe* the entire [file] 'config_lib.h' could be
> removed. ... But that's something that needs some
> time for investigation...

… 

Today I removed the remaining references of config_lib.h except those in
src/Fl.cxx which are still needed to implement the static assignment of
runtime configuration variables (documented here):

https://www.fltk.org/doc-1.4/group__cfg__gfx.html
https://www.fltk.org/doc-1.4/group__cfg__prn.html
https://www.fltk.org/doc-1.4/group__cfg__win.html
https://www.fltk.org/doc-1.4/group__cfg__sys.html

…

As always, all comments and suggestions would be very much appreciated. TIA.

Question 1: keep these runtime features?

I'm not completely sure but my impression is that until FLTK can support a build in which

these global variables (or function results) can take distinct values according to the

application's running context, these variables/functions are not useful. They may even give to FLTK

users a false impression that FLTK supports alternative graphics or printing systems.

One expressive situation is under macOS, where FLTK can be built to use either the Quartz

or X11 drawing systems. Any FLTK app uses either one or the other in a invariable way.

Another case arises with the proposed GDI+ branch. There, either GDI+ or GDI is used,

and there's no way for an app to choose between them at run-time.

Question 2: turn them into functions?

N/A

[Albrecht Schlosser]

These runtime info functions (or static class variables as they are
currently) are only meant to give info to the program, not to be changed
at runtime. They would be useful for instance if a program is linked
against a shareable library and can query whether a certain function is
available or on which OS or platform (X11 vs. Quartz on macOS etc.) it
is running.

I'm also not sure what this info would be good for, at least the program
could tell in an warning message "this program needs Cairo support but
the FLTK library it is linked to does not support Cairo" or something
like that.

Matt created these global variables together with all these macros
(config_lib.h) in the pre-driver aera, i.e. in the "fltk-porting" branch
(or whatever that name was) before the new driver model was developed.

You can compare this with the way you can use FL_VERSION macros and you
can query the runtime version with Fl::api_version() etc..

That said, we /could/ remove all this now, before FLTK 1.4 is released
because it would be new in 1.4 (not in 1.3.x).

Useful or not? I'm not sure as well, that's why I asked for opinions and
comments.

[Bill Spitzak]

I don't believe anything other than constexpr declared in the headers, or macros are useful for this. Making them look like variables or function calls is really misleading and quite confusing.

--
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/d9aa231e-966a-3440-e167-6c3ddb6fb587%40online.de.

[Ian MacArthur]

On 18 Feb 2021, at 16:55, Albrecht Schlosser wrote:
>
> These runtime info functions (or static class variables as they are currently) are only meant to give info to the program, not to be changed at runtime. They would be useful for instance if a program is linked against a shareable library and can query whether a certain function is available or on which OS or platform (X11 vs. Quartz on macOS etc.) it is running.
>
> I'm also not sure what this info would be good for, at least the program could tell in an warning message "this program needs Cairo support but the FLTK library it is linked to does not support Cairo" or something like that.

I don't think I’ve even looked at these, nor thought about what they do - what I take from Albrecht’s description is that if a program loaded fltk as a SO/DLL then it could query these symbols and on that basis decide what features to use, is that right?

I imagine to do that the program would need to use dlsym (or equivalent) to access any of the “optional” capabilities in the fltk lib though, since if they were actually linked in the app any “missing" symbols would presumably fail when the app bound the SO.

I’m not sure I see how that would work out though, as you’d presumably have to use dlsym to access quite a lot of fltk functionality to make that hang together?

And if you have to use dlsym to access the features, well, dlsym itself will tell you whether the feature is available or not.
Clearly, I don't understand what is being done here.

Presumably this is all irrelevant in a static linked app, where the capabilities are presumably known explicitly at build time anyway?

[Albrecht Schlosser]

On 2/18/21 11:04 PM Ian MacArthur wrote:
> On 18 Feb 2021, at 16:55, Albrecht Schlosser wrote:
>>
>> These runtime info functions (or static class variables as they are currently) are only meant to give info to the program, not to be changed at runtime. They would be useful for instance if a program is linked against a shareable library and can query whether a certain function is available or on which OS or platform (X11 vs. Quartz on macOS etc.) it is running.
>>
>> I'm also not sure what this info would be good for, at least the program could tell in an warning message "this program needs Cairo support but the FLTK library it is linked to does not support Cairo" or something like that.
>
>
> I don't think I’ve even looked at these, nor thought about what they do - what I take from Albrecht’s description is that if a program loaded fltk as a SO/DLL then it could query these symbols and on that basis decide what features to use, is that right?

Even if I wrote something like that, it's not only for a dynamically
linked program. Imagine a user linking their FLTK program on a Linux
system with a system provided FLTK lib (as SO/DLL or static/object
library). Even a simple hello world program could access all these
functions and thus "know" something about the library provided by the
system.

What is this good for? Honestly, I don't know. It's a little like
"looking into config.h" which is not exported by FLTK (why not, BTW?).

Anyway, all these functions have been created by Matt and he could maybe
tell us about his intentions. I can only refer to the docs as they are
(links in my original post of this thread). And it's as simple as
exporting a variable with the contents that reflects the value of a
compile definition at build time.

> I imagine to do that the program would need to use dlsym (or equivalent) to access any of the “optional” capabilities in the fltk lib though, since if they were actually linked in the app any “missing" symbols would presumably fail when the app bound the SO.
>
> I’m not sure I see how that would work out though, as you’d presumably have to use dlsym to access quite a lot of fltk functionality to make that hang together?
>
> And if you have to use dlsym to access the features, well, dlsym itself will tell you whether the feature is available or not.
> Clearly, I don't understand what is being done here.

All I said is that these variables can tell you something about the FLTK
lib your program is linked to. It's somehow like querying which features
an X11 server provides or the runtime version queries some libs (and
FLTK as well) provide. How you would use that info I don't know. And
again, that's why I asked for opinions.

> Presumably this is all irrelevant in a static linked app, where the capabilities are presumably known explicitly at build time anyway?

Even in a statically linked app you can query these functions/values
because you don't know what features were enabled when the library was
built (if you didn't build it yourself).

As I wrote before I don't know of any direct usage example. If nobody
else knows and - as the discussion shows - if we consider these static
variables useless then, well, let's delete them. I'd be fine with
deleting them if nobody can tell how to use them for anything useful.

[Manolo]

I have just verified that the same object file, hello.o, output by command

    g++ -I/path/to/source/FLTK/tree -c hello.cxx

can be linked to the dynamic libfltk libraries built with

OPTION_APPLE_X11 set either off or  on.

That provides a scenario where an app could test the values of Fl::cfg_gfx_quartz

or Fl::cfg_gfx_xlib.

[Bill Spitzak]

I think the question is whether a program can do anything useful with those return values.

The only use I can see is for a "glxinfo" type program to print out how fltk has been compiled.

If this is useful I would prefer it to be much more obvious that these are compile-time constants. Ideally there is a structure defined, and a single extern instance. This is compiled with a static assignment to a value that is controlled by #if statements.

--
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/8c5bd1f0-d7f0-4ad6-a22d-4d54605562f5n%40googlegroups.com.

[Albrecht Schlosser]

On 2/19/21 10:16 PM Bill Spitzak wrote:
> I think the question is whether a program can do anything useful with
> those return values.

After all discussions here I'd say nobody sees a real useful application
of these variables.

> The only use I can see is for a "glxinfo" type program to print out how
> fltk has been compiled.

I agree, this would be a useful FLTK utility program (flinfo, maybe?).

> If this is useful I would prefer it to be much more obvious that these
> are compile-time constants. Ideally there is a structure defined, and a
> single extern instance. This is compiled with a static assignment to a
> value that is controlled by #if statements.

I do also agree that such a structure would be fine. This structure
would include much more (and different) values than what we have now.

We'd need a different implementation anyway, so I strongly believe that
we should remove the entire file config_lib.h and all variables (global
runtime config) associated with this file.

[Manolo]

On Tuesday, February 23, 2021 at 11:00:39 PM UTC+1 Albrecht Schlosser wrote:

We'd need a different implementation anyway, so I strongly believe that
we should remove the entire file config_lib.h and all variables (global
runtime config) associated with this file.

OK to remove file config_lib.h altogether on my side.