Horizontal mousewheel events use pseudo button numbers 6 and 7, resp.,
similar to vertical mousewheel events which use buttons 4 and 5.
The old code erroneously sent FL_RELEASE events for buttons 6 and 7
although it was prevented for buttons 4 and 5 explicitly.
Some applications insist on sending XDND protocol version 5 and
rejected (ignored) FLTK as DND receiver because we allowed only
protocol version 4. Known apps: Google Chrome and Chromium.
This commit enables XDND protocol version 5 in FLTK programs as
DND receiver.
This DnD gives two data types of the dragged text: text and a gnome-specific type.
The code previously accepted DnD with 1 data type or 4 or more data types,
and processed situations with 2 or 3 data types in a special way that fails
with gnome source apps.
The new code processes situations with 2 and 3 data types just like other ones.
This works OK when dragging from gnome wayland apps.
Thanks to Mike Qin for finding how to query the possibly changed DPI value
of an X11 display while an FLTK app keeps running without running
an external command in a pipe.
Although this was not strictly necessary I decided to implement the
proposed patch, but in a slightly different way.
This adds a static public method for internal use only but it wouldn't
do any harm if a user called it.
Pressing the shift key while using the mousewheel changes
horizontal to vertical scrolling and vice versa. This allows users
with a standard mouse with only one scroll button to use it for both
scrolling directions.
Note: other mice that have either two buttons or a scroll ball can
generate both horizontal and vertical scrolling in one action. This
commit does not affect such behavior.
This patch has been provided by Manolo in file 'scroll.patch'
(see STR 3521).
Pure platform specific files like 'src/*_win32.cxx' are excluded from
doxygen processing and don't need doxygen specific guard macros.
Document this fact prominently at the beginning of each file.
Fix exclude patterns and remove duplicates from Doxyfile.in.
The new method Fl::selection_to_clipboard(int) enables copying
selection data to the clipboard on X11 if it is set to 1.
This feature was requested by STR 3229 and the implementation was
inspired by an `xterm` feature named "Select to Clipboard" which can
be enabled by 'ctrl + middle mouse button + "Select to Clipboard"'
in an xterm window.
FL_OVERRIDE is defined as `override` for C++11 and higher
FL_OVERRIDE is defined as `override` for VisualC 2015 and newer
Don't interfere with Fl_Widget::override()
warning: ‘int xrender_supported()’ defined but not used
This happens only with certain configure options, particularly if
FLTK_USE_CAIRO is set, i.e. drawing with Cairo is enabled.
This improves reading large selections and fixes one more bug.
- Fix reading selection data size of clients that don't send the size.
These clients don't respect the ICCCM. Using a default size instead.
- Improve memory allocation by pre-allocating at least 4 MB and
extending by 4 MB to reduce the number of realloc() operations.
This may waste up to 4 MB buffer space but this is only an issue
if clients don't send an appropriate size (see above).
- Limit the initial allocation to 200 MB in case clients send higher
values. This is very unlikely and might be a bug in these clients.
Default extension as above would apply anyway.
- Add more comments and optional debug statements (commented out).
Note: reading selections (clipboard) from other clients using the
INCR protocol is implemented but the opposite (providing large
selections (clipboard) by using the INCR protocol is not.
- Fix reading the size (aka "lower bound") of selection data.
- Use Fl::fatal() to terminate the process if memory for the selection
(aka clipboard) data can't be allocated. This should rarely
happen but if it does this is at least a "clean" exit and does
not overwrite arbitrary data waiting for later errors that are
hard to debug (as the old code would have done).
Todo: find a better solution because this can be caused by
another faulty process (the "selection owner"). It would be good
if we could ignore the transfer rather than killing the process.
- Continue processing the INCR protocol if another "unexpected" event
is received. Such events can definitely happen but the current code
can't deal with this because other events might cause recursions.
Hence such events are currently ignored.
Example: pressing and holding ctrl/v would trigger another clipboard
transfer while we're still processing one.
Todo: maybe process "other" events correctly while processing the INCR
protocol. The current processing is done inside a function and would
need to call fl_handle() with potential recursions, hence this would
likely need major refactoring.
- fix window size of GL windows as reported for test/glpuzzle.cxx
- fix window not resizing on ctrl/+/- (X11 only)
Unfortunately the previous commit "optimized" a necessary X11 message
away. This is now fixed.
Fixes#392.
For details see comment in src/Fl_x.cxx: this "Hack to speed up
bg box drawing" is now disabled for several reasons. The code
is still available if the macro ENABLE_BOXCHEAT is defined.
Windows platform: Remove comments about obsolete code and one
exported declaration of the variable 'fl_background_pixel' which
is used only on the X11 platform.
X11 platform: Remove comments.
Other platforms: not affected.
