Re: [fltk.coredev] Consider using std::vector (C++98 / C++11)

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
Previous Message ]New Message | Reply ]Next Message ]

Re: Consider using std::vector (C++98 / C++11) Rob McDonald 14:42 Jul 24 top right image
In my experience, projects that rely on extremely limited toolchains aren't in a big hurry to update to the latest release of every dependency.  They are generally happy to remain frozen in time with a well tested system that works.

What is the union of esoteric systems stuck on ancient toolchains that also need to update to the latest / greatest FLTK?

Hmm, to clarify: did you mean intersection rather than union? That would likely be a very small set.

Good catch -- I did mean intersection rather than union.   I agree it is a very small set -- and one that is probably only identifiable by the developers in that situation.

As FLTK moves from 1.3.X to 1.4.X, it is the perfect time to draw some line in the sand.  To determine what will be supported (and hopefully tested) - and what will be allowed to remain at 1.3.X (or earlier).

I believe that FLTK 1.4 should stay as compatible to 1.3 as possible (regarding API and build system) because 1.4 is long (over?)due and we added so many improvements (and fixes) which are not in 1.3 that we should offer a real / simple migration path from 1.3 to 1.4 for as many platforms as possible.

But I do also think that we need to move forward. See below.

I think you are perhaps a little too conservative here.  This argument - that the release process has lagged the magnitude of development is not a great reason.  As a volunteer driven effort, FLTK's development pace is likely going to always be somewhat slow and deliberate (not a bad thing).  Not wanting to leave legacy users out of the newest features leads to supporting them forever.

Once again I wonder if the systems we're worried about are even considering updating to 1.4.  If they are happy with 1.1 or 1.3, do we really expect them to jump forward.

On the other hand, since we all desire a 1.4.0 release ASAP, there isn't much point in opening up the development rules for 1.4.  1.4 should probably ship with the current rules -- not for the sake of legacy systems -- but in the interest of getting it out the door ASAP.

My thoughts on future FLTK development (short term and mid/long term, certainly incomplete):

- keep FLTK 1.4 as-is, don't change software requirements (see the "pragmatic answer" above)
- change build requirements only as much as absolutely necessary (e.g. we removed bundled IDE's)
- stay conservative with CMake minimum version (we moved from 2.6.3 to 3.2.3)
- release FLTK 1.4 "soon" (soon means hopefully this year)

The next version after 1.4 could be a major step with a new major version number. This would be 4.0 because 2.0 and 3.0 have already been burnt (without releases). This next major version would allow us to change build requirements and maybe also supported systems. Some ideas:

- allow FLTK to use <some> C++11 features internally, i.e. require a C++11 compiler ('auto' comes to mind [4])
- allow namespaces (particularly anonymous namespace)
- allow select STL features like std::vector< some-types >
- drop autoconf build for easier maintenance (see also STR #2916 [3] from Jan 2014)
- update the CMP accordingly (this would probably be the first step)
- keep the API backwards compatible as much as possible (as we always did)

This way we could modernize the FLTK code base and those users with older compilers/build systems could stay with a "more modern" FLTK 1.4 from 2021 rather than a less maintained FLTK 1.3 (macOS support + some bug fixes since 1.3.4 (Nov 2016)).

Thoughts about very restricted platforms like embedded systems that use FLTK: I believe that those platforms use cross compilers anyway. If they are stuck with really old cross tools then they are (probably already) also stuck with old FLTK versions. I suspect that some of these platforms use 1.1 anyway because they don't have working UTF-8 support - unless they are using ASCII only. That said, if these platforms can use FLTK 1.4 at all this should be a sufficient base for the next 5 years or so. After that time a switch to FLTK 4.0 (released in 2022 and later) would involve new, more modern cross tools anyway. Even the ancient build systems used for cross compiling those old embedded systems might fade away over time because the hardware may die (unless they're using well maintained VM's).

Does this sound like a more encouraging plan?

I am not a core FLTK developer, so I can't really speak to the value or difficulty of each specific policy change.

I think the most important step is updating the CMP.  While there is a ton of great information in there, I think it needs to define what systems are supported.  That will likely be done in terms of platform and toolchain version numbers.  It would be best to actually have CI testing of everything on that list -- as mentioned, Docker could be a great help here. 

Once there is a clear handle on what is supported, there can be a roadmap that updates the support basis as new versions are developed and released.

This may imply that FLTK should try to pursue a regular cadence of time-based releases -- most linux distributions and developer tools have gone to time-based releases, it might be good to pseudo-align FLTK's targets and goals with those schedules.  I'm not thinking direct alignment, but instead lagged alignment -- for example, FLTK aims to support official versions released over the past five years of Ubuntu, gcc, clang, msvc, CMake, MacOS, Windows...  That five year window moves forward, but in spirit it remains the same.


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
To view this discussion on the web visit
Direct Link to Message ]
bottom left image   bottom right image
Previous Message ]New Message | Reply ]Next Message ]

Comments are owned by the poster. All other content is copyright 1998-2021 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.