| |
| |
On 11/20/22 12:23 Greg Ercolano wrote:
On 11/20/22 01:34, 'melcher....@googlemail.com' via fltk.coredev wrote:
Hi Devs,
tl;dr : I would like to overhaul the menubar code, and I would like
to do it incrementally, so we can find regressions. I want to use the
master branch for that, but I would like to hear you first, since
that may add work.
Cool! Sounds a little scary though, lol. But maybe that's needed.
Yes, I agree to all three points: cool, scary, and needed.
We seem to keep holding back 1.4.0 release, so I'm thinking we'd need
to keep the old code the default, but could maybe make your code a
build option that can be turned on to test, and later it could become
the default?
I'm really afraid that such massive changes would have unforeseeable
effects and might break user code. Once we push them to master it would
be very hard to turn this back.
Hence I would suggest to use a branch, probably in a (i.e. Matthias')
fork for first testing. I would volunteer to test and once we (me and
other volunteers) see the code and find it "good enough" (i.e. unlikely
to break existing code) we can still decide whether to merge it in
master or not.
I know that old application code might be using perhaps "unsavory"
ways of accessing the internals of Fl_Menu's data to work around
API limitations, which a code cleanup might break.
Yes, I'm also afraid of such effects. Maybe manipulations in
Fl_Menu_Item arrays etc. that we don't expect.
Or, should the rewrite have a new API, e.g. Fl_Menubar_V2, Fl_Menu_V2
so you can go bananas on the API, without having to worry about
breaking
old code (since the old Fl_Menubar / Fl_Menu API would remain
"forever")
That's indeed an option but in the end we'd need to *replace* the old
menu code with the new code for one of the next releases. Keeping that
old code "forever" would be a problem I'd like to avoid.
I think in a later phase a build option that would *replace* the old
menu code with the new code so users can test their own applications w/o
rewriting anything would be desirable.
I think we can't decide what to do (incrementally integrate in master or
not) before we see the code. What I definitely don't want is "trying"
something (in master) that doesn't work and needs to be reverted or is
perhaps released at some time and breaks user code.
That said, this is my statement for now, w/o seeing the code, just from
a "FLTK management" point of view. I have some more questions to the
technical details mentioned by Matthias which I will ask in a separate
message.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/70080b2a-95b1-63a3-70ec-e16b353123bc%40online.de.
[ Direct Link to Message ] | |
|
| |
