See report in fltk.coredev as of today (Jan 16, 2020):
"Fl_Input in readonly mode - wrong behaviour".
Summary: Drag and drop within a read-only Fl_Input (i.e. Fl_Output)
widget would not insert the dragged text (correct) but removed
the dragged text from the widget (error). This is now fixed.
The main fixes are only to avoid static code analyzer warnings reported
in issue #5, but there are also minor bug fixes included. These bug
fixes are more of theoretical concerns though.
Close#6.
This new class is explicitly internal and undocumented. We can
rename and/or redefine or extend it as we need.
This work is based on Matt's recent update with separate internal
classes BMPReader and GIFReader which have been replaced by
Fl_Image_Reader.
Detailed information on how preference file paths are generated, and preliminary docs what happens if that fails. Documentation, on what FLTK die pre 1.4 when any of this failed. Also, a little TODO list for me that I will hopefully get to in the next days.
Text outside the 16-bit X11 coordinate space must be clipped before
calling X11 draw functions, otherwise text might appear anywhere
in the window because X11 would "truncate" the coordinates instead
of proper clipping (X11 handles only 16-bit coordinates).
Added Fl_Preferences::file_access() and various flags that make it possible to limit or completely deny file access to the preferences system, either for the core library or for the application or both.
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."
This is the main patch for Fl_Clock discussed in STR 3516. Although
the root cause under Linux (in Fl::add_timeout()) has been fixed
in a previous commit (35a3e7cc1) early timeouts may still occur,
e.g. under Windows in a Virtualbox environment.
This commit reverts bab61a93d and replaces it with the patch proposed
by Manolo and further discussed in STR 3516.
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().
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
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.
