FLTK 1.4.0 release schedule

[Albrecht Schlosser]

Hi all,

I'm proposing a release schedule in the hope that I can do those things I need to do in the remaining time:


(1) Feature freeze at Mar 1, 2022 or near that date.

(2) Release candidate 1 at Mar 15, 2022.

(3) Following release candidates depending on feedback.

(4) Release of FLTK 1.4.0 in April 2022, depending on release candidates and feedback.


That said: I'm going to concentrate solely on the implementation of pending features and issues for the release. I will still follow discussions but I will likely not be very responsive, don't worry about that.

I'm not sure yet if I can hold the feature freeze date in 6 weeks but I'll try.

Whenever I have something new to test (either pushed to the FLTK repo or in my fork) I'll let you know and I would appreciate quick feedback.

Thanks

Milestones we should IMHO consider for inclusion:

- Wayland support (Manolo's branch)
- consolidated timeout handling (WIP)
- Fl_Grid widget (WIP)
- touch gestures on macOS and Windows (WIP)
- CMake improvements (GitHub Issues)

Comments and other suggestions welcome.

[Manolo]

That proposal is very good for me.

Once touch gestures will be in macOS and Windows, I'll try to reproduce that for Wayland.

[melcher....@googlemail.com]

tl;dr : yes, that sounds great

long answer and question:

Fluid: I have reorganised Fluid a little bit and fixed a few pressing issues, like i18n, dnd, insertion points, etc. . Fluid itself probably needs a separate post though.

Preferences: are 80% done and fix the most common issues: where is my file, locale, etc. . Still to do is the location of files on Linux.

Text Styles: background color should be relatively easy to implement

OTOH: there is some dead code that I started just before my long break.

• So, the Nano/Pico stuff, should we remove that before the big release? It's not working as intended, still some users ran with it and implemented half-working stuff. IMHO, if it isn't done, it has no place in a release (or better: I should have never checked that in to begin with. Sorry!)
  
• The Android stuff is also very half-assed. It pollutes some of the CMake files and it is just a proof of concept. Yet some users seem to have at least tried it. Same question: remove all traces, fix it, and put it in 1.5.0? Or leave it and drag it along?

I'll add more as things come to mind.

[Albrecht Schlosser]

On 1/22/22 13:00 'melcher....@googlemail.com' via fltk.coredev wrote:

tl;dr : yes, that sounds great

Welcome.

long answer and question:

Fluid: I have reorganised Fluid a little bit and fixed a few pressing issues, like i18n, dnd, insertion points, etc. . Fluid itself probably needs a separate post though.

What "post" do you mean?

Fluid has an own chapter in the docs. Do you think that (some of) the new features should be mentioned?

Preferences: are 80% done and fix the most common issues: where is my file, locale, etc. . Still to do is the location of files on Linux.

Every step forward is a good step. I'd like to have the XDG stuff (for others: location of preferences files) implemented in 1.4.0 though because we changed the location of preferences files anyway. You (Matthias) documented this in the Fl_Preferences docs and I added a paragraph in the "Migration" chapter of the docs:
https://fltk.gitlab.io/fltk/migration_1_4.html#migration_1_4_preferences

This could maybe be improved if need be.

Text Styles: background color should be relatively easy to implement

You mean styles in Fl_Text_Display? Would be great to have, I think this has been a FAQ.

OTOH: there is some dead code that I started just before my long break.

• So, the Nano/Pico stuff, should we remove that before the big release? It's not working as intended, still some users ran with it and implemented half-working stuff. IMHO, if it isn't done, it has no place in a release (or better: I should have never checked that in to begin with. Sorry!)
  
• The Android stuff is also very half-assed. It pollutes some of the CMake files and it is just a proof of concept. Yet some users seem to have at least tried it. Same question: remove all traces, fix it, and put it in 1.5.0? Or leave it and drag it along?

From a maintenance point I vote clearly for removing this stuff: Android, Nano/Pico, SDL(2), whatever. As you say, this unfinished stuff pollutes CMake files (and is probably not available in configure/make builds) and makes things more complicated than necessary. Users are asking things about unfinished stuff and some are even criticizing non-working (experimental) drivers.

I'd love to remove all this for a clean release.

I've had a hard time to integrate my new (WIP) Fl_Timeout features [1] in the Android port and I'm pretty sure I broke something because I can't test it. There's also much unimplemented stuff in these "Android drivers" which seems to be copied from the Windows (WinAPI) drivers which is weird anyway (although it's all deactivated by #if's). I didn't touch the pico and SDL drivers which *would* need changes.

It's also a problem if you search for a function or global and find it in experimental and/or dead code!

These are all points for the removal of unused, unfinished, beta, experimental driver stuff from the official repo.

+1 to remove these experimental drivers from the master branch!

Nothing would be deleted from the repository anyway, all this stuff would still be there. We could set a tag or create a branch "experimental" at the current point and, if anybody wants it, they can check out this branch (or tag). They could even fork it...

If you (Matthias) want to continue development of the Android port or any of the other ports I suggest to do it in an own fork where interested users can find it and we can decide to merge it back if (when) it gets ready to use. If this is an "official" fork we can even leave a note in README.experimental.txt (or README.Android.txt) where to find the experimental code.

I'll add more as things come to mind.

I hope there's not too much that needs to go into 1.4.0. ;-)

----  New Timeout handling (work in progress) ----

[1] My Fl_Timeout branch can be found in my fork: https://github.com/Albrecht-S/fltk/tree/Fl_Timeout
This branch builds and works fine on all major platforms (one or two test programs can't build with MSVC but that's not important).
The new internal Fl_Timeout class deals with all Fl::add_timeout() etc. features in a platform independent way and thus removes lots of platform specific code. All timeout related code is cross-platform and the same on all platforms with one minor known exception: timer resolution on Windows may be lower than on other platforms.

If anybody likes to test, please check out my fork and try branch Fl_Timeout.

$ git clone https://github.com/Albrecht-S/fltk.git fltk-timeout
$ cd fltk-timeout
$ git checkout Fl_Timeout

... build with configure/make or CMake, no further options required.

All feedback with "real programs" would be appreciated!

[Gonzalo Garramuño]

El 22/1/22 a las 09:00, 'melcher....@googlemail.com' via fltk.coredev
escribió:

> tl;dr : yes, that sounds great
>
> long answer and question:
>
> Fluid: I have reorganised Fluid a little bit and fixed a few pressing
> issues, like i18n, dnd, insertion points, etc. . Fluid itself probably
> needs a separate post though.

Mathias,

Where can I find the new i18n code?  I would like to test it when I have
the time.

[Greg Ercolano]

On 1/22/22 8:53 AM, Albrecht Schlosser wrote:

On 1/22/22 13:00 'melcher....@googlemail.com' via fltk.coredev wrote:

[..] Fluid itself probably needs a separate post though.

What "post" do you mean?

    I think Matt means he'll be following up with another post/thread
    with all the details about fluid that he's working on, presumably too long
    for this thread.

[Albrecht Schlosser]

On 1/22/22 18:34 Gonzalo Garramuño wrote:
>
> Where can I find the new i18n code?  I would like to test it when I
> have the time.

It's in git in the master branch. You can activate it as before in the
project settings dialog.

I can't tell though how to use it.

[melcher....@googlemail.com]

On 1/22/22 18:34 Gonzalo Garramuño wrote:
>
> Where can I find the new i18n code?  I would like to test it when I
> have the time.

 

I18n in Fluid was broken. I had a lot of back and forth with Albrecht about it because it used to work somewhat, but was no broken in other places for quite a while. I went through the GNU gettext documentation an updated Fluid to their recommendations. Particularly the initialisation of static text (Menu item labels) has been reworked, and the Unix tool `xgettext` will now output all strings that need to be translated. This was all tested with a German version the the test app "Preferences" since it is a Fluid-only app with pulldown menus and lots of labels.

Admittedly, I have not put the same amount of work into `catgets` which seems to be used a lot less anyway.

If would be really helpful if you could try it out too and point me at issues, so I can fix stuff before 1.4.0 . ;-)

