It is really an accessor to protected method Fl_Window::flush().
Rename it to Fl_Window_Driver::flush_Fl_Window to reflect that.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12340 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Corresponds to STR #3320
1) HiDPI support consists in detecting the adequate scaling factor for the screen on which
FLTK maps a window, and scaling all FLTK units by this factor. FLTK tries to detect the correct
value of this factor at startup (see more details below). Environment variable
FLTK_SCALING_FACTOR can also be used to set this value.
2) Rescaling support consists in changing the scaling factor of all FLTK windows
in reply to ctrl/+/-/0/ keystrokes.
More details for the various platforms :
- X11: Support is very advanced. Some details need still to be improved.
Automatic detection of the correct starting value of the scaling factor works well
with the gnome desktop. The present code contains no support for this on
other desktops. FLTK_SCALING_FACTOR provides a workaround.
-WIN32: Support is incomplete at this point, although many test
applications have partial or complete HiDPI and scaling support.
The current value of the system's scaling factor is correctly detected
at application startup. Apps respond to changes of this value in real time.
Support needs to define the FLTK_HIDPI_SUPPORT preprocessor variable
at compile time. This way, standard builds produce a code with the
default WIN32 HiDPI support, that is, where all graphics goes to an internal
buffer that gets enlarged by the system and then mapped to the HiDPI
display. To experiment with (or develop) the new HiDPI support requires
a modified build procedure in which FLTK_HIDPI_SUPPORT is defined
at compile time. When the support will be complete, the requirement for the
definition of this preprocessor variable will be removed. The present commit
contains support for a single scaling factor. Eventually, per-screen scaling
factors should be implemented, as done for X11.
- MacOS: this commit does not give new HiDPI for this platform.
Eventually, window rescaling in reply to command/+/-/0/ is desirable.
Per-screen scaling factor makes no sense on this platform because
the OS itself takes care of the difference between the resolutions of
traditional and retina displays.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.4@12239 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
These methods are intended to be used instead of pWindow->method()
for better code readability and easier porting of methods from
Fl_Window to Fl_Window_Driver.
New methods: x(), y(), y(), h(), shown(), parent(), border(),
visible(), and visible_r().
We should add more such methods if appropriate.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3-porting@11414 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This removes a bunch of
friend class Fl_XXX_Window_Driver;
declarations from Fl_Window.H, and therefore allows
to add a new window driver without modifying the platform-independent code.
The Fl_PicoXXX_Window_Driver classes have been modified but not tested ==> test needed.
File Fl_X11_Window_Driver.cxx contained this:
// DO NOT call this if the window is not mapped!
static int can_xdbe()
{ ... }
The new code does call can_xdbe() before any window is mapped,
and does work. Since can_xdbe() asks the X server whether it supports
the Xdbe extension, I don't see why this should not work without a
mapped window. This point should be clarified by the author of
"DO NOT call this if the window is not mapped!".
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3-porting@11388 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Still unclear whether the implementation of the flush() functions follows the plan.
The Fl_Printer class is fully rewritten under the driver model.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3-porting@11364 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Don't get your hopes up just yet: this code does compile, but it doesn't fully link yet. If you like to test this, install the Android SDK and NDK, set the usual environment variables, then change into the "Android" direktory and run "mk". It will currently fail at the linker stage.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3-porting@11343 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
It seems this allows not to #include <windows.h> in the public header files.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3-porting@11342 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This was needed because Fl_X only exists if a window is mapped, but we need the driver from the very beginning. Adding Fl_X in the ctor would create hidden bugs. Strategy is now to remove system specific stuff from Fl_X and move it one-by-one to Fl_Window_Driver while maintaining a working code base. X11 and WIN32 fixups will follow in 15 minutes.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3-porting@11308 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Some refactoring of a take_focus() function into driver structures (not too happy with it, because it has some kind of bug fix. However, shouldn't *all* Fl_Windows always have an FL_Window_Driver?)
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3-porting@11196 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
