Evan Laforge
unread,Sep 5, 2026, 5:58:48 PMSep 5Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to fltkc...@googlegroups.com
Apologies if I've brought this up before, for some reason the whole
thing has a familiar feeling to me, but looking through archives I
can't find any exact match. I've been tracking down a bug where when
I use scroll (two finger on a mac, but of course the event is
FL_MOUSEWHEEL) and fltk then thinks the scrolled window has focus,
even when the OS disagrees. I'll attach an example program, it should
bring up two windows. The red should make it obvious where fltk
thinks the focus is. If you do some mousewheel scrolling in the
unfocused window, then move the cursor between windows to create some
FL_ENTER events, the red should switch over to the scrolled-in window,
and now, assuming OSX with click-to-focus, the OS and fltk now
disagree about who has focus. I tried this in 1.4.4 but also got
latest dev version from github, and they are the same.
I asked claude about this, and it fingered this bit in Fl.cxx:
```
case FL_MOUSEWHEEL:
fl_xfocus = window; // this should not happen! But maybe it does:
```
indeed, commenting it out fixes the problem. I asked about
consequences, and it thinks the code is making the assumption that
only focused windows can receive mousewheel events, which is
definitely not true on the mac! It's also talking about
fl_fix_focus() as a way to reconcile with the OS, but apparently that
is not called in mousewheel code path. But of course it would be
better to not get the state wrong in the first place, than to
reconcile! But perhaps on Windows or X11 it is true that you cannot
get a mousewheel on a non-focused window? At least the "this should
not happen" comment seems to indicate whoever wrote it wasn't thinking
about OSX, or at least thought that mousewheel only goes to focused
window.
Anyway I'm sure others can ask AI just as well as I can, so I'll stop
there :) One thing I'm suspicious of is that this seems like a pretty
obvious bug and has presumably been in there for a long time, surely
someone would have come across it before, or it's actually intended in
some way, or everyone else uses fltk in a way that naturally mitigates
the problem. I've had a lingering focus bug for maybe a decade by now
which I never tracked down, maybe this was it! I'll comment out the
line in my local install and see how it goes.
// example.cc
#include <iostream>
#include <FL/Fl_Window.H>
#include <FL/Fl_Box.H>
#include <FL/Fl.H>
static void
show_widget(Fl_Widget *w)
{
if (w == nullptr) {
std::cout << "<null>\n";
} else {
std::cout << w->label() << '\n';
}
}
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;
protected:
int handle(int evt) {
if (Fl::focus() == this) {
if (box.color() != FL_RED) {
box.color(FL_RED);
redraw();
}
} else if (box.color() != FL_WHITE) {
box.color(FL_WHITE);
redraw();
}
if (evt == FL_MOUSEWHEEL) {
std::cout << label() << ": WHEEL";
} else if (evt == FL_ENTER) {
std::cout << label() << ": ENTER";
} else if (evt == FL_LEAVE) {
std::cout << label() << ": LEAVE";
} else if (evt == FL_FOCUS) {
std::cout << label() << ": FOCUS";
} else if (evt == FL_UNFOCUS) {
std::cout << label() << ": UNFOCUS";
}
if (evt != FL_MOVE) {
std::cout << " focused: ";
show_widget(Fl::focus());
};
return Fl_Window::handle(evt);
}
};
int main()
{
Bug win1(200, 200, 200, 200);
win1.label("b1");
win1.show();
Bug win2(400, 200, 200, 200);
win2.label("b2");
win2.show();
Fl::run();
return 0;
}