[melcher....@googlemail.com]

Albrecht Schlosser schrieb am Samstag, 22. Januar 2022 um 17:53:31 UTC+1:

Fluid has an own chapter in the docs. Do you think that (some of) the new features should be mentioned?

Yes, I will update the docs when I have the time. The extended Fluid docs inside the `fluid` directory won't be finished and will be moved into an experimental branch (again, I will write a another Fluid post).

> Preferences: are 80% done and fix the most common issues: where is my file, locale, etc. . Still to do is the location of files on Linux.

I'd like to have the XDG stuff (for others: location of preferences files) implemented in 1.4.0 though

Yeah, I'll implement that soon. I have enough input now,

> Text Styles: background color should be relatively easy to implement

You mean styles in Fl_Text_Display? Would be great to have, I think this has been a FAQ.

There is an STR assigned to me already anyway ;-) 

 

> OTOH: there is some dead code that I started just before my long break.

I'd love to remove all this for a clean release.

Ok, I will put it into an experimental branch as soon as I get another +1.

 

[Greg Ercolano]

On 1/22/22 12:45 PM, 'melcher....@googlemail.com' via fltk.coredev wrote:

I'd love to remove all this for a clean release.

Ok, I will put it into an experimental branch as soon as I get another +1.

    A cleanup is a +1 from me, unless you think it'd in any way
    delay the 1.4.0 release sched..

[Albrecht Schlosser]

On 1/22/22 23:03 Greg Ercolano wrote:

On 1/22/22 12:45 PM, 'melcher....@googlemail.com' via fltk.coredev wrote:

I'd love to remove all this for a clean release.

Ok, I will put it into an experimental branch as soon as I get another +1.

... in your fork, please. (?)

    A cleanup is a +1 from me, unless you think it'd in any way
    delay the 1.4.0 release sched..

It's the opposite: removing the unused and unfinished test platforms would speed up the schedule - at least for me.

Example platforms and drivers that don't exist make things much easier.

[melcher....@googlemail.com]

Albrecht Schlosser schrieb am Samstag, 22. Januar 2022 um 23:30:59 UTC+1:

On 1/22/22 23:03 Greg Ercolano wrote:

On 1/22/22 12:45 PM, 'matt' via fltk.coredev wrote:

I'd love to remove all this for a clean release.

Ok, I will put it into an experimental branch as soon as I get another +1.

... in your fork, please. (?)

Yes, ok. It only makes sense to continue coding here if I am able to wrap things up within a reasonable time frame, and if it fully works then, I can merge it back.

 

    A cleanup is a +1 from me, unless you think it'd in any way
    delay the 1.4.0 release sched..

It's the opposite: removing the unused and unfinished test platforms would speed up the schedule - at least for me.

And easier to maintain. Thanks Greg and Albrecht. I'll clean that up.

 

[Albrecht Schlosser]

FTR:

As discussed with Matt via PM I took a stab at it and created PR #376:
https://github.com/fltk/fltk/pull/376

If nobody objects and I don't find any glitches I'll merge this PR tomorrow (Sunday).

[Gonzalo Garramuño]

El 22/1/22 a las 17:39, 'melcher....@googlemail.com' via fltk.coredev escribió:

If would be really helpful if you could try it out too and point me at issues, so I can fix stuff before 1.4.0 . ;-)

I tried it with xgettext and all seems to work fine.  I'll do more testing when I have more time.