Skip to content

Home

Jump to bottom
Matthias Melcher edited this page Dec 31, 2025 · 10 revisions

fltk3

This is a collection of thought on trying to implement fltk3 - again.

Safe FLTK

FLTK1 was written a long time ago to quickly implement a missing library. It's basically "C++ with classes". Modern C++, even if it is only C++11, can offer so much more type safety and early warnings to the user at compile time. I would love to upgrade FLTK1 to use a much better API, but there are so many changes, I find a new major version number very appropriate.

At the same time, I don't want to lose and existing users and make moving to fltk3 as painless as possible.

So here is the idea: move the existing FLTK1 code into a new fltk3 namespace, and then write a header-only shim that maps every FLTK1 code to the fltk3 implementation via an inline function or method. If that works, FLTK1 and fltk3 could be freely intermixed. Users can start with fltk3, or continue using FLTK1, or keep existing FLTK1 code and continue with fltk3 within the same app, and benefit from the new API without sacrificing any existing code.

Gradual Transition

The initial fltk3 API and implementation will simply replace all Fl references (Fl_, fl_, Fl::) with a new fltk3:: namespace and completely clean up the global namespace.

Major changes will include:

  • get rid of any const char* and char* types where we meant to say std::string, avoid doubling APIs and providing both const char* and std::string everywhere for back compatibility
  • get rid of all #define statements, cludges, and trickery
  • use constexpr and enum classes wherever it makes sense (do you know the difference between FL_Caps_Lock and FL_CAPS_LOCK? Wouldn't if be better if they were named Key::Caps_Lock and Modifier::Caps_Lock?)
  • use classes even if we just represent integers, so they are not intermixed (do you know what myWidget->color(16711680) does? Maybe myWidget->color(0xff0000) is better? But is that red or green? How about myWidget->color(RGBColorI(0, 255, 0)? Oh, it's green!)
  • again, type safety: if (Fl::event_key()==FL_RED) should generate an error at compile time!
  • be perfectly clear about ownership. Who owns the text in const char* Fl_Widget::label()? Hint: it's not Fl_Widget, at least not always.

Trust the Compiler

This is the big premise her. Trust the compiler to optimize a ton of stuff away, and still get fast and lean code. The shim implementation looks complex, but it really is just a simple trampoline. Fltk3 implementations may look complex to achieve type safety, but if implemented right, all that will be optimized away, and the binary will be as lean as the original FLTK1 code, but with all the compile time checks to keep thing save, and run time check if we want them.

Clone this wiki locally