RFC: convert Fl class to namespace

[melcher....@googlemail.com]

The FL/Fl.H file is quite huge by now. We are squeezing tons of stuff into the Fl class, all static, almost all public, and a few private members.

I propose that the public members of the "class Fl" are transferred into globals in the "namespace Fl", and private members go into "namespace Fl_Private".

By using a namespace, we don't need everything in a single header file. We can move the event stuff in its own header file, the options stuff elsewhere, etc., and keep header files readable. Cool thing, this does not change the API at all, and we can still add stuff to the namespace without changing the ABI. 

Point in case: I want to add touch events and tablet events, but I don't want to mess up FL/Fl.H even further.

[melcher....@googlemail.com]

PS: I did this conversion without paying attention to formatting, and FLTK an all test and Fluid build just fine:

https://github.com/MatthiasWM/fltk/tree/namespace

FL/Fl.H is even bigger than I first estimated!

[Albrecht Schlosser]

On 11/1/25 15:42 'melcher....@googlemail.com' via fltk.coredev wrote:
>
> The FL/Fl.H file is quite huge by now. We are squeezing tons of stuff
> into the Fl class, all static, almost all public, and a few private
> members.
>
> I propose that the public members of the "class Fl" are transferred
> into globals in the "namespace Fl", and private members go into
> "namespace Fl_Private".

Actually, your implementation linked in the next post uses Fl::Private::
rather than Fl_Private:: but that's nitpicking.

> By using a namespace, we don't need everything in a single header
> file. We can move the event stuff in its own header file, the options
> stuff elsewhere, etc., and keep header files readable. Cool thing,
> this does not change the API at all, and we can still add stuff to the
> namespace without changing the ABI.

What access restrictions would Fl::Private:: provide? Private members of
class Fl:: can't be accessed by user programs, but what about
Fl::Private::some_variable?

I'm generally open for such changes, as long as they are backwards
compatible (API wise, i.e. for user programs) and don't open holes like
access to private variables etc..

> Point in case: I want to add touch events and tablet events, but I
> don't want to mess up FL/Fl.H even further.

:-)

[melcher....@googlemail.com]

Allrighty then. Thanks, Albrecht, for the clarifying phone call.


There is now a clean version of this feature in:
https://github.com/MatthiasWM/fltk/tree/namespace2

Fl::Private moved into the src/ subdirectory, making it invisible to app developers. Removing FL_EXPORT would also make those members inaccessible.

I modified everything related to Cairo and other platforms, and if I did it right, these should also compile just fine.

FL/Fl.H is now 800 instead of 1600 lines large. FL/core contains a few header files that hold Fl namespace members grouped by functionality.