Fl_Pack::draw() sometimes resizes itself. This must be followed
by a call to Fl_Group::init_sizes() as indicated in that function's doc:
"If you rearrange the widgets in your group, call this method to register
the new arrangement with the Fl_Group that contains them."
See comment 14 (excerpt):
"The current implementation basically handles add_timeout() the same
way as repeat_timeout(), i.e. add_timeout() *calls* repeat_timeout().
However, repeat_timeout() intentionally *corrects* the timeout value
by the value found in the global variable 'missed_timeout_by' which
is set when the timer expires, directly before the timer callback
is called. This variable is never reset."
This commit resets the variable as necessary in Fl::add_timeout().
Fixed including binaries and text to use the same path as the source code. This is consistent with the way the file is selected in the corresponding dialog box. Since the old behavior was false, I don't think this will break any existing projects.
MacOS uses bundles instead of executables. CMake creates those bundles in various locations, depending on the generator used (Xcode or Makefiles). I tried to fix all instances where demo apps did not find the resources they needed. This probably must be done for Linux and MSWindows as well.
macOS strangely sends NSViewFrameDidChangeNotification and a drawRect: message to its content view
after having sent to the window the close message. That is apparently new in 10.15.2
Usage of Fl::readqueue() is not recommended (should be deprecated?),
hence we shouldn't use it in our demo program(s).
To do: remove Fl::readqueue() usage from fluid.
A recent commit changed the library name, supposedly unintended.
While testing I found that the debug statements generated confusing
output (both "selected GTK-3" and "selected GTK-2") when GTK-3 was
available.
Another way to support what occurs under macOS 10.15 where the bitmap graphics context
prepared by the system when drawRect: runs sometimes changes its number of bytes/row
even if the width and height are unchanged.
This is expected to perform better when the number of bytes/row alternates between
two values.
Under Catalina, the bitmap graphics context prepared by the system when drawRect: runs
sometimes changes its number of bytes/row even if the width and height are unchanged.
The code to determine whether the GTK library is available is now in Fl_X11_System_Driver::probe_for_GTK()
called both by Fl_Printer::begin_job() and Fl_Native_File_Chooser.
New Fl::option OPTION_PRINTER_USES_GTK allows to deactivate use of
the Gnome print dialog.
Minor change in Fl_Native_File_Chooser: GTK version 3 is searched before version 2,
whereas the search order was the opposite before.
Subject "Bug in 1.4 Displaying PNG under x64 Kernel x86 app." in fltk.general
contains a report by Darren Legge that presents the problem,
and a later post stating the code modification does fix the problem.
fluid/template_panel.{fl|cxx}:
.../fluid/template_panel.cxx:261:44: warning: ‘%s’ directive output
may be truncated writing up to 255 bytes into a region of size
between 0 and 1023 [-Wformat-truncation=]
Solution: increase buffer size from 1024 to 1400.
fluid/undo.cxx: fix warning [-Wformat-truncation=]
This fix also removes some static variables and simplifies the
function undo_filename(). It does no longer copy the full filename
string back to a given buffer. Now it returns a pointer to the
internal filename string.
Summary: fix compiler warning, save memory, simplify a function, and
speed up code by not copying data unnecessarily.
