Mutter implements too strictly this rule expected from compositors about "frame callbacks" :
"A server should avoid signaling the frame callbacks if the surface is not visible in any way,
e.g. the surface is off-screen, or completely obscured by other opaque surfaces."
When a window is being interactively resized, it makes no sense to create a frame callback
for an entirely covered surface but then never signal the surface can be redrawn,
because this blocks the resize operation.
Neither KWin nor Weston have this problem.
This addresses some issues pointed out by GitHub Issue #875.
Documentation lacked details about Fl_Multi_Label assignment and
correct memory handling.
The new methods
- Fl_Menu_Item::image_label(const Fl_Image *) and
- Fl_Menu_Item::multi_label(const Fl_Multi_Label *)
provide a cleaner interface to assign images and Fl_Multi_Label's
to menu items.
examples/howto-menu-with-images.cxx: carify some issues, fix leak,
and use new Fl_Menu_Item::multi_label(const Fl_Multi_Label *).
This issue was revealed during testing for GitHub Issue #875.
"ERROR: AddressSanitizer: attempting free on address which was not
malloc()-ed", reported by examples/howto-menu-with-images.cxx if
the window object was released at the end of the program, causing
Fl_Menu_::clear() to be called.
The issue was caused by casting all supported label types to
'const char *' which are stored in Fl_Menu_Item::text and then trying
to free() all text strings in Fl_Menu_::clear() under certain
conditions.
Now images and Fl_Multi_Label's are no longer (tried to be) free'd.
... with cmake_minimum_required(VERSION 3.4) or higher. This version
sets CMP0065 to 'NEW' which by default inhibits exporting global
symbols from executable programs.
For details see CMake policy CMP0065 and README.Wayland.txt.
This library is no longer needed in FLTK itself. There is only one
demo program (test/forms.cxx) that uses it if it is built. The demo
program displays a message if fltk_forms is not available.
The default is 'enabled' for backwards compatibility but this may
be changed to 'disabled' in a future version.
- the current UI for fallback/default/original shortcut was
confusing, so I remove it until we find something better. I
kept the values so we can reinstate a better interface without
changing the API.
