Please note that the parameter 'percent' of XBell(3).
Given the value of 100, the system defined setting
(normally specified via xset) is ignored and the
percent of 100 is used instead. When calling the
bell from fltk with FL_BEEP_DEFAULT I would expect
to get the default (system specified) percent setting.
This widget overrides FL_NO_BOX internally by FL_UP_BOX for all
practical purposes, e.g. draw(). This has been this way since
its initial release and can't be changed.
The implemented approach is to create and use the pango_layout_ object only relatively
to an unscaled cairo context. With this, the pixel width of a drawn string equals
the sum of the widths of its characters.
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.
This issue revealed that the macOS and Wayland platform processed events slightly differently
from other platforms.
Under X11 and Windows, Fl::wait() processes one event if one is present, and also all other events
present in the event queue immediately after the processing of that event.
Under macOS and Wayland, Fl::wait() processes one event if one is present and returns.
This commits makes the macOS and Wayland platforms behave as other platforms.
Fix Fl_Tiled_Image made from scaled source image.
Fix Fl_Shared_Image::update() to allow scaled source image.
Correct handling of default value (-1) of 3rd argument of 3-argument Fl_BMP_Image constructor.
This fixes some issues of the repeat timeout of Fl_Counter. It could
happen that the widget missed the FL_RELEASE event, for instance if
a modal window like fl_message() was opened in the callback but there
could be other reasons as well. See issue #450 for more info.
This commit prevents "timer loops" without intermediate event handling
if callback handling takes longer than the timer delay of repeating
timers.
For more details see GitHub issue #450.
ManoloFLTK