For a very simple test program see STR 3222, File 2:
https://www.fltk.org/strfiles/3222/value_slider.cxx
Known issues:
- range checking of the value box size is very limited
- resizing the widget does not change the value box size
- drawing issues are possible if the value box size and the widget
size are not compatible (e.g. value box too large)
Use the new standard arrow drawing methods (whose style depends on
the active scheme) for "arrows" used in Fl_Menu and Fl_Menu_Button.
To do: maybe we need some "fine tuning" of arrow sizes in some of
the modified widgets using the new "arrow drawing" methods.
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.
If the resizable() of an Fl_Group is deleted it is automatically
removed from the group.
New: to avoid dangling resizable() pointers the resizable widget
is set to the group itself.
It turns out it's necessary to memorize 2 event serial numbers :
- serial changed at each pointer and key event;
- pointer_enter_serial changed when pointer enters a surface
because this one and not any other is needed for exact cursor changes
by wl_pointer_set_cursor() in do_set_cursor().
Some functions didn't document the handling of arguments properly,
particularly Fl::has_timeout() and Fl::remove_timeout().
This is now fixed by documenting the correct behavior that was
preserved (re-implemented) from FLTK 1.3.x in the new class Fl_Timeout.
Unfortunately there have been some inconsistencies (likely unexpected
behavior) which have been preserved and which are now documented.
The d-n-d target window is now always the top-level window even if the
mouse is over a subwindow. That's what all other platforms do.
Global var fl_dnd_target_surface memorise what's the current d-n-d target
surface and follows changes from top-window to subwindows.
Drag-n-drop under Wayland was OK in general except when the drop target is an Fl_Window
because the belowmouse object is not set in this configuration.
Processing an FL_ENTER event before the FL_DND_RELEASE event fixes that.
This issue is caused by setting `Fl_Group::current(0);` in
Fl_Window::show(), i.e. in Fl_X::make_xid(..) in an attempt to
fix a "very common user bug: forgot end()". As long as this is
done, this commit fixes the issue.
For details see GitHub issue #515.
These option combinations work:
-DOPTION_APPLE_X11
-DOPTION_APPLE_X11 -DOPTION_USE_CAIRO
But
-DOPTION_APPLE_X11 -DOPTION_USE_PANGO
is not possible because homebrew doesn't provide the pangoxft package.
Doxygen uses a <div> with center alignment for images, hence
adding HTML center alignment for image is not only superfluous
but was also inconsistent.
Also removed some more unnecessary HTML tags, updated copyright year.
The code failed with 2 or more widgets when FLTK would trigger
partial redraws of the widgets, unless the Fl_Gl_Window was FL_DAMAGE_ALL.
This commit also adds a second FLTK widget to example/OpenGL3test to
check this multiple widget situation, and fixes an error where operator ! was used
instead of ~ .
This commit fixes " "drawing an fl_pie() with dimension 1x1".
But it does not change "drawing fl_line() with begin position = end position does not show"
because the same behaviour is observed with Windows and macOS.
This commit allows to switch between FL_DOUBLE / FL_SINGLE modes
in widget-containing GL3 windows.
Demo program examples/OpenGL3test is modified to show FLTK widgets
even if the platform does not support OpenGL 3.
Under non-macOS platforms, the key is to call glUseProgram(0); after having used OpenGL 3
which allows to then use OpenGL 1 and draw FLTK widgets over the OpenGL3 scene.
Under macOS, this is impossible because macOS GL3 contexts are not compatible
with GL1. The solution implemented here is to create an additional Fl_Gl_Window
placed above and sized as the GL3-based window, to give it a non opaque,
GL1-based context, and to put the FLTK widgets in that additional window.
Function fl_read_image() obliges to keep a minimal use of global variable fl_window
also under the Wayland platform, even if its type (Window) makes little sense for
the hybrid library because it has its X11 value (given by X11/X.h) which is not
meaningful for the Wayland leg of the hybrid platform.
Virtual member function Fl_Surface_Device::as_image_surface() becomes useless.
The special use context of fl_read_image() inside the draw() function of an
Fl_Double_Window, where the function should read inside the window's double buffer
rather than the on-screen window, no longer worked.
Removal of all uses of the fl_window global variable from platform-independent
code remains necessary, because this variable is ill-defined in the Wayland/X11
library.
1) add Wayland code that prevent subwindows from leaking outside their parent.
This does not cover GL subwindows.
2) add macOS code that prevent GL subwindows from leaking outside their parent.
This fixes issue #494 for the macOS platform.
N.B.: Wayland GL subwindows are not prevented from leaking because no solution
that would not require any change in client applications was found. Code that
would cover Wayland GL subwindows but would require client applications to always
use the FL_ALPHA flag is included in this commit in commented out form.
The old code would allocate memory on FL_KEYDOWN and FL_KEYUP events
and never free the latter.
The fix is to allocate memory only on FL_KEYDOWN events which will
be free'd later as intended.
Also fix two unrelated whitespace errors.
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.
The problem is that the app sometimes stops after closing a file dialog window.
It results in fact from a bug in function draw_title_bar of libdecor-gtk.c that erroneously
calls libdecor_frame_set_max_content_size(). This bug is being proposed to be fixed
by a MR to libdecor.
But moving the libdecor_frame_set_min/max_content_size() calls after the capability changes
hides the bug, and the problem with file dialog doesn't show.
Conflicting demands arise in the implementation of class Fl_Xlib_Graphics_Driver
for drawing images with the XRender library :
1) Issue #163 leads to use a bilinear filter to draw-and-scale images.
2) This tends to blur the edges of drawn areas which is bad for tiled images
(that is because the edges get alpha values, even for an opaque source image).
This commit resolves the conflict adding a means to detect whether the library
is busy drawing a tiled image. If so, the bilinear filter is not applied, drawn areas
don't have blurred edges, resulting in a nice tiling.
With this commit, these test apps perform correctly:
- tiled_image is correct at all scaling factor values also when modified
to use a depth-3 or a depth-4 Fl_RGB_Image as tile;
- unittests - Drawing Images is correct at all scaling factor values;
- pixmap_browser scales correctly up and down JPEG and PNG images.
Modifying test/tiled_image to make it use a depth-3 image for
tiling (rather than an Fl_Pixmap) shows the filter does require
to use PictOpOver as the render op in the XRenderComposite call.
Support different margin sizes on all four edges. Default margin
and gap size is now 0 (compatible with Fl_Pack).
Doxygen: move the description from the constructor to the class
declaration which constitutes a "description".
Make some methods virtual and/or 'const'.
Clarify demo programs, make them even more "FLTK style".
