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.
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.
The case was under macOS with a non-GL parent window mapped to a retina display
containing a GL subwindow and if the app did not call Fl::use_high_res_GL(1).
This new implementation does all screen drawing through the drawRect: method.
The benefit is that [[NSGraphicsContext currentContext] CGContext] provides
a system-built drawing context whose product ultimately appears on screen.
Feed-back from the fldigi FLTK application shows that this procedure is
measurably faster that the previous one when drawing a rapidly changing image.
Users can press ctrl-c (or ctrl-x) while using the fl_color_chooser()
function or the Fl_Color_Chooser widget to copy the current color
selection to the clipboard.
X11 requires to process differently paste if both copy and paste are within the
same app or are in 2 separate apps. This was implemented for paste of text.
It's now also implemented for paste of image.
