Existing code should work the same, except for the underscore versions, but that's easy to remedy by giving two enum constants the same value. I would not use a #define for that.

That's much better, I didn't think of using two enum constants with the same value. However, defining the enum and documenting the values would be ... ugly. But that shouldn't prevent us from doing it.

The patch removes the link feature for our existing code. ...

Hmm, what exactly do you mean here? I don't think that we gained anything from the underscore enums except confusion because I don't think that "a good linker could optimize and remove all plastic drawing routines". The fact that the code to set up these boxtypes is definitely in our library (because we have '-s plastic' as you wrote) would make such optimization fail at runtime - if at all possible. Therefore I believe that we'd have seen bug reports and conclude that such (false) "optimizations" never happened.

Side note: Maybe that optimization could have been done in some very early FLTK versions, I don't know. You certainly know more about early FLTK versions than I do.

I can make a small patch if you feel more comfortable with that.
But ok, I will commit just the focus fix for now when I have the time to extract that.

I didn't want to say that this is really necessary. What I wrote were only my "thoughts". Let's further think about implications and risks. My main intention is to make FLTK 1.4 (as much as possible) backwards compatible with 1.3.x.

OK, final question: if we add the "underscore versions" of the enum (with documentation), can we assume that this PR would be 100% backwards compatible? If this can be assured then we should go for it.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <fltk/fltk/pull/958/c2077765927@github.com>