FLTK 1.3.6 Release Candidate 1 is now available for download and testing

58 views
Skip to first unread message

Albrecht Schlosser

unread,
Apr 26, 2021, 4:16:26 PM4/26/21
to fltk.coredev
The first release candidate for FLTK 1.3.6 is now available for download and testing.

Please look for:

  fltk-1.3.6rc1-source.tar.gz

.. on the FLTK downloads page https://www.fltk.org/software.php

Please test and report bugs within 2 weeks (until May 10, 2021) if you find any issues with this release candidate.

Please see the following page on how to report bugs and issues:

  https://www.fltk.org/bugs.php

Note: Since problems reported on the FLTK newsgroups or mailing lists are *not* automatically entered as bug reports, it is imperative that you report any problems using a "GitHub Issue" as described in 'bugs.php' mentioned above.


For more information on this release please see this article:

  https://www.fltk.org/articles.php?L1749

Manolo

unread,
Apr 29, 2021, 5:15:51 AM4/29/21
to fltk.coredev
On Monday, April 26, 2021 at 10:16:26 PM UTC+2 Albrecht Schlosser wrote:
The first release candidate for FLTK 1.3.6 is now available for download and testing.
Please test and report bugs within 2 weeks (until May 10, 2021) if you find any issues with this release candidate.

Many thanks to Albrecht for putting up this RC.

Here are the tests I performed, all errorless:
- standard configure build under macOS 11.2.3
- configure --enable-x11 build under macOS 11
- standard configure build under Windows XP

Albrecht Schlosser

unread,
Apr 29, 2021, 6:45:48 AM4/29/21
to fltkc...@googlegroups.com
On 4/29/21 11:15 AM Manolo wrote:
>
>
> On Monday, April 26, 2021 at 10:16:26 PM UTC+2 Albrecht Schlosser wrote:
>
> The first release candidate for FLTK 1.3.6 is now available for
> download and testing.
> Please test and report bugs within 2 weeks (until May 10, 2021) if
> you find any issues with this release candidate.
>
>
> Many thanks to Albrecht for putting up this RC.

Welcome. Thanks for testing...

> Here are the tests I performed, all errorless:
> - standard configure build under macOS 11.2.3
> - configure --enable-x11 build under macOS 11
> - standard configure build under Windows XP

Did you notice the error report from Bob Tolbert about:

/Users/bob/build/fltk-1.3.6rc1/version:1:1: error:

...
expected unqualified-id
1.3.6
^

It seems clear to me that this is caused by our file named VERSION in
the FLTK root directory which I asked Bob to rename and build again.
This file is included by system headers which want to #include
<version>, a new C++ header.

I already committed a fix to Git on branch-1.3.

My question to you (and others): Do you have a macOS system with a case
/insensitive/ file system where you can test and see if the error
manifests? That's just for curiosity but it might help. I know that we
had a user report of the same issue on Windows (and I renamed the file
in 1.4.0).

Maybe the build needs to be run with --std=C++11 or C++14 or whatever to
trigger the error though.

A simple test should be to `git clone` the FLTK repo and run `make` in
the FLTK root dir.

Bob Tolbert

unread,
Apr 29, 2021, 11:03:56 AM4/29/21
to fltkc...@googlegroups.com
I just cloned from github and checked out the 1.3 branch. With the renamed VERSION file, everything builds great on macOS

I tested the build on an M1 Mac as well. Looks great and the few apps I tried run really well.

There is a single change people can make on macOS to allow building a "universal" app.  I added this one line in "cmake/Setup.cmake" 
$ git diff
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
modified: CMake/setup.cmake
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
@ CMake/setup.cmake:25 @
set (EXECUTABLE_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/bin)
set (LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/lib)
set (ARCHIVE_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/lib)
set (CMAKE_OSX_ARCHITECTURES "arm64;x86_64")

