The problem was that after a drag-n-drop within a window, text selection
by shift+arrow key stopped working.
Also, improves drag-n-drop within a window by leaving insertion point
at end of dragged text.
This removes the cause of this developer's message
# FIXME: This needs to be redesigned! Forcing GTK_FOUND to 0 (NO) is a bad
# FIXME: idea because there could be unwanted side effects. AlbrechtS
"Arrows" in widgets are those GUI elements mostly represented by
triangles pointing in a particular direction as in scrollbars,
choice widgets, some menus, valuators and Fl_Counter widgets.
The code has been simplified and standardized such that all these
GUI elements are drawn identically per FLTK scheme.
Widget authors no longer need to write code to calculate arrow sizes
and draw polygons etc.
Different schemes can and do implement different drawing functions.
Todo: see comments "FIXME_ARROW" in src/Fl_Menu_Button.cxx and
src/Fl_Menu.cxx
Selecting a text range programmatically would not sync
some variables with the actual selection. This also fixes
a crash bug in macOS when dragging text that was
selected by buffer()->select() only.
While adding the docs, noticed some things that need modification
for proper public use. These are highlighted as \todo items and
\warning items, which will be fixed in a separate commit forthcoming. -erco
Calculate scroll area only according to visible children.
Note: "visible" means in this context: "not hidden" - as opposed
to being invisible because the widget doesn't have a background
and a label.
Started with @wcout's patch (see Issue #153, STR 3290), modified
patch for CMP conformance, restructured methods, and finally:
- used Fl_Int_Vector instead of 'fl_data_container'
- removed fl_data_container
Thanks for the working patch to @wcout.
Both bugs can happen if a widget doesn't have an associated window()
or in similar situations. These fixes returns NULL to prevent crashes.
Bugs observed in special test scenarios, not real-life programs.
It's not necessary to call wl_subsurface_place_above() because
"A new sub-surface is initially added as the top-most in the stack of its siblings and parent."
This is a partial fix of issue #525 that reproduces under Wayland the "unofficial",
X11-specific way to cancel a Dnd operation by calling Fl::pushed(0).
This fixes the scrollbar order when children are inserted rather than
at some indefinite time later, for instance in draw().
This commit will very likely make Fl_Scroll::fix_scrollbar_order()
obsolete but this method is kept as is for tests and verification.