Consider using std::vector (C++98 / C++11)

[Albrecht Schlosser]

Isn't it time to think about using simple std::container types in FLTK?

I've seen the necessity of using vectors in some situations (patches),
particularly useful would be

- std::vector<int>
- std::vector<Fl_Widget *>

I'm not asking to rewrite existing code, just to add such containers
where useful. The potential new widget Fl_Flex
(https://github.com/osen/FL_Flex) would be an example but I know of at
least one patch that suggested using a vector.

I don't know about real compatibility issues with old (maybe embedded)
systems and such. Do we still need to take care or can we "move our code
base a little forward" WRT more modern C++ standards? According to
https://www.cplusplus.com/reference/vector/vector/ class vector is
defined in C++98 with some additions in C++11.

If not (and I think one valid reason is enough, like a veto), then I
suggest to add some similar classes for internal usage rather than
inventing the wheel over and over again. I could search and give some
examples but I don't want to do this now.

All comments would be appreciated, not only from FLTK devs. Thanks.

[Bill Spitzak]

Back when fltk was created using std:: stuff was certainly much worse performance and storage wise compared to directly writing pointer manipulation like in C. However that has certainly changed over time, modern implementations especially on Linux are highly optimized. I suspect using std::vector<FlWidget*> everywhere possible would not cause any problems or incompatibility, the old widgets did hide the implementation pretty well.

--
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/6a1d9208-9cf0-28b6-bdf1-853ae2db9345%40online.de.

[imm]

On Thu, 15 Jul 2021, 19:38 Bill Spitzak wrote:

Back when fltk was created using std:: stuff was certainly much worse performance and storage wise compared to directly writing pointer manipulation like in C. However that has certainly changed over time, modern implementations especially on Linux are highly optimized. I suspect using std::vector<FlWidget*> everywhere possible would not cause any problems or incompatibility, the old widgets did hide the implementation pretty well.

Meant to reply to this ages ago... But forgot...

I got caught out by this a while back (might have been list rather than vector, but anyway...) where I'd updated a block of embedded code. In testing (on Windows) this went really well.

But the embedded version wouldn't even compile.

The key was that the gcc std lib *required* exception support, whereas the MS implementation did not. Our embedded targets don't support exceptions (not enough RAM and nowhere to propagate to anyway.) So that was the end of that!

The implementation may be "better" now of course but that's what happened back then.

The other key is not to expose the template in the API, as I've hit weird issues with that, where I think the compiler implemented the API differently between two modules due to... Something? Optimization settings? Don't know; compiled OK but choked in weird ways at runtime!

--
Ian
From my Fairphone FP3
   

[Albrecht Schlosser]

On 7/19/21 12:23 PM imm wrote:

On Thu, 15 Jul 2021, 19:38 Bill Spitzak wrote:

Back when fltk was created using std:: stuff was certainly much worse performance and storage wise compared to directly writing pointer manipulation like in C. However that has certainly changed over time, modern implementations especially on Linux are highly optimized. I suspect using std::vector<FlWidget*> everywhere possible would not cause any problems or incompatibility, the old widgets did hide the implementation pretty well.

Meant to reply to this ages ago... But forgot...

I got caught out by this a while back (might have been list rather than vector, but anyway...) where I'd updated a block of embedded code. In testing (on Windows) this went really well.

But the embedded version wouldn't even compile.

The key was that the gcc std lib *required* exception support, whereas the MS implementation did not. Our embedded targets don't support exceptions (not enough RAM and nowhere to propagate to anyway.) So that was the end of that!

That would be a strong reason not to use std::stuff in FLTK, even today - if it would still be the case.

The implementation may be "better" now of course but that's what happened back then.

Any chance to test on your [oldest | most primitive] embedded platforms, cross-compiler suites, or ... ?

The other key is not to expose the template in the API, as I've hit weird issues with that, where I think the compiler implemented the API differently between two modules due to... Something? Optimization settings? Don't know; compiled OK but choked in weird ways at runtime!

My intention was not to expose template code in the API. The only reason to use it would be simplification of internal code. Allocating varying size arrays and reallocating everywhere we need them is a code maintenance issue. Of course it can be done, but it's likely more code and error prone.

I'm thinking of new widgets that need more arrays than only the list of children. Layout stuff for instance, be it row/column [1] or grid [2] oriented.

There's also GitHub Issue #153 [3] and STR #3290 [4]. I'd say the biggest part of the solution is to avoid std::vector by including some own FLTK classes [5] [6]. This should at least be standardized (see below, solution (2)).

There are other (similar) solutions already included in FLTK, e.g.

FL/Fl_Table.H:157:  // An STL-ish vector without templates
FL/Fl_Table.H:158:  class FL_EXPORT IntVector {
FL/Fl_Table.H:167:    IntVector() { init(); }                                     // CTOR
FL/Fl_Table.H:168:    ~IntVector();                                               // DTOR
FL/Fl_Table.H:169:    IntVector(IntVector&o) { init(); copy(o.arr, o._size); }    // COPY CTOR
FL/Fl_Table.H:170:    IntVector& operator=(IntVector&o) {                         // ASSIGN
FL/Fl_Table.H:184:  IntVector _colwidths;                 // column widths in pixels
FL/Fl_Table.H:185:  IntVector _rowheights;                // row heights in pixels

FL/Fl_Table_Row.H:52:  // An STL-ish vector without templates
FL/Fl_Table_Row.H:53:  class FL_EXPORT CharVector {
FL/Fl_Table_Row.H:62:    CharVector() {                              // CTOR
FL/Fl_Table_Row.H:65:    ~CharVector();                              // DTOR
FL/Fl_Table_Row.H:66:    CharVector(CharVector&o) {                  // COPY CTOR
FL/Fl_Table_Row.H:70:    CharVector& operator=(CharVector&o) {       // ASSIGN

src/Fl_Help_View.cxx:7:// Buffer management (HV_Edit_Buffer) and more by AlbrechtS and others.
src/Fl_Help_View.cxx:292:class HV_Edit_Buffer {
src/Fl_Help_View.cxx:302:  HV_Edit_Buffer (int alloc = 1024, int ext = 1024);    // c'tor
src/Fl_Help_View.cxx:303:  ~HV_Edit_Buffer ();                                   // d'tor

This list could likely be continued.

I'd like to find a good solution for different kinds of vectors (variable size arrays) or maybe stacks or whatever we need:

(1) If we can use std:: stuff w/o compatibility issues: allow a selected subset of std::vector< ... > for internal usage beginning with FLTK 1.4.0.

(2) If we can't use it, create some internal FLTK classes we can use "everywhere" internally. These classes need not (must not?) be exposed in the public FLTK API.

How to find a solution? If we find at least one supported application/platform/system that does not allow us to use std:: stuff then we must use solution (2).

Ian, hence my question: would your (current) needs allow or disallow std::vector (etc.) stuff? If not we're done (solution 2), if yes the question remains open (needs more input).

Comments from everybody would be appreciated, particularly if an application/platform/system would NOT allow to use std:: stuff when building FLTK.

Thanks in advance.


- - -  Links  - - -

[1] A potential candidate Fl_Flex uses std::vector internally, see GitHub Issue #255:
https://github.com/fltk/fltk/issues/255
https://github.com/osen/FL_Flex/blob/main/FL_Flex.H

[2] A potential "Fl_Grid" widget (no candidates yet) would need all sorts of variable sized arrays (Issue #256):
https://github.com/fltk/fltk/issues/256

[3] https://github.com/fltk/fltk/issues/153
[4] https://www.fltk.org/str.php?L3290
[5] https://github.com/fltk/fltk/issues/153#issuecomment-756027342
[6] https://github.com/fltk/fltk/files/5780975/ol.diff.txt

[imm]

On Tue, 20 Jul 2021, 18:38 Albrecht Schlosser wrote:

But the embedded version wouldn't even compile.

The key was that the gcc std lib *required* exception support, whereas the MS implementation did not. Our embedded targets don't support exceptions (not enough RAM and nowhere to propagate to anyway.) So that was the end of that!

That would be a strong reason not to use std::stuff in FLTK, even today - if it would still be the case.

Just for clarity, I should emphasize I was not trying to get fltk running on the target, nor do I desire to.

Rather, I was wanting to note the unexpected dependency on exception support, which fltk has traditionally avoided.

The toolchain used was gcc-4.3, so pretty old (2008 or so) but that's not unusual for embedded tools.

The Windows prototype was also tested with gcc-4.3 (from mingw) but worked. It turns out that uses the MS std:: implementation, I think, which does not have that dependency.

I *think* I heard that dependency on exception is removed in later std:: lib versions but I do not know and can't currently test.

Any chance to test on your [oldest | most primitive] embedded platforms, cross-compiler suites, or ... ?

I'll try, but can't at the moment. May be a week or so yet...

However, my oldest/most primitive targets will never run fltk anyway, so they're not a constraint. I guess we'd need to determine which tools would be a problem... Somehow.

I'd like to find a good solution for different kinds of vectors (variable size arrays) or maybe stacks or whatever we need:

(1) If we can use std:: stuff w/o compatibility issues: allow a selected subset of std::vector< ... > for internal usage beginning with FLTK 1.4.0.

(2) If we can't use it, create some internal FLTK classes we can use "everywhere" internally. These classes need not (must not?) be exposed in the public FLTK API.

This is, in effect, the path I took...

Ian, hence my question: would your (current) needs allow or disallow std::vector (etc.) stuff? If not we're done (solution 2), if yes the question remains open (needs more input).

I do not know if any of the targets on which I currently run fltk have this constraint but I *believe* that they do not. Will check in due course.

The targets that I know for certain do have this constraint are not able to run fltk anyway.

[Albrecht Schlosser]

On 7/21/21 12:02 PM imm wrote:

On Tue, 20 Jul 2021, 18:38 Albrecht Schlosser wrote:

That would be a strong reason not to use std::stuff in FLTK, even today - if it would still be the case.

I *think* I heard that dependency on exception is removed in later std:: lib versions but I do not know and can't currently test.

Any chance to test on your [oldest | most primitive] embedded platforms, cross-compiler suites, or ... ?

I'll try, but can't at the moment. May be a week or so yet...

However, my oldest/most primitive targets will never run fltk anyway, so they're not a constraint. I guess we'd need to determine which tools would be a problem... Somehow.

OKAY, I withdraw my request to consider using std::vector etc.. There's no need to test. Thanks.

Thinking about the problem, the only valid answer we could get from testing is that it doesn't work. If it works, the basic question is still not answered: are there other systems that rely on FLTK and which can't use std:: stuff.

I believe the only logical conclusion is:

(2) If we can't use it, create some internal FLTK classes we can use "everywhere" internally. These classes need not (must not?) be exposed in the public FLTK API.

This is, in effect, the path I took...

... and I think that's what we need to do as well.

Thanks for reading and replying so far. IMHO this thread is now done.

I'll evaluate using already existing FLTK and maybe new classes and open another thread when I have something usable.

[Rob McDonald]

On Friday, July 23, 2021 at 6:14:46 AM UTC-7 Albrecht Schlosser wrote:

OKAY, I withdraw my request to consider using std::vector etc.. There's no need to test. Thanks.

Thinking about the problem, the only valid answer we could get from testing is that it doesn't work. If it works, the basic question is still not answered: are there other systems that rely on FLTK and which can't use std:: stuff.

I believe the only logical conclusion is:

(2) If we can't use it, create some internal FLTK classes we can use "everywhere" internally. These classes need not (must not?) be exposed in the public FLTK API.

This is, in effect, the path I took...

... and I think that's what we need to do as well.

Thanks for reading and replying so far. IMHO this thread is now done.

I'll evaluate using already existing FLTK and maybe new classes and open another thread when I have something usable.

While this may well be the pragmatic answer in this case, as an overall philosophy it is greatly disheartening and wholly unsatisfying.

It seems that forward progress will always be curtailed by a ghost in the room.  Some notion of long-dead systems that carry a veto lest we ever offend them.

I'm a big fan of supporting legacy systems and not breaking things -- even with great conservatism.  The difficulty I see here is that we don't have a well defined backwards compatibility target.

In my own project, I have struggled with what to set CMAKE_MINIMUM_VERSION to (a terrible mis-feature if ever there was one).  I had been holding some changes back because I believed I needed to support RHEL / Centos 7 - CMake 2.8.x.  Only recently one of my users on RH7 spoke up and said that my CMake build had long been broken on that platform and he has had to self-install (locally) CMake for a long time.  Progress had been needlessly frozen by a ghost I did not know and was not testing.

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? 

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 don't know where to draw that line -- and I'm not going to argue for any particular feature, compiler, or platform.  However, catering to a vague notion seems unsustainable.  In my own project, I held back changes for compatibility to a platform that didn't even work.

It seems a reasonable first principle would be that we can't claim to support anything that we can't test.  Travis, Jenkins, GitHub Actions, and all the other free/commercial CI platforms I am aware of only support platforms back one or two versions.  They certainly don't support anything exotic or embedded.  From there, it seems reasonable to expect users invested in support of antiquated systems to at least speak up if not volunteer to test on those platforms.

I realize this is very difficult -- many users don't follow these development lists -- but the alternative (supporting unknown vague legacy systems) is impossible.  When faced with impossible, difficult looks pretty good....

Perhaps we need a survey to search this out.  What platforms do users need supported -- and do you have any intention of continuing to update FLTK on those platforms to 1.4.X and beyond?

Rob

 

[Albrecht Schlosser]

On 7/24/21 3:12 AM Rob McDonald wrote:

On Friday, July 23, 2021 at 6:14:46 AM UTC-7 Albrecht Schlosser wrote:

OKAY, I withdraw my request to consider using std::vector etc.. There's no need to test. Thanks.

...

I'll evaluate using already existing FLTK and maybe new classes and open another thread when I have something usable.

While this may well be the pragmatic answer in this case, as an overall philosophy it is greatly disheartening and wholly unsatisfying.

I agree. We need a better strategy for the future, whatever this might be.

It seems that forward progress will always be curtailed by a ghost in the room.  Some notion of long-dead systems that carry a veto lest we ever offend them.

I'm a big fan of supporting legacy systems and not breaking things -- even with great conservatism.  The difficulty I see here is that we don't have a well defined backwards compatibility target.

Yes, indeed we don't have such a backwards compatibility target. What we have is our CMP [1] [2] that tells us what we can do and what we can't do. This is mostly from the time of FLTK 1.1 with some changes regarding the never released and now abandoned FLTK version 2.0.

This needs to be updated for the near future.

In my own project, I have struggled with what to set CMAKE_MINIMUM_VERSION to (a terrible mis-feature if ever there was one).  I had been holding some changes back because I believed I needed to support RHEL / Centos 7 - CMake 2.8.x.  Only recently one of my users on RH7 spoke up and said that my CMake build had long been broken on that platform and he has had to self-install (locally) CMake for a long time.  Progress had been needlessly frozen by a ghost I did not know and was not testing.

Good example.

<OT>

Side note, please understand this only as a hint for future development: I'm also not a fan of all these CMake CMP's but you could at least have tested your CMake project against the minimum CMake version (even if not a particular Linux release). CMake can be built pretty easily even on systems that only have a working C++ compiler, but if you have a current CMake it's even easier to build an older CMake version to be used in testing. I have several older and newer CMake versions installed under /usr/local:

$ ls -d1 /usr/local/cmake-3.*
/usr/local/cmake-3.10.3
/usr/local/cmake-3.16.9
/usr/local/cmake-3.18.6
/usr/local/cmake-3.20.0
/usr/local/cmake-3.20.1
/usr/local/cmake-3.20.5
/usr/local/cmake-3.2.3

and you can use a different version easily by just putting something like /usr/local/cmake-3.2.3/bin in front of your PATH or by using an alias. CMake will even save this version in its cache and will use this version for subsequent updates.

Another hint: I've recently started using docker containers to build FLTK versions on different platforms. This is a very interesting option. Docker containers are readily available for many system (Linux) flavors, just as those used with Google actions and other CI providers.

</OT>

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.

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 don't know where to draw that line -- and I'm not going to argue for any particular feature, compiler, or platform.  However, catering to a vague notion seems unsustainable.  In my own project, I held back changes for compatibility to a platform that didn't even work.

And I suspect that's somehow the case with FLTK as well. The current Makefile's (particularly for shared libs) and the (not working) dependency system with our autoconf build system are a mess. I'd really, really, really like to drop autoconf in favor of CMake [3] and move forward in our CMake support to newer CMake versions and more modern CMake features. (As discussed earlier, I know, and I didn't forget!).

It seems a reasonable first principle would be that we can't claim to support anything that we can't test.  Travis, Jenkins, GitHub Actions, and all the other free/commercial CI platforms I am aware of only support platforms back one or two versions.  They certainly don't support anything exotic or embedded.  From there, it seems reasonable to expect users invested in support of antiquated systems to at least speak up if not volunteer to test on those platforms.

I realize this is very difficult -- many users don't follow these development lists -- but the alternative (supporting unknown vague legacy systems) is impossible.  When faced with impossible, difficult looks pretty good....

Perhaps we need a survey to search this out.  What platforms do users need supported -- and do you have any intention of continuing to update FLTK on those platforms to 1.4.X and beyond?

We have our polling system on the website. My experience shows that many users vote once we open a new poll. I could do this, but what would be a good question and a good set of possible answers? Comments welcome.

OTOH, Rather than specifying what we support we could probably specify software (C++ standards, e.g. C++11) and build system (CMake version + pkg-config) requirements. For instance, minimum CMake version (with release dates):

v3.2.3       2015-06-01  <-- we're now here
v3.3.2       2015-09-16
v3.4.3       2016-01-25
v3.5.2       2016-04-15
v3.6.3       2016-11-02
v3.7.2       2017-01-13
v3.8.2       2017-05-31
v3.9.6       2017-11-10
v3.10.3      2018-03-16
v3.11.4      2018-06-14
v3.12.4      2018-11-02
v3.13.5      2019-05-14  <-- we need features of 3.13
v3.14.7      2019-09-30
v3.15.7      2020-02-04
v3.16.9      2020-09-15
v3.17.5      2020-09-15
v3.18.6      2021-02-11
v3.19.8      2021-04-06
v3.20.5      2021-06-21

Although we are using a fallback mechanism for CMake versions before 3.13 this is harder to maintain. I don't know how far we need to go back or how far we can move forward with our 'cmake_minimum_required' version.

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?


Links:

[1] https://www.fltk.org/cmp.php
[2] https://www.fltk.org/cmp.php#CS_CPP_PORTABILITY
[3] https://www.fltk.org/str.php?L2916
[4] https://en.cppreference.com/w/cpp/keyword/auto

[Rob McDonald]

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.

Rob

 

[Albrecht Schlosser]

On 7/24/21 11:42 PM Rob McDonald wrote:

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.

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.  ...  Not wanting to leave legacy users out of the newest features leads to supporting them forever.

This was not meant to define a strategy for the future. It does only describe the current situation.

There's another reason to do it this way: if we ever need to backport changes from the next gen FLTK (4.0) and create a new release this would be *much* easier for 1.4.x than for 1.3.x because of the big structural code base changes. This is also a pragmatic solution based on the current situation rather than a future strategy.

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.

Exactly. (But I would say "also for the sake of legacy systems" because it doesn't cost anything)

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.

We're probably not able to use this "testing everything we support" strategy. Even with docker you can only test Linux platforms on Linux (unless I'm missing something). I don't know what the CI providers exactly do for using Windows and macOS (maybe VM's?). And using the free CI tools as we do does only help to find some build issues. We can never test each build config and we can't test live GUI programs.

This is why I think we need to define software and build system requirements rather than specific system versions. Maybe there can be a mixture of both, but this needs to be discussed anyway (but not yet).

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.

Good point. I've also thought about using a regular release cycle in the future. This might be possible if we're only doing updates with some new features and bug fixes. The move from 1.3 to 1.4 with all that driver stuff and new build system (CMake) was a much bigger change. Such a change would maybe require an out of order release anyway.