initial focus on OS X

[Evan Laforge]

After upgrading to OSX 15.7, my app would no longer come to front and
get focus when launched. After some experimentation, I discovered
this was due to calling Fl::lock() and Fl::wait() before creating any
windows. I was able to work around by putting in some extra logic to
not call Fl::wait() until after the first window has been created.

I think this is a change in OSX, not fltk. I'll include a simplified
version that demonstrates the problem. Call with no args and it
should come to front when launched as expected. Call with an arg and
it should launch, but in the background. I assume it's something
where fltk initializes with the OS somehow before creating the window,
which somehow misses the OS's "bring to front" window.

Or could it be I'm using fltk in an unexpected way? The repro is
contrived, but in the real app, the structure that the main thread is
like:

Fl::lock();
for (;;) {
Fl::wait();
actions = get_queue();
run(actions);
}

Event loop thread:

for (;;) {
action = event_logic();
put_queue(action);
Fl::awake();
}

I wound up modifying the main thread like:

Fl::lock();
wait_for_queue();
actions = get_queue();
run(actions);
for (;;) {
Fl::wait();
actions = get_queue();
run(actions);
}

This fixes it, but it's a bit more complicated and it might take
others a while to figure it out, as with me! Here's the reproduction:

#include <iostream>
#include <FL/Fl_Window.H>
#include <FL/Fl_Box.H>
#include <FL/Fl.H>

class Bug : public Fl_Window {
public:
Bug(int x, int y, int w, int h) : Fl_Window(x, y, w, h), box(0, 0, w, h)
{
box.box(FL_FLAT_BOX);
box.color(FL_WHITE);
}
Fl_Box box;
};


int main(int argc, char **argv)
{
if (argc > 1) {
std::cout << "lock\n";
Fl::lock();
Fl::wait(0.01);
}
Bug win(200, 200, 200, 200);
std::cout << "show\n";
win.show();
while (Fl::wait())
;
return 0;
}

[Manolo]

I find that controlling all details of how an app starts and gets focus under macOS becomes more and more difficult

with recent macOS versions.

I have reproduced your findings under macOS 26 and would like to discuss 2 things related to the problem.

1) the problem disappears if the Fl::wait(0.01) statement is commented out.

Would that be compatible with your program?

2) the problem also disappears if the app is launched from a terminal via command "open" as follows:

   open -a myapp

or, to launch it with an argument:

   open -a myapp --args arg1

Would that be compatible with your uses?

[Evan Laforge]

1 yes this works and is the workaround I discovered. Since I use a non blocking queue I had to add and extra lock to avoid a busy wait, but it's fine. 

2 is interesting and I guess hints something about the internal mechanism but I don't know what! 

So from my point of view we're fine and no further changes needed. But it took a while to track down so it's nice to get it documented out there. Maybe this mailing list mention is already enough! 

--
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...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fltkgeneral/3555dc19-b9ad-4069-9bb5-078da1084c5an%40googlegroups.com.