With macOS 10.13 and 10.14 at least, recursivelySendToSubwindows:@selector(display)
is not necessary in the new procedure where the window icon is computed in
windowDidMiniaturize rather than in windowWillMiniaturize as was done before.
Test scenario:
- use 2-screen configuration, one retina, one non-retina as main screen
- put subwindow-containing window on retina
- miniaturize window
- close retina screen
- de-miniaturize window
The subwindow was wrong without this change.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@13131 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
After experimenting with a modified cairo_test program that draws both with
cairo and with regular FLTK drawing functions to the same window, it seems
necessary to control for possible changes to the graphics context made by
cairo in Fl_Cocoa_Window_Driver::make_current() rather than in
cairo_create_surface().
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@13119 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Thus, Fl_cocoa.mm is completely independent from code of libfltk_gl.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@13104 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
The problem was visible with test/mandelbrot and with layer-backed views.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@13100 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Part of the fix applies both to layer-backed and non layer-backed windows.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@13090 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
The doc recommends to draw views with the displayLayer: method when the view manages itself
completely its own bitmap:
If your delegate implements the displayLayer: method, that implementation is responsible
for creating a bitmap and assigning it to the layer’s contents property.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@13075 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
MacOS apps running under 10.14 AND linked with SDK 10.14 use a completely different way
to draw to the screen in comparison with the same app running under 10.13 or earlier:
all views are "layer-backed".
This commit makes FLTK apps running under 10.14 and linked with SDK 10.14 explicitly
use layers to draw to the screen.
FLTK apps remain downward compatible with earlier macOS versions.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@13071 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
error: non-constant-expression cannot be narrowed from type 'int' to 'CGFloat'
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@13070 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Window capture by initWithFocusedViewRect: does not work if the app is linked against 10.14 SDK
and run under 10.14. In that case, capture is performed instead by CGWindowListCreateImage().
Detection of whether the app was linked against 10.14 SDK is done by checking whether
the FLView possesses a CALayer.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@13062 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
The regression was detected by "FLTK 1.4 on macOS: Trouble compiling my Application with Makefile"
in fltk.general.
The fix is to have unbundled apps initialize under MacOS 10.13 as under earlier OS,
thus the new initialization procedure introduced for 10.13 is for bundled apps only.
Tested OK on 10.13.6 and 10.14 public beta 10.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@13050 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
The previous method int(x + 0.5) is incorrect when x < 0
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@13046 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
The new procedure essentially resizes the window, as done on the X11+EWMH and Windows platforms.
This improves in particular the possibility to turn an Fl_Gl_Window fullscreen on and off.
MacOS ≥ 10.10 is required because the procedure isn't stable (random crashes during fast switches) with 10.9.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@13045 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
