C++ GUI Standard Proposal - FLTK?

47 views
Skip to first unread message

Robin Rowe

unread,
Feb 2, 2023, 2:20:22 AM2/2/23
to fltkg...@googlegroups.com
I am drafting a proposal for the ISO C++ standard committee to add a
graphics library to the C++ language. Imagine having a GUI library as
part of C++, like the STL is a standard C++ container library.

Am considering proposing FLTK be the standard C++ GUI library. What do
FLTK folks think of this idea? In favor? Against? Want to be involved?

Best,

Robin
--
Robin Rowe
CinePaint Project Manager
Los Angeles, California

Basile Starynkevitch

unread,
Feb 2, 2023, 2:36:26 AM2/2/23
to Robin Rowe, fltkg...@googlegroups.com


On 02/02/2023 08:20, Robin Rowe wrote:
I am drafting a proposal for the ISO C++ standard committee to add a graphics library to the C++ language. Imagine having a GUI library as part of C++, like the STL is a standard C++ container library.

Am considering proposing FLTK be the standard C++ GUI library. What do FLTK folks think of this idea? In favor? Against? Want to be involved?


My personal opinion is that it is not worth your precious time and efforts. And my opinion on the C++ standard is that it is already too complex and too thick.


In particular since there are good open source several competitors, like Gtkmm or Qt.


(My pet open source project in C++ is http://refpersys.org/ .... a symbolic inference engine)


Regards.


Best,

Robin
-- 
Basile Starynkevitch                  <bas...@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Mohammed

unread,
Feb 2, 2023, 4:57:32 AM2/2/23
to fltkg...@googlegroups.com
I think it’s not worth the effort. Check this posting for example:

I believe the problem with C++ is the difficulty in incorporating 3rd party code, so the usual move is to add/propose it to the standard. 

Rust has a spartan standard library when compared to C++ (no regex or random for example), but has a standardized way of writing and describing packages, a good build-system/package manager which makes adding 3rd party Rust code rather trivial. 

Sent from my iPhone

On 2 Feb 2023, at 10:36, Basile Starynkevitch <bas...@starynkevitch.net> wrote:


--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/ccd3d140-753b-53bc-c6d7-8d0538bd5803%40starynkevitch.net.

Matthias Melcher

unread,
Feb 2, 2023, 6:12:07 AM2/2/23
to fltk.general

Thanks for the link below. A very good read. 

As for FLTK in a standard proposal. FLTK1 is almost 30 years old now. It was based on the "C" API of the library Forms, later XForms, and is even to this day somewhat source code compatible. A lot of limitations from Forms went int the FLTK 1 API, for example, pulldown menu items are not full widgets and are accessed through a completely different API than widgets, even though they do just the same, be children of a group inside a window. And much more. The list would get long quickly.

Bill saw that very early on, and FLTK2 fixed many if not all of these flaws within a year or two of the release of FLTK1. FLTK2 was in intensive daily use at Digital Domain, our employer, back then, and rumour has it, at at least two other special effects houses. FLTK2 uses a namespace, has a better layout engine, treats menu items as widgets, and has an al-in-all better C++ interface.

But as it was, FLTK1 made it into Linux distros. FLTK2 did not. Core devs, including me, got stuck on 1 while there were a few great apps developed with 2, like Dillo. And while fltk1 got better and better in the backend, fully supporting macOS and even Android for a while, fltk2 become more and more incompatible, idling to halt, and eventually being downgraded to an eternal Alpha version, majorly pissing off fltk2 developers who did not want to go back to 1.

The final stab to the death of fltk2 was probably Stroustrup's book "Programming: Principles and Practise using C++" which used fltk1 to teach C++, diverging new users away from 2 back to 1. Not sure if we were the cause and Stroustrup lived with the symptoms, or if it was the other way around, but here we are. Well, the book was from 2009, so I guess fltk2 was finished by then already.

I tried to merge 1 and 2 into 3, providing an API that was compatible to both, but eventually gave up due to the lack of capabilities of C++. But I did a great job in adding to the confusion in the FLTK version system. 

To get back to the standard proposal, FLTK is flagellating itself to use original C++. No exceptions, no STL, heck, not even RTTI or templates. This is awesome if you need to compile some app for Windows'89, but it's also very much in the way of a modern GUI standard for C++ in 2026 and further into the future.

In conclusion, as much as I would love to help with developing a C++ standard for user interfaces - and I guess my 30 years of experience may be helpful - I have a strong feeling that FLTK is the wrong base to make this happen. I love FLTK for its simplicity. Using Qt would be a much bigger mistake, because it is so huge and unwieldy, but FLTK probably isn't it either.

Then again, have you looked at FLTK4 yet? ;-)

 - Matthias

Mo_Al_

unread,
Feb 2, 2023, 8:49:18 AM2/2/23
to fltk.general
I think with C++23 modules, it would be possible to distribute module units as well as the headers. The module units could just expose a more modern api along with namespaces:

// window.cppm
module;
// global module fragment, Fl_Window.H symbols are not exported to users
#include <FL/Fl_Window.H>

export module window;

export namespace fltk::window {
    export using Window = Fl_Window;
    export using DoubleWindow = Fl_Double_Window;
}

// fl.cppm
module;

#include <FL/Fl.H>

export module fl;

export namespace fltk {
    export int run() {
        return Fl::run();
    }
}

// main.cpp
import fltk.fl;
import fltk.window;

