> > w->y(int(main_screen_height - (crect.origin.y + w->h()))); > > The last statement above reflects the fact that cocoa uses coordinates > > that go upward from the main screen bottom whereas FLTK uses > > coordinates that go downward from the main screen top. > > Thanks, the comments help a lot. So one thing that strikes me as > suspicious is that you are converting coordinates by subtracting > main_screen_height. But if the window is on a different screen won't > that be incorrect? It seems like any reference in fltk to a "main > screen" is likely to be misguided, since as far as I can tell main > screen just determines where the menu bar is, and that's not fltk's > responsibility.
The value of main_screen_height is updated at each screen configuration change in applicationDidChangeScreenParameters. Thus, it's always set to the height of the menubar-containing screen. This value is used only for coordinates calculation. These coordinates encompass all screens, so are valid whatever the screen the window is on. > > > Did you try and add a position() call in your make() function > > after the show() statement ? What happens ? > > The positions are correct, but only while the other monitor is plugged > in. When it's removed, they're all bunched up on the right, whereas > if I had listened to the window manager they would still be bunched > but at least fully on the screen. This is unexpected because Fl_X::fake_X_wm() makes sure that the window is fully visible on the screen it's sent to. > If I add back my original workaround at the start of the thread, all > the positioning as "correct" (in the right place with the external > monitor, and placed according to the WM when it's not plugged in). The change was to fix requests for creations of window on secondary screens, because the previous code allowed only for creation on the main screen. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