# Search for modules in the FLTK source dir first
set (CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/CMake")


and after a rebuild, you can see the results are fat binaries:

$ file bin/fluid.app/Contents/MacOS/fluid
bin/fluid.app/Contents/MacOS/fluid: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
bin/fluid.app/Contents/MacOS/fluid (for architecture x86_64): Mach-O 64-bit executable x86_64
bin/fluid.app/Contents/MacOS/fluid (for architecture arm64): Mach-O 64-bit executable arm64


Bob Tolbert

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/bf76319e-b341-667d-53d5-e9d0b7e7281f%40online.de.

Albrecht Schlosser

unread,
Apr 29, 2021, 11:29:22 AM4/29/21
to fltkc...@googlegroups.com
On 4/29/21 4:36 PM Bob Tolbert wrote:
> I just cloned from github and checked out the 1.3 branch. With the
> renamed VERSION file, everything builds great on macOS
>
> I tested the build on an M1 Mac as well. Looks great and the few apps I
> tried run really well.

Thanks for the feedback and this additional test.

> There is a single change people can make on macOS to allow building a
> "universal" app.  I added this one line in "cmake/Setup.cmake"
> $ git diff
> ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
> modified: CMake/setup.cmake
> ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
> @ CMake/setup.cmake:25 @
> set (EXECUTABLE_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/bin)
> set (LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/lib)
> set (ARCHIVE_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/lib)
> *set (CMAKE_OSX_ARCHITECTURES "arm64;x86_64")*
>
> # Search for modules in the FLTK source dir first
> set (CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/CMake")
>
> and after a rebuild, you can see the results are fat binaries:
> ...

Thanks for this hint as well.

Setting CMAKE_OSX_ARCHITECTURES is the right variable but I do /not/
recommend to change setup.cmake and such a change will not be
incorporated in the official sources (because it would overwrite the
cache variable).

A better way to achieve this is to set the cache variable
CMAKE_OSX_ARCHITECTURES either in the CMake GUI or on the commandline:

cmake -D 'CMAKE_OSX_ARCHITECTURES=arm64;x86_64' <...>

if you want to build universal apps.

Maybe we will add a macOS specific option to let the user select for
which architecture to build in 1.4.0.

Manolo

unread,
Apr 29, 2021, 1:21:24 PM4/29/21
to fltk.coredev
On Thursday, April 29, 2021 at 12:45:48 PM UTC+2 Albrecht Schlosser wrote:
Did you notice the error report from Bob Tolbert about:
/Users/bob/build/fltk-1.3.6rc1/version:1:1: error:
...
expected unqualified-id
1.3.6
^
No. I had no error whatsoever.


It seems clear to me that this is caused by our file named VERSION in
the FLTK root directory which I asked Bob to rename and build again.
This file is included by system headers which want to #include
<version>, a new C++ header.

I already committed a fix to Git on branch-1.3.

My question to you (and others): Do you have a macOS system with a case
/insensitive/ file system where you can test and see if the error
manifests? That's just for curiosity but it might help. I know that we
had a user report of the same issue on Windows (and I renamed the file
in 1.4.0).
Do you really mean "a case insensitive macOS system" ?
That's what a standard macOS is. So yours is probably case insensitive.

Albrecht Schlosser

unread,
Apr 29, 2021, 2:15:06 PM4/29/21
to fltkc...@googlegroups.com
On 4/29/21 7:21 PM Manolo wrote:
>
> Do you really mean "a case insensitive macOS system" ?

Yes.

> That's what a standard macOS is. So yours is probably case insensitive.

Oh yes, partially. ;-)

I thought they had changed this in a new filesystem, but indeed I can
see that files are still found if I mistype the case.

However, I'm used to use tab completion, and in that case you /need/ to
type the correct case for tab completion to work, for instance:

$ ls /ap<tab>

doesn't work whereas

$ ls /Ap<tab>

worked. This confused me, thanks for the correction.

Bob Tolbert

unread,
Apr 29, 2021, 2:30:33 PM4/29/21
to fltkc...@googlegroups.com
I certainly didn't mean to make a permanent change to build Universal apps. Just wanted to point out that it built and runs just dandy.

Bob

--
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...@googlegroups.com.

Albrecht Schlosser

unread,
Apr 29, 2021, 2:53:33 PM4/29/21
to fltkc...@googlegroups.com
On 4/29/21 8:30 PM Bob Tolbert wrote:

> I certainly didn't mean to make a permanent change to build Universal
> apps. Just wanted to point out that it built and runs just dandy.

That's good and appreciated,, thanks and thanks for the clarification.
But I also wanted to prevent other users from copying what you did and
suggest a better method. All fine!

Manolo

unread,
Apr 30, 2021, 2:50:43 PM4/30/21
to fltk.coredev
Le jeudi 29 avril 2021 à 12:45:48 UTC+2, Albrecht Schlosser a écrit :
Did you notice the error report from Bob Tolbert about:

/Users/bob/build/fltk-1.3.6rc1/version:1:1: error:

...
expected unqualified-id
1.3.6
^

It seems clear to me that this is caused by our file named VERSION in
the FLTK root directory which I asked Bob to rename and build again.

New build on another system: macOS 11.3 with M1 processor:
this time, I get the error mentionned above, and indeed the error
disappears when file VERSION is renamed.
I've seen that has been fixed already in the git repository.

Besides this, both configure-based and CMake-based builds run OK.

Albrecht Schlosser

unread,
Apr 30, 2021, 3:42:47 PM4/30/21
to fltkc...@googlegroups.com
On 4/30/21 8:50 PM Manolo wrote:
>
> Le jeudi 29 avril 2021 à 12:45:48 UTC+2, Albrecht Schlosser a écrit :
>
> Did you notice the error report from Bob Tolbert about:
>
> /Users/bob/build/fltk-1.3.6rc1/version:1:1: error:
>
> ...
> expected unqualified-id
> 1.3.6
> ^
>
> It seems clear to me that this is caused by our file named VERSION in
> the FLTK root directory which I asked Bob to rename and build again.
>
> New build on another system: macOS 11.3 with M1 processor:
> this time, I get the error mentionned above, and indeed the error
> disappears when file VERSION is renamed.

Thanks for confirmation.

I just started the upgrade from 11.2.3 to 11.3 on my MacBook Air (M1). I
didn't experience this problem on my own system with 11.2.3, and the
upgrade will take a while before I can test the new version.

Do you have an idea what could have caused the difference?

> I've seen that has been fixed already in the git repository.

Yes, I committed the fix quickly because we have the same fix in 1.4
already.

> Besides this, both configure-based and CMake-based builds run OK.

Thanks for your feedback.

Manolo

unread,
May 1, 2021, 3:12:30 AM5/1/21
to fltk.coredev
On Friday, April 30, 2021 at 8:50:43 PM UTC+2 Manolo wrote:

Besides this, both configure-based and CMake-based builds run OK.

Wait a minute: the build step runs OK, but I find that test apps having a custom icon
(checkers, blocks and sudoku) don't start when the app is double-clicked.
I see that with 11.3 on M1 but not with 11.2.3 on x86_64.
I'll look into that.

Albrecht Schlosser

unread,
May 1, 2021, 7:22:37 AM5/1/21
to fltkc...@googlegroups.com
No problem here. I built several combinations and everything works fine
when double-clicking apps with icons (and others as well):

configure/make: default build

cmake/ninja: default, i.e. CMAKE_BUILD_TYPE=(empty), Release, Debug

ABI-Version: empty, 10306

To "simplify" my tests I ran the build process, opened a Finder window
from the build directory with

open bin/test

and then clicked on the apps in question. Is that (similar to) what you did?

Note: I previously installed the Xcode commandline tools and this time
they worked fine after the upgrade (I didn't need to reinstall).
However, I did not yet update Xcode for all these tests above.

I'm now upgrading to Xcode 12.5 (~80% done). I'll try again after the
upgrade just in case this changes anything. Which Xcode version do you
have installed on your 11.3 M1 mac?

Manolo

unread,
May 1, 2021, 10:57:42 AM5/1/21
to fltk.coredev
Le samedi 1 mai 2021 à 13:22:37 UTC+2, Albrecht Schlosser a écrit :
On 5/1/21 9:12 AM Manolo wrote:
>
> On Friday, April 30, 2021 at 8:50:43 PM UTC+2 Manolo wrote:
>
> Wait a minute: the build step runs OK, but I find that test apps having
> a custom icon
> (checkers, blocks and sudoku) don't start when the app is double-clicked.
> I see that with 11.3 on M1 but not with 11.2.3 on x86_64.

No problem here. I built several combinations and everything works fine
when double-clicking apps with icons (and others as well):

configure/make: default build

cmake/ninja: default, i.e. CMAKE_BUILD_TYPE=(empty), Release, Debug

ABI-Version: empty, 10306
I have the problem after configure + make, but no problem after CMake + make.
Very strange.


To "simplify" my tests I ran the build process, opened a Finder window
from the build directory with

open bin/test

and then clicked on the apps in question. Is that (similar to) what you did?
I can do that and it doesn't change my observations.


Note: I previously installed the Xcode commandline tools and this time
they worked fine after the upgrade (I didn't need to reinstall).
However, I did not yet update Xcode for all these tests above.

I'm now upgrading to Xcode 12.5 (~80% done). I'll try again after the
upgrade just in case this changes anything. Which Xcode version do you
have installed on your 11.3 M1 mac?
I have for now only the commandline tools. No Xcode yet.

Albrecht Schlosser

unread,
May 1, 2021, 11:35:45 AM5/1/21
to fltkc...@googlegroups.com
On 5/1/21 4:57 PM Manolo wrote:

> I have the problem after configure + make, but no problem after CMake +
> make.
> Very strange.

The bundles are created differently, the .plist files may be different.
I know that I had to "extend" the CMake-generated .plist by "copying"
some parts of the template files used by `fltk-config --post' - but I'm
not aware that the files generated by 'make' have any deficiencies.

I just rebuilt with

make distclean
make -j7

No problems.

FTR: Xcode 12.5 is meanwhile installed but I didn't use it.

Manolo

unread,
May 2, 2021, 12:54:58 AM5/2/21
to fltk.coredev
Le samedi 1 mai 2021 à 17:35:45 UTC+2, Albrecht Schlosser a écrit :
On 5/1/21 4:57 PM Manolo wrote:

> I have the problem after configure + make, but no problem after CMake +
> make.
> Very strange.

The error occurs after I downloaded the FLTK source tar archive with Firefox, unfold the archive
and build FLTK. The error symptom is a popup window saying
"Blocks is damaged and can't be opened.
Firefox downloaded this file on …"

If I git clone, git checkout branch-1.3 and build with configure : NO ERROR!

If I copy the blocks.app dir from my CMake-based build, empty it completely,
and then fill it with the content of blocks.app from my firefox+configure build : NO ERROR
Thus, the difference in Info.plist between CMake and configure builds is not the culprit.

Thus , the status "I'm suspect, I was downloaded from internet" seems transferred
from the tar archive all the way to the blocks.app directory and to block launching these 3 apps.

Albrecht, can you see that too?

Manolo

unread,
May 2, 2021, 1:09:36 AM5/2/21
to fltk.coredev
Same errors if I download with Safari instead of Firefox.

Albrecht Schlosser

unread,
May 2, 2021, 5:15:54 AM5/2/21
to fltkc...@googlegroups.com
On 5/2/21 6:54 AM Manolo wrote:
>
> Le samedi 1 mai 2021 à 17:35:45 UTC+2, Albrecht Schlosser a écrit :
>
> On 5/1/21 4:57 PM Manolo wrote:
>
> > I have the problem after configure + make, but no problem after
> CMake +
> > make.
> > Very strange.
>
>
> The error occurs after I downloaded the FLTK source tar archive with
> Firefox, unfold the archive
> and build FLTK. The error symptom is a popup window saying
> "Blocks is damaged and can't be opened.
> Firefox downloaded this file on …"
>
> If I git clone, git checkout branch-1.3 and build with configure : NO ERROR!

Yes, I see this too.

> If I copy the blocks.app dir from my CMake-based build, _empty it
> completely_,
> and then fill it with the content of blocks.app from my
> firefox+configure build : NO ERROR
> Thus, the difference in Info.plist between CMake and configure builds is
> not the culprit.

I made a similar test: in the <firefox-download> folder I removed
test/blocks.app/Contents/MacOS and Info.plist, then replaced Info.plist
with the Git version and built again (after also removing the blocks
wrapper script). After these steps I could open blocks.app with the Finder.

> Thus , the status "I'm suspect, I was downloaded from internet" seems
> transferred
> from the tar archive all the way to the blocks.app directory and to
> block launching these 3 apps.

In their help info in the message popping up they say it has to do with
security and that you should control-click the app and click open to run
it. But that doesn't work for me, it just doesn't change anything. See
attached open_app_help.txt.

Another observation: when I type in the FLTK root dir:

open test/checkers.app

I get a weird error message (attached).

I can still run the executable if I use the wrapper script, like on the
commandline:

test/checkers

Really CRAZY!

FTR: I tried to edit Info.plist before building so it gets (maybe)
another status, time stamp, whatever, but this didn't help either.

Solution/workaround: drop configure/make build, use CMake instead! ;-)

You know much more about macOS, do you have any other ideas how to solve
this?

Mike (Sweet), if you are reading this, do you have any more info/ideas
how to work around this "security" issue?
open_checkers.txt
open_app_help.txt

Albrecht Schlosser

unread,
May 2, 2021, 5:56:32 AM5/2/21
to fltkc...@googlegroups.com
To circumvent this "security problem" I moved blocks.app aside and
created it again manually. I used an editor (code => VS Code) to edit
the files to avoid duplicating any "downloaded from internet"
attributes, wherever they may be hidden.

See attached file modify_blocks_app.txt for what I did. This worked as
intended, now blocks.app can be opened with the finder and with 'open
test/blocks.app'.

Finally I recreated the entire directory structure of checkers.app and
just /copied/ everything from the saved structure, see attached
modify_checkers.txt, and this worked as well. This is more or less what
you described but I tried it so we can maybe use it in an automated way
to get rid of the problem.

That's real SECURITY! Move unsecure files away, copy the contents back,
and then it's secure. ;-)
Apple???
modify_blocks_app.txt
modify_checkers.txt

Manolo

unread,
May 2, 2021, 6:27:40 AM5/2/21
to fltk.coredev
Thanks Albrecht for taking the time to reproduce in your hands. I was beginning
to envisage my M1 had some defect in its security processor.

All that crazy stuff goes into the direction of preventing macOS users from using non-Apple software.
Very sad.

But there's a command to remove that
     xattr -d -r com.apple.quarantine   /path/to/app

I found it there:
and it works.

I'll see if I can add that to the test/ makefile.

Albrecht Schlosser

unread,
May 2, 2021, 7:36:21 AM5/2/21
to fltkc...@googlegroups.com
Thanks for that, that's awesome. Howeve it doesn't resolve the
underlying issue, it's more like "healing the symptoms".

If you can get it working, can you please post a patch here before you
commit it so I can test and we can decide this shortly? If my long-term
solution (see below) doesn't work out quick enough we can use yours as a
quick fix in 1.3.6.

BTW: fluid is also concerned.


My long term solution ("plan B") would be to create the app folders for
all apps "from scratch", just as we do with all the other apps and then
copy the extry files (icon and others) into the app folder in a second step.

I'm working on this solution and I'll let you know how this works out.
This should avoid the issue in the first place and IMHO have another
benefit: I moved the "extra files" to a separate folder "resources" and
intend to copy the files from there into the .app folder. The benefit is
that this extra folder removes some special handling of '.app' folders
in 'git' and 'make clean': since we won't have *any* .app folders in our
sources we can have '*.app' in .gitignore and 'rm -rf *.app' in `make
clean'.

Here's a potential layout (work in progress):

fltk-1.3.6rc1/test$ tree resources/
resources/
├── blocks
│   ├── Info.plist
│   ├── PkgInfo
│   └── blocks.icns
├── checkers
│   ├── Info.plist
│   ├── PkgInfo
│   └── checkers.icns
└── sudoku
├── Info.plist
├── PkgInfo
└── sudoku.icns

3 directories, 9 files

Albrecht Schlosser

unread,
May 2, 2021, 7:44:11 AM5/2/21
to fltkc...@googlegroups.com
On 5/2/21 1:36 PM Albrecht Schlosser wrote:
> On 5/2/21 12:27 PM Manolo wrote:
>>
>> But there's a command to remove that
>>       xattr -d -r com.apple.quarantine   /path/to/app
>>
>> I found it there:
>> https://osxdaily.com/2010/09/12/disable-application-downloaded-from-the-internet-message-in-mac-os-x/
>>
>> and it works.

FTR: this command can also be applied to the downloaded tarball.

Michael Sweet

unread,
May 2, 2021, 8:00:00 AM5/2/21
to fltkc...@googlegroups.com
Albrecht,

> On May 2, 2021, at 7:36 AM, Albrecht Schlosser <Albrech...@online.de> wrote:
> ...
> Here's a potential layout (work in progress):
>
> fltk-1.3.6rc1/test$ tree resources/
> resources/
> ├── blocks
> │ ├── Info.plist
> │ ├── PkgInfo
> │ └── blocks.icns
> ├── checkers
> │ ├── Info.plist
> │ ├── PkgInfo
> │ └── checkers.icns
> └── sudoku
> ├── Info.plist
> ├── PkgInfo
> └── sudoku.icns

I'd recommend against using the name "resources" since that has some unfortunate side-effects on macOS in Xcode and some of the Foundation framework features. Instead, use "resource" or "mac-resources" or something like that so that things don't get confused about a subdirectory named "Resources" (yay case-insensitive file systems... :/)

________________________
Michael Sweet

signature.asc

Albrecht Schlosser

unread,
May 2, 2021, 10:44:45 AM5/2/21
to fltkc...@googlegroups.com
On 5/2/21 1:59 PM Michael Sweet wrote:
> Albrecht,
>
>> On May 2, 2021, at 7:36 AM, Albrecht Schlosser <...> wrote:
>> ...
>> Here's a potential layout (work in progress):
>>
>> fltk-1.3.6rc1/test$ tree resources/
>> resources/
>> ├── blocks
>> │ ├── Info.plist
>> │ ├── PkgInfo
>> │ └── blocks.icns
>> ├── checkers
>> │ ├── Info.plist
>> │ ├── PkgInfo
>> │ └── checkers.icns
>> └── sudoku
>> ├── Info.plist
>> ├── PkgInfo
>> └── sudoku.icns
>
> I'd recommend against using the name "resources" since that has some unfortunate side-effects on macOS in Xcode and some of the Foundation framework features. Instead, use "resource" or "mac-resources" or something like that so that things don't get confused about a subdirectory named "Resources" (yay case-insensitive file systems... :/)

Yeah, thanks, Mike. That's another trap I'd like to avoid.

I think I'll rename it to 'mac-resources'.

Another question that arose: Do we really need the PkgInfo files? AFAICT
they are only used in the bundles we generate for these three games and
fluid and they seem to be

(a) optional
(b) inconsistent

according to this article:

https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html

"""
This file is not required, but can improve performance for code that
accesses this information. Regardless of whether you provide this file,
you should always include type and creator information in your
information property list file using the CFBundlePackageType and
CFBundleSignature keys, respectively.

The contents of the PkgInfo file are the 4-byte package type followed by
the 4-byte signature of your application. Thus, for the TextEdit
application, whose type is 'APPL' and whose signature is 'ttxt', the
file would contain the ASCII string “APPLttxt”.
"""

@a: None of the CMake-generated bundles has a PkgInfo file.

@b: For instance in fluid we have in Info.plist:

<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleSignature</key>
<string>FLID</string>

and the PkgInfo file has:

FLIDFlid

It's only 8 chars + <lf>, but according to the docs and Info.plist this
should read:

APPLFLID

There are other PkgInfo files with similar inconsistencies.

I alwas saw the second four bytes Upper/Lowercased like 'Flid' (only
first letter uppercase) but that's another question which is moot if we
drop the PkgInfo files as I propose below.

None of the CMake-generated bundles has a PkgInfo file.

If we don't really need PkgInfo files and if there's no /significant/
performance boost if we have them, then I suggest to *drop all PkgInfo
files* for unification and simplification.

Given the structure above we'd only need Info.plist and the .icns file
(icon) per application (including fluid, of course).

Thoughts and insights? Manolo, Mike, anybody else?

Michael Sweet

unread,
May 2, 2021, 2:45:03 PM5/2/21
to fltkc...@googlegroups.com
Albrecht,

> On May 2, 2021, at 10:44 AM, Albrecht Schlosser <Albrech...@online.de> wrote:
> ...
> Another question that arose: Do we really need the PkgInfo files? AFAICT they are only used in the bundles we generate for these three games and fluid and they seem to be
>
> (a) optional
> (b) inconsistent
>
> according to this article:
>
> https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html

Drop them, they are no longer necessary.

> Given the structure above we'd only need Info.plist and the .icns file (icon) per application (including fluid, of course).
>
> Thoughts and insights? Manolo, Mike, anybody else?

I'd just name the files "program.icns" for the icon and "program.plist" for the Info.plist. Then you can flatten the directory...

________________________
Michael Sweet



signature.asc

Albrecht Schlosser

unread,
May 2, 2021, 3:17:05 PM5/2/21
to fltkc...@googlegroups.com
On 5/2/21 8:44 PM Michael Sweet wrote:
> Albrecht,
>
>> On May 2, 2021, at 10:44 AM, Albrecht Schlosser <Albrech...@online.de> wrote:
>> ...
>> Another question that arose: Do we really need the PkgInfo files? AFAICT they are only used in the bundles we generate for these three games and fluid and they seem to be
>>
>> (a) optional
>> (b) inconsistent
>>
>> according to this article:
>>
>> https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html
>
> Drop them, they are no longer necessary.

OK, thanks.

>> Given the structure above we'd only need Info.plist and the .icns file (icon) per application (including fluid, of course).
>>
>> Thoughts and insights? Manolo, Mike, anybody else?
>
> I'd just name the files "program.icns" for the icon and "program.plist" for the Info.plist. Then you can flatten the directory...

I'll consider this. Thanks again.

Manolo

unread,
May 3, 2021, 2:03:08 AM5/3/21
to fltk.coredev
On Sunday, May 2, 2021 at 1:36:21 PM UTC+2 Albrecht Schlosser wrote:
If you can get it working, can you please post a patch here before you
commit it so I can test and we can decide this shortly?

Here's the patch :
quarantine.patch.txt

Albrecht Schlosser

unread,
May 3, 2021, 10:25:50 AM5/3/21
to fltkc...@googlegroups.com
Thanks for the patch, I tried it and it worked for me.

However, meanwhile I refactored macOS bundle generation completely
(removed all *.app dir's) and dropped the PkgInfo files as discussed.

fluid has its own storage concept, all other demos in test/ have their
resources stored in folder 'test/mac-resources', including
test/editor.plist.

Please test this commit on your local macOS system and report if there's
anything not working. I tested thoroughly all app generation and 'make
clean', 'make distclean' etc.

The next step - after hopefully positive feedback - would be to upload
this as 1.3.6rc2 which can be tested after download to see if there are
no other issues.

Thanks to all who tested and those who will test this commit too.


$ git shortlog release-1.3.6rc1..
Albrecht Schlosser (6):
Rename file 'VERSION' to 'fltk_version.dat' (#191)
Fix version number in doxygen docs
Fix build with Cairo for CMake < 3.13
CMake: fix old (pre 3.13) link_directories() usage
Enhance CMake build configuration summary
Refactor macOS bundle generation to avoid "quarantine"


commit 15aff3718e7102371cf1b301a03d65cef73c941e
Author: Albrecht Schlosser <...>
Date: Mon May 3 14:19:50 2021 +0200

Refactor macOS bundle generation to avoid "quarantine"

macOS Big Sur 11.3 introduced a new "security feature" such that
app bundles created from existing bundle templates in downloaded
files (tar distibutions, expanded) could no longer be executed
without unsetting the "quarantine" attribute. This commit fixes
this by creating all bundles from scratch.

Known *workaround* for older tarballs and snapshots:

$ xattr -d -r com.apple.quarantine xxx.app

Albrecht Schlosser

unread,
May 3, 2021, 4:42:21 PM5/3/21
to fltkc...@googlegroups.com
On 5/3/21 4:25 PM Albrecht Schlosser wrote:
>
> [...] meanwhile I refactored macOS bundle generation completely
> (removed all *.app dir's) and dropped the PkgInfo files as discussed.
>
> fluid has its own storage concept, all other demos in test/ have their
> resources stored in folder 'test/mac-resources', including
> test/editor.plist.
>
> Please test this commit on your local macOS system and report if there's
> anything not working. I tested thoroughly all app generation and 'make
> clean', 'make distclean' etc.
>
> The next step - after hopefully positive feedback - would be to upload
> this as 1.3.6rc2 which can be tested after download to see if there are
> no other issues.

OK, after another small patch I uploaded a *temporary* release tarball
for developer testing. This is NOT the
next official release candidate and can't be "found" on the website.

Please download one of the following files on your Mac (Big Sur, 11.3
preferred) and try if all builds well and if the app bundles,
particularly fluid, blocks, checkers, and sudoku (which all have a
special icon) can be clicked and executed from the Finder and/or with
'open xxx.app'.

https://www.fltk.org/pub/fltk/1.3.6rc2/fltk-1.3.6rc2-source.tar.bz2

https://www.fltk.org/pub/fltk/1.3.6rc2/fltk-1.3.6rc2-source.tar.bz2

Note that the download via webbrowser is (was) the necessary step before
expanding the tarballs to trigger the macOS security problem. This
should be gone with the new tarballs.

AFAICT we've only seen the issue on macOS Big Sur 11.3 (very recent
upgrade) but feedback regarding all other macOS versions would also be
appreciated.

Albrecht Schlosser

unread,
May 3, 2021, 4:44:07 PM5/3/21
to fltkc...@googlegroups.com
On 5/3/21 10:42 PM Albrecht Schlosser wrote:

Correction: the second URL should read '... .gz':

> https://www.fltk.org/pub/fltk/1.3.6rc2/fltk-1.3.6rc2-source.tar.bz2
>
> https://www.fltk.org/pub/fltk/1.3.6rc2/fltk-1.3.6rc2-source.tar.gz

Michael Sweet

unread,
May 3, 2021, 7:09:57 PM5/3/21
to fltkc...@googlegroups.com
Worked on my M1 and Intel Macs running Big Sur (using configure script...)
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/55e8d288-c9d9-b290-25c9-10e04bb5079e%40online.de.

________________________
Michael Sweet



signature.asc

Manolo

unread,
May 4, 2021, 4:33:01 AM5/4/21
to fltk.coredev
It's OK for me on macOS 11.3 with fltk-1.3.6rc2-source.tar.gz both for configure+make
and CMake+make

I see, though, that test/subwindow doesn't respond to cmd-Q and will look whether it's expected.

Manolo

unread,
May 4, 2021, 8:06:32 AM5/4/21
to fltk.coredev
That is expected from the source code, so OK for rc2.

Albrecht Schlosser

unread,
May 4, 2021, 8:21:26 AM5/4/21
to fltkc...@googlegroups.com
On 5/4/21 2:06 PM Manolo wrote:
>
> Le mardi 4 mai 2021 à 10:33:01 UTC+2, Manolo a écrit :
>
> It's OK for me on macOS 11.3 with fltk-1.3.6rc2-source.tar.
> <https://www.fltk.org/pub/fltk/1.3.6rc2/fltk-1.3.6rc2-source.tar.bz2>gz
> both for configure+make
> and CMake+make
>
> I see, though, that test/subwindow doesn't respond to cmd-Q and will
> look whether it's expected.
>
> That is expected from the source code, so OK for rc2.

Thanks to you and Mike for testing again.

I'm planning to release 1.3.6rc2 later today ...

Albrecht Schlosser

unread,
May 4, 2021, 3:08:25 PM5/4/21
to fltk.coredev
CHANGES IN FLTK 1.3.6rc2 RELEASED: May 04 2021

FLTK 1.3.6rc2 fixes some minor issues in 1.3.6rc1, particularly macOS
bundle generation. It addresses an issue that bundles can't be executed
on macOS 11.3 Big Sur if built with configure/make after downloading
the release tarball because of the macOS "quarantine" feature.

Details:

Albrecht Schlosser:
Rename file 'VERSION' to 'fltk_version.dat' (#191)
Fix version number in doxygen docs
Fix build with Cairo for CMake < 3.13
CMake: fix old (pre 3.13) link_directories() usage
Enhance CMake build configuration summary
Refactor macOS bundle generation to avoid "quarantine"
Fix a new compiler warning



CHANGES IN FLTK 1.3.6rc1 RELEASED: Apr 26 2021

FLTK 1.3.6 is a maintenance release with new macOS Big Sur support
and some bug fixes. macOS Big Sur is supported on both Intel and the
new Apple Silicon (M1) chips.

CMake support has been improved but is not yet "perfect". Documentation
has been enhanced, bundled image libraries have been updated to current
versions.

The following lists are subsets of all commits. References in '(...)'
are either STR numbers (STR xxxx) or GitHub Issues or Pull Requests
(#nnn).


Bug fixes and other improvements

Albrecht Schlosser:
Fix Fl::add_timeout() in draw() under Linux (STR 3188)
X11: Fix X Input Methods (XIM) (STR 3502, 3192)
Fix overly restrictive JPEG filter (#81)
Fix DND in read-only Fl_Input (Fl_Output) (#113)
Fix offscreen drawing under X11 (STR 3384)
Fix potential fluid crashes (STR 3420) + memory leak
Fix X11 copy-paste and drag-and-drop target selection (#182)
Fix CMake install procedure (#212)
Avoid "Bogus FL_MOVE/FL_DRAG events" (#76)
CMake: Document FLTKConfig.cmake and set FLTK_INCLUDE_DIR

Greg Ercolano:
Fix issue92, added -d debug flag to fluid (#92)
Merge pull request #176 from ComputerNerd/errmsg-fix-13

ManoloFLTK:
X11: add support for copy+paste of image within one app
Windows: add bitmap version of graphics when copying to clipboard
Fix use of Xrender extension with old, 16-bit framebuffers.
Fix for Fl_Native_File_Chooser under macOS 10.15 Catalina and ...
Restore macOS capacity to turn window fullscreen encompassing
several screens.
Improve Fl_Copy_Surface under macOS
Set OPTION_USE_SYSTEM_LIBPNG/JPEG off under macOS by default
Have Fl_Pack::draw() call Fl_Group::init_sizes() on its parent group.
CMake support of the Darwin+XQuartz test platform
Add support of macOS "Big Sur" 11.0
Fix when building with SDK 10.15 and running with 11.0 Big Sur
Backport fix for issue #185 "Shared Image reload() loses initial
dimensions" from branch 1.4
Fix fl_endpoints() for macOS platform that was not effective.
Fix stack corruption when loading GIF (pull request #200)
Restore ./configure --enable-x11 on macOS
Fix crash when terminating any macOS app by cmd-Q

OKAMURA, Yasunobu:
Fix JIS Keyboard dead keys
Reply all
Reply to author
Forward
0 new messages