|
|
I have over 10,000 users of a
suite of amateur radio Emergency Communications programs. Many
of the users are associated with the American Red Cross. I
distribute source, Windows installation binaries and OS-X /
macOS disk image files (dmgs), http://www.w1hkj.com. The
flagship program, fldigi, has been in development with many
releases over the last 18 years. All of the programs use Fltk
as the UI library. Fltk-1.3.5 produces excellent binaries for
G4 (Motorola), i386, and x86_64 OS-X/macOS targets, up to and
including 10.15.x. Those same binaries will not run on Big Sur,
11.x. The code executes, but the UI produces blank dialogs. My
macOS testers report that the same code linked to Fltk-1.4.x
(latest git commit) will run and display correctly, but not for
every combination of display / video h/w. My three M1 platform
testers report that Rosetta-2 fails to produce a fulfilling
run-time for both the 1.3.5 and 1.4.0 Fltk builds. One of the
M1 testers is a member of my development team. I expect he will
be able to provide us with additional insight. I've asked him
to create a full build suite on the M1 system. Fltk first of
course.
Apple seems intent on making life difficult for third party
developers. I am grateful for all of the work that the Fltk
developer/maintainer team puts forth. Thank you.
David
On 11/22/20 3:52 PM, Albrecht Schlosser
wrote:
On
11/22/20 10:15 PM Rob McDonald wrote:
Some of my users are reporting problems
with MacOS Big Sur. It looks like these have been addressed
with some of the recent work by Manolo and the team.
I am currently using 1.3.5 with no patches. I'd prefer to stick
with a stable version in general as it makes everyone's life a
bit easier.
Article #1611
<https://www.fltk.org/articles.php?L1611> says that 1.3.X
is still receiving MacOS related fixes, but other comments
indicate that it is pretty stagnant.
I'd like to release 1.3.6 maybe this year or at the beginning of
2021. I'm currently working on backporting some CMake
modifications, particularly addressing Windows DLL builds but also
other stuff. This should definitely go into 1.3.6.
We have 26 commits in branch-1.3 since the release of 1.3.5. Many
of these commits are related to macOS.
I can't speak for Manolo, but since the new Apple M1 processor is
available there may be some necessary fixes for macOS as well (or
not, who knows?).
All that could likely be achieved during the next weeks/months so
that we can hopefully release 1.3.6 as I wrote above. There's no
defined plan or schedule however yet.
1.4.X seems to have no particular path to
a .0 release. I am reluctant to grab master on a random day as
you never know if that will relatively stable or in the middle
of a mess.
You could pick a version that "looks good" (read the commit logs)
and watch the further development. Then test this version with
your application(s) and watch for further commits that may be
relevant to you or fix issues you see when testing. If everything
is fine, use this release for production code.
So, what is the current recommendation?
Use the tip of branch-1.3? Use the tip of master? Use some
random SHA version that is known to be 'pretty good'?
The tip of 1.3 should be pretty stable as there are no new
features but there are also fixes that may have introduced new
bugs. Probably not much though but there have been no release
candidates and hence no wide testing. If you can wait until the
beginning of 2021 chances are that there will be a 1.3.6 release
with one or more RC's.
Is there an uncharted plan for 1.4.0?
1.3.5 was 20+ months ago
My opinion is that 1.4.0 still needs some improvements and I'm
working on some of them. Before we release 1.4.0 there should also
be a thorough code review and there are some "FIXME" comments that
should be reviewed and maybe fixed. It's still in progress.
That said, I'd suggest to start with the tip of branch-1.3, test
your app (as if this was a RC) and wait for upcoming changes for
CMake and macOS and then for release 1.3.6.
I would also give git master (1.4.x) a go to see if this works for
you. The code is really mostly API compatible and the few
differences can be made compatible, for instance using the correct
include files. Both versions are slightly different in their
requirements but if you include the *correct* headers everything
should be fine with both versions (no need to #ifdef ...). I
intend to improve the docs with hints what to do. If you find any
regressions you're invited to report these in fltk.coredev. TIA.
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/0b4dbbd5-be00-61fd-8f3f-5a3c13dde520%40bellsouth.net.
[ Direct Link to Message ] | |
|
| |