- remove obsolete code / comments (see Git for history)
- add copyright to generated file src/fl_cmap.h
- generate copyright year in src/fl_cmap.h automatically
- add color indices as comments to color values
- remove $Id header
- replace $Id trailer with a more useful comment
Under Windows, window resize requests sent by the program are now ignored,
which is what happens under X11 and macOS.
Previously, the window would become frozen.
Metrowerks CodeWarrior was an ancient macOS compiler (discontinued
since 2005) that defined the macro __MWERKS__. Code using this macro
and several comments have been removed.
This is a partial fix for "[fltk.general] scroll and overlay window"
dated 7 march 2020.
Mixing of Fl_Scroll and Fl_Overlay_Window is now OK also
on a retina display, but there are still problems when the window
is scaled.
Revert commit 958d912ffc using 'XSetLocaleModifiers("@im=");'
which was incorrect (STR 3192).
Apply fix for STR 3502, using 'XSetLocaleModifiers("");' which appears
to be the correct solution for using X Input Methods (XIM).
This has also been backported to FLTK 1.3.6 in branch-1.3, see
commit 219ae5e455.
The doc states:
"Top-level windows initially have visible() set to 0 and parent() set to NULL.
Subwindows initially have visible() set to 1 and parent() set to the parent window pointer."
The first statement was not satisfied when a window was constructed
with the Fl_Window(x, y, w, h, t) constructor.
According to the documentation fl_font(face, size) may be called
"outside a draw context if necessary to call fl_width()".
This worked in 1.3.5 but did not in 1.4 (so far). I reworded the
docs to make clear that other measurement functions can be called
as well and refactored the code to make sure that fl_font(face, size)
will open the display if necessary.
The X11 specific overloaded function fl_open_display(Display *)
has never been documented but exposed (and "exported" in the ABI)
in FL/platform.H which is not necessary. This internal function
is now static and no longer exposed in the ABI.
Don't confuse with fl_open_display() w/o arguments which is still
exported and declared in FL/platform.H.
... for GCC >= 4.6 and clang compilers.
This annoying warning exists on X11 (Linux/Unix/macOS) platforms
because we need to use XKeycodeToKeysym() although it is deprecated.
See STR 2913 for discussion and details.
Clarify functionality of fl_not_clipped() and fl_clip_box().
Add developer documentation for Fl_Graphics_Driver::clip_box().
Documentation only, no code changes in this commit.
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.
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.
The bug is that the app freezes for a few seconds before the yellow transient window is closed
if the close message is set from within a timer callback.
If the window to close returns NO to the canBecomeKeyWindow message, the bug does not occur.
Anyway it's good that canBecomeKeyWindow returns NO for a window with the OUTPUT flag.
This method can be called after all menu modifications to make sure
the menu() array is relocated (copied from the internal working area)
to a private place owned by the Fl_Menu_ instance.
menu_end() is now called in Fl_Menu_Button::popup() to make sure
the menu array is in private storage.
This fixes STR 3523 w/o user code changes. Calling menu_end() is
in most cases optional.
Todo: call menu_end() where useful (or necessary), e.g. in
Fl_Choice, Fl_Menu_Bar, etc. ?
As discussed in fltk.general, valgrind reported errors when gl_draw()
is called and the text is converted to a texture (i.e. when testing
whether the texture already exists).
We need a length check to make sure we don't overrun text buffers.
See threads "gl_draw" and "gl_draw - [General Use]", respectively,
started on Jun 19, 2019.
Per-Monitor V2 awareness mode is supported on Windows 10 1703 or above
and has window title bars correctly scaled on HighDPI screens.
Before this commit, FLTK Windows apps were "Per-Monitor-V1 DPI Aware".
FLTK apps detect at run-time whether the V2 mode is possible.
The new argument gives the window to be captured, or NULL to indicate capture
from the current offscreen.
Calling this function becomes easier because less dependent on global variables.
Previously, each time fl_font(fnum, fsize) was called, functions
pango_font_description_free() and pango_font_description_from_string()
would be called.
Now, pango_font_description_from_string() is called only once, the first time
an Fl_Font is used.
Rename member function Fl_Surface_Device::end_current_() to end_current(),
set it protected, and make it called by the destructor of all classes
derived from Fl_Surface_Device that re-implement end_current().
This way, end_current() runs equally if Fl_Surface_Device()::pop_current()
is called before or after the drawing surface is deleted.
ManoloFLTK