int main() {
    fltk::window::DoubleWindow w{400, 300};
    w.end();
    w.show();
    fltk::run();
}

Greg Ercolano

unread,
Feb 2, 2023, 12:57:40 PM2/2/23
to fltkg...@googlegroups.com
On 2/1/23 23:20, Robin Rowe wrote:
I am drafting a proposal for the ISO C++ standard committee to add a graphics library to the C++ language. Imagine having a GUI library as part of C++, like the STL is a standard C++ container library.

Am considering proposing FLTK be the standard C++ GUI library. What do FLTK folks think of this idea? In favor? Against? Want to be involved?


    Sounds interesting, but we're such a small team. And fltk1 doesn't really take advantage
    of the newer features of C++, which might make us.. undesireable?

    That said, if there's a need for a GUI toolkit to help people starting C++ get a GUI going
    without a lot of overhead or expectactions of "beauty", I'm thinking along the lines of how
    OpenGL needed Glut to make demos work, then perhaps it is a good fit. Also, we've been
    around pretty long, which shows staying power I suppose..!

Greg Ercolano

unread,
Feb 2, 2023, 1:57:28 PM2/2/23
to fltkg...@googlegroups.com

    But hmm, it sure sounds like a reach to bring GUI stuff into the C++ language.
    Maybe I'm just old fashioned, but I'd think C++ has enough trouble definining
    its own language than to bring a GUI into it. And I can't imagine a standards committee
    getting everyone to agree on how a GUI API should be defined. If they were serious,
    they'd probably look at all the GUI toolkits out there, and define a new API that
    takes the best of all of them.

    They made terrible API naming decisions though with STL.
    "push_back()" instead of append()? "vector()" instead of array? Don't get me started, lol!


Ian MacArthur

unread,
Feb 3, 2023, 1:22:27 PM2/3/23
to Fltk General
On 2 Feb 2023, at 07:20, Robin Rowe wrote:
>
> I am drafting a proposal for the ISO C++ standard committee to add a graphics library to the C++ language. Imagine having a GUI library as part of C++, like the STL is a standard C++ container library.
>
> Am considering proposing FLTK be the standard C++ GUI library. What do FLTK folks think of this idea? In favor? Against? Want to be involved?
>


Hi Robin,

Well, I’m late too this but I guess I’m thinking the same way as most other respondents...
Like Greg, I’d say the dialect of C++ that FLTK uses is not very “modern” (or even very C++ !) so I’d guess it’d be a long shot to get it accepted as the standard.... but you never know of course.

I don’t think I could cope with all the committees, TBH...



Greg Ercolano

unread,
Feb 3, 2023, 5:25:58 PM2/3/23
to fltkg...@googlegroups.com


On 2/3/23 10:22, Ian MacArthur wrote:
Well, I’m late too this but I guess I’m thinking the same way as most other respondents... 
Like Greg, I’d say the dialect of C++ that FLTK uses is not very “modern” (or even very C++ !) so I’d guess it’d be a long shot to get it accepted as the standard.... but you never know of course.

I don’t think I could cope with all the committees, TBH...

    One way it could work is if they standardized on a wrapper around FLTK
    that had an API they liked that was more C++ ish, and perhaps would meet
    their needs.

    Whatever that need is. All I can guess is for simple examples to work,
    like how glut is to opengl.

    Qt might not be appealing because of their whole signal/slot front end
    that works in front of the compiler, not to mention its "weight".

    However, I'm not sure Qt hasn't made a way to split their library, like FLTK,
    where their advanced widgets are separate (like the web browser stuff,
    media features for sound and movies, etc), as I think Qt might be popular
    even on mobile devices, which I would think demand small libs.
   


  

Pierre Jasmin

unread,
Feb 3, 2023, 5:48:08 PM2/3/23
to fltkg...@googlegroups.com
Maybe it should be the other way around, drafting a version of C++ that only supports what FLTK does :)
Been programming C++ for 25+ years and some of the new constructs when I look at the code I can barely say it's C++ :)

Pierre

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

Greg Ercolano

unread,
Feb 3, 2023, 6:34:11 PM2/3/23
to fltkg...@googlegroups.com


On 2/3/23 14:47, Pierre Jasmin wrote:
Maybe it should be the other way around, drafting a version of C++ that only supports what FLTK does :)
Been programming C++ for 25+ years and some of the new constructs when I look at the code I can barely say it's C++ :)

    Heh, +1.

    When STL was admitted as a standard, and all those keywords with angle brackets and underbars
    in the names started appearing, I thought "no way, this is hacky/ugly/kludgy", and words that
    made no sense. The word "static" is abused and overloaded too much, and the STL API is just awful.

    My favorite thing to hate is working with vectors (arrays?!), appending to them (push_back!?)
    and deleting items (v.erase(v.begin()+index?!) is just so damned ugly.

w1hkj

unread,
Feb 3, 2023, 9:13:33 PM2/3/23
to fltk.general
Amen to that Pierre.  I chose fltk over the competing GUI libraries 23 years ago and have had no regrets over that choice.  fltk allows me to be as object oriented as I choose and does not force that paradigm upon my programming style.  I now have about a million lines of real-time application code in the public domain, all of which uses the fltk user interface.  The applications are used daily for emergency and recreational communications.

see: https://sourceforge.net/projects/fldigi/  a repository for the entire suite

Thanks and my hats off to the fltk maintainers who have always been responsive to my questions and suggestions.

David
Reply all
Reply to author
Forward
0 new messages