oddities on os x sequoia

[Evan Laforge]

I recently upgraded to macos sequoia 15.3, and upgraded to the latest
released 1.14.1 while I was at it. It basically works, thanks to the
hard work of developers in here, but there are a few oddities. I
haven't spent much time tracking them down, first I thought I'd ask if
other macos users have noticed:

1. I get some logs on stderr on startup. Seems to be harmless, but
it's a bit noisy:
2025-02-07 18:48:00.601 logview[17665:1231533] +[IMKClient subclass]:
chose IMKClient_Modern
2025-02-07 18:48:00.601 logview[17665:1231533] +[IMKInputSession
subclass]: chose IMKInputSession_Modern

2. Windows don't seem to come to the front and get focus on startup.
Actually, after upgrading to 1.14.1 2/3 of my fltk apps do come to the
front, the 3rd one stays in the background, until I select it with
cmd-tab. That 3rd one does more overriding of handle methods and the
like, maybe it has to do with that.

3. Icons don't seem to work anymore. I've been using a make_bundle.py
script, derived from something posted here long ago (by Albrecht?),
it's basically the same as fltk-config --post will do. It gets an
icon in the finder but not in the cmd-tab process selector thing.
That makes it hard to pick when they're all featureless white boxes!

I can't tell if the test programs have icons because most of them
macos won't even start them, I guess that's the infamous signing
thing. Fortunately my own compiled program doesn't have this problem,
I'm not sure what makes the difference.

4. There's a new "-weak_framework UniformTypeIdentifiers" apparently
used by Fl_Native_File_Chooser_MAC.mm. It's not such a problem on its
own, but I'm linking through ghc which understands -framework but not
-weak_framework... it seems to be not a big deal because I can just
omit it and things seem to be fine (I don't use a file chooser). Just
curious about this new linking option.

5. MIDI bindings don't seem to work anymore. This is surely nothing
to do with fltk, just thought I'd mention in case it rings a bell with
anyone.

[Gonzalo Garramuño]

On 2/7/2025 10:46 AM, Evan Laforge wrote:
> 1. I get some logs on stderr on startup. Seems to be harmless, but
> it's a bit noisy:
> 2025-02-07 18:48:00.601 logview[17665:1231533] +[IMKClient subclass]:
> chose IMKClient_Modern
> 2025-02-07 18:48:00.601 logview[17665:1231533] +[IMKInputSession
> subclass]: chose IMKInputSession_Modern

Not sure about the rest, but this is a macOS bug, not an FLTK issue.  I
get this with emacs, for example.

--
Gonzalo Garramuño
ggar...@gmail.com

[Manolo]

2. Windows don't seem to come to the front and get focus on startup.
Actually, after upgrading to 1.14.1 2/3 of my fltk apps do come to the
front, the 3rd one stays in the background, until I select it with
cmd-tab. That 3rd one does more overriding of handle methods and the
like, maybe it has to do with that.

Then it seems there's no issue inside FLTK.

 

3. Icons don't seem to work anymore. I've been using a make_bundle.py
script, derived from something posted here long ago (by Albrecht?),
it's basically the same as fltk-config --post will do. It gets an
icon in the finder but not in the cmd-tab process selector thing.
That makes it hard to pick when they're all featureless white boxes!

What I see here is that apps given a proper icon in the bin/test folder such as blocks,

sudoku and checkers do appear with their proper icon in the cmd-tab chooser window

and in the dock.

 

I can't tell if the test programs have icons because most of them
macos won't even start them, I guess that's the infamous signing
thing. Fortunately my own compiled program doesn't have this problem,
I'm not sure what makes the difference.

FLTK macOS test apps are expected to start when double clicked in the finder. 

That's what I see here, and they're not signed.

 

4. There's a new "-weak_framework UniformTypeIdentifiers" apparently
used by Fl_Native_File_Chooser_MAC.mm. It's not such a problem on its
own, but I'm linking through ghc which understands -framework but not
-weak_framework... it seems to be not a big deal because I can just
omit it and things seem to be fine (I don't use a file chooser). Just
curious about this new linking option.

This option is the only solution to link an app that can run both with old

macOS versions before the advent of the APIs brought by a given framework,

and with more recent macOS versions where the app uses these APIs.

If -framework is used instead, the product doesn't launch on old macOS versions

and fails with missing symbol errors.

If you're not interested in compatibility with older macOS versions, then you can 

just replace -weak_framework by -framework.

[Evan Laforge]

On Sat, Feb 8, 2025 at 3:06 AM Manolo <manol...@gmail.com> wrote:
> 2. Windows don't seem to come to the front and get focus on startup.
> Actually, after upgrading to 1.14.1 2/3 of my fltk apps do come to the
> front, the 3rd one stays in the background, until I select it with
> cmd-tab. That 3rd one does more overriding of handle methods and the
> like, maybe it has to do with that.
>
> Then it seems there's no issue inside FLTK.

Something did change though, previously all came to front reliably,
and on fltk 84c09ae7b2de0ad9142551ebd4f53a7e113902b4 0/3 would come to
front, while the official 1.4.1, 2/3 do. But since I have some which
come to front and some which don't, I can try to make them more
similar to each other to find out where the difference happens.

> 3. Icons don't seem to work anymore. I've been using a make_bundle.py
> script, derived from something posted here long ago (by Albrecht?),
> it's basically the same as fltk-config --post will do. It gets an
> icon in the finder but not in the cmd-tab process selector thing.
> That makes it hard to pick when they're all featureless white boxes!
>
> What I see here is that apps given a proper icon in the bin/test folder such as blocks,
> sudoku and checkers do appear with their proper icon in the cmd-tab chooser window
> and in the dock.

Yes, those do get icons for me. When a `cp -r blocks.app ~` then the
copy has the icon, but if I recreate it by hand copying one file at a
time, no icon. Clearly something is different though, and there's
some caching going on which further muddies the waters. And
blocks.app itself is created by a simple shell script in the makefile,
it should be the same steps I do by hand. Anyway, I don't think this
is a fltk issue, just a regular MacOS one, since it shouldn't matter
what the actual executable in there is. I'll keep experimenting.
Probably a dumb mistake.

> I can't tell if the test programs have icons because most of them
> macos won't even start them, I guess that's the infamous signing
> thing. Fortunately my own compiled program doesn't have this problem,
> I'm not sure what makes the difference.
>
> FLTK macOS test apps are expected to start when double clicked in the finder.
> That's what I see here, and they're not signed.

That's not what happens on my laptop (MacBook Pro, 2024, M4). All of
them I've tried except "keyboard" offer to delete themselves when I
double click, or if I start from the shell, regardless of if I click
on the .app or the shell wrapper. I don't know what's different about
"keyboard", or even what causes this to happen. I can look into it in
a bit. As I said, my own built programs don't do this, also don't
understand why.

I have noticed that newly linked programs start slowly the first time,
I seem to recall talk about some phoning home Apple added a while
back, maybe that's related.

> This option is the only solution to link an app that can run both with old
> macOS versions before the advent of the APIs brought by a given framework,
> and with more recent macOS versions where the app uses these APIs.
> If -framework is used instead, the product doesn't launch on old macOS versions
> and fails with missing symbol errors.
>
> If you're not interested in compatibility with older macOS versions, then you can
> just replace -weak_framework by -framework.

Got it, thanks for the explanation. It turns out I can omit it
entirely and nothing bad seems to happen, as I mentioned perhaps
because I don't use a file chooser.

[Manolo]

Le vendredi 14 février 2025 à 12:43:16 UTC+1, qdu...@gmail.com a écrit :

……

> FLTK macOS test apps are expected to start when double clicked in the finder.
> That's what I see here, and they're not signed.

That's not what happens on my laptop (MacBook Pro, 2024, M4). All of
them I've tried except "keyboard" offer to delete themselves when I
double click, or if I start from the shell, regardless of if I click
on the .app or the shell wrapper. I don't know what's different about
"keyboard", or even what causes this to happen. I can look into it in
a bit. As I said, my own built programs don't do this, also don't
understand why.

I also use a MacBook Pro 2024 M4 and all FLTK apps start when double-clicked.

Do you have applications from "App Store & Known Developer" authorized

in your system settings? See attached picture.

I have noticed that newly linked programs start slowly the first time,
I seem to recall talk about some phoning home Apple added a while
back, maybe that's related.

Slow startup is also unexpected.

 

[Evan Laforge]

> > 2025-02-07 18:48:00.601 logview[17665:1231533] +[IMKClient subclass]:
> > chose IMKClient_Modern
> > 2025-02-07 18:48:00.601 logview[17665:1231533] +[IMKInputSession
> > subclass]: chose IMKInputSession_Modern
> Not sure about the rest, but this is a macOS bug, not an FLTK issue. I
> get this with emacs, for example.

Indeed you're right, I should have searched for some of those words
first! Just one of those Mac papercuts I guess.