Roadmap to FLTK 1.4

[Manolo]

Could we write down a roadmap of needed operations until FLTK 1.4

can be presented as a Release Candidate?

I believe that branch contains important new features (HiDPI support,

CMake-based building, Pango support for the X11 platform) that would

be useful for many FLTK users.

A roadmap would help to reach that goal.

One issue that clearly needs fixing is #93

"Fl_Text_Editor + pango + word wrap -> hangs on scroll"

It contains a proposal for a work-around, but another approach

may also be considered.

[Greg Ercolano]

On 2020-11-23 09:03, Manolo wrote:

Could we write down a roadmap of needed operations until FLTK 1.4

can be presented as a Release Candidate?

I believe that branch contains important new features (HiDPI support,

CMake-based building, Pango support for the X11 platform) that would

be useful for many FLTK users.

A roadmap would help to reach that goal.

    +1

    Usually this involves just going through all the bugs and listing the items that
    must be fixed for release, and lower the priority of items that can be delayed for
    subsequent maintenance releases.

    As Linus always said, "release early, and release often."
    Doesn't seem to be our motto, but maybe should, lol.

    Since this is a major release (1.4.0), we should put some priority on anything that
    affects ABI, esp. if it involves adding members to structures that can be used in
    later fixes. Sometimes thinking ahead like adding a char just for bit flags we know
    we'll need can be useful to prevent ABI breakage during the maintenance path.

One issue that clearly needs fixing is #93

"Fl_Text_Editor + pango + word wrap -> hangs on scroll"

It contains a proposal for a work-around, but another approach may also be considered.

    I might be wrong, but pango support could probably be moved to being a fix in
    a maintenance release, esp. if it's a tough one to solve.

[Evan Laforge]

> Since this is a major release (1.4.0), we should put some priority on anything that
> affects ABI, esp. if it involves adding members to structures that can be used in
> later fixes. Sometimes thinking ahead like adding a char just for bit flags we know
> we'll need can be useful to prevent ABI breakage during the maintenance path.

There are also a bunch of non-virtual methods that could be made
virtual. I don't remember exactly what, since my list was from years
ago, but if someone has been keeping track, now is a good time to do
those changes!

Here's a fragment from an old file I was able to find:

Fl_Input_::value should be virtual
Fl_Input_::position shadows Fl_Widget::position with a different meaning.

I'm sure there are many more non-virtual functions that could be made virtual!

[Greg Ercolano]

On 2020-11-23 12:08, Evan Laforge wrote:
>> Since this is a major release (1.4.0), we should put some priority on anything that

>> affects ABI [..]
>>
>> There are also a bunch of non-virtual methods that could be made virtual [..]

    +1 -- now is definitely the time to do that sort of thing.

    As I think Albrecht mentioned somewhere, perhaps in an issue, there needs to
    be a search for FIXME and maybe XXX/TODO items.

    

[Albrecht Schlosser]

On 11/23/20 9:40 PM Greg Ercolano wrote:
> On 2020-11-23 12:08, Evan Laforge wrote:
>>> Since this is a major release (1.4.0), we should put some priority on anything that
>>> affects ABI [..]
>>>
>>> There are also a bunch of non-virtual methods that could be made virtual [..]
>
>     +1 -- now is definitely the time to do that sort of thing.

Yes, I had a lot of such non-virtual methods in mind as well, but some
of these can't be easily converted to virtual. Unfortunately there are
too many conflicts. I can investigate (and look in my internal notes)
for more info tomorrow.

>     As I think Albrecht mentioned somewhere, perhaps in an issue, there needs to
>     be a search for FIXME and maybe XXX/TODO items.

That sort of thing is what I'd like to get done before we release 1.4.0.

Technically spoken: GitHub has a "Milestone" feature we could and IMHO
*should* explore for this goal.

I created a Milestone "1.4.0" to try that feature some time ago. We can
add issues as we like and should try to resolve those (first) before we
release 1.4.0. Of course we need to find consensus about what issues
(and STR's) should be resolved in 1.4.0.

Note that I added two "random" issues, this needs to be checked and
evaluated. We can of course remove these (or not).

https://github.com/fltk/fltk/milestone/1

(go to https://github.com/fltk/fltk/issues and click on "Milestones" to
go there).

I'll add more of my thoughts and open issues tomorrow or even later...

[Lauri Kasanen]

On Mon, 23 Nov 2020 09:03:23 -0800 (PST)
Manolo <manol...@gmail.com> wrote:

>
> Could we write down a roadmap of needed operations until FLTK 1.4
> can be presented as a Release Candidate?

Long time no see. Looking at my old todo, I had wanted a fix for the @
symbols, and the & symbols in menu items, to make them both per-widget
disable-able. There were patches for at least &, but I'm not sure if any
of them were committed.

- Lauri

[duncan]

    As I think Albrecht mentioned somewhere, perhaps in an issue, there needs to
    be a search for FIXME and maybe XXX/TODO items.

There are a lot of places in the documentation with a FIXME / TODO, especially

the UTF-8/Unicode stuff where it wasn't exactly clear how the two approaches

being merged would work together, and because the person updating the dox,

i.e. me, didn't really have much experience of non-ASCII programming.

But maybe these FIXME/TODO markers are not a show-stopper for 1.4.x

D.