| Age | Commit message (Collapse) | Author |
|---|
|
Fl_Menu_Item::measure did not take the gap between a possible
checkbox and the label text into consideration.
|
|
|
|
The old code would trigger a callback when hovering the
mouse of an inactive item and pressing Return.
|
|
|
|
|
|
menu (#1043)
Thanks for those nice changes.
|
|
- huge menus would scroll down when the mouse pointer hit
position 0, but for some secondary screens, the top edge is
not at y==0, so now we check for a range a the top border of
the working space of the screen showing the menu.
|
|
|
|
- sizeof(Fl_Widget) not increased
- label positions can be adjusted
- try it out in test/label app
- full support in FLUD
|
|
- May need a better method name.
- This makes the gap between the image in a label and
the label text user settable.
- Can be tested using test/label app
|
|
* find_shortcut(): fix testing of multi-label alt shortcuts
* Use static function instead of macro
|
|
menubar.
Slight behavior change of Fl_Menu_Bar relatively to 1.3: left and right arrow keys
when pressed in the first (resp. last) (sub)menu of a menubar wrap to the menu
at the other end of the bar. Also, left and right arrow keys open the previous
(resp. next) menu of the bar when pressed in a submenu.
Rationale: macOS, gnome and Windows apps equipped with a menubar do that.
|
|
menubar.
Fix some border cases.
|
|
menubar.
See "Menu navigation in FLTK is different from Ubuntu X11 navigation" in fltk.general.
Menubar wrapping is what macOS and gnome applications do.
|
|
|
|
|
|
|
|
- center (sub)menu arrow as good as possible
- adjust arrow sizes in Fl_Counter widget
- refactor "oxy" arrow drawing and centering in widgets
|
|
Also, remove this text from the doc of Fl_Menu_::down_box()
"If this is FL_NO_BOX then it acts like
FL_THIN_UP_BOX and selection_color() acts like
FL_WHITE, for back compatibility."
that was true only for the Windows platform and that required
selection_color to be replaced by white for menu items which is
not what FLTK 1.4 expects.
The new state of menu item drawings is as follows :
- all platforms draw menu items with the same symbolic colors
- selected items and menu titles are drawn with the selection color
as background color
- menu items are drawn by default with no box but can be given one
by Fl_Menu_::down_box(Fl_Boxtype)
- the text of selected items is drawn with the menu's color
unless fl_contrast() finds it does not make enough contrast with
the background (selection color) and substitutes it with a more
adapted color
- the Windows platform uses a visibly different hue for its default
selection color from what other platforms use
|
|
... in thread: "FLTK 1.4 Menu Bar Style", started on May 6, 2024
This is about the little triangle (or similar) pointing right when
a submenu exists in a menu. The arrow form differs per scheme.
|
|
Fl_Screen_Driver::screen_boundaries_known()
Fl_Window_Driver::set_popup_window() is to be used to declare a window should be
positioned relatively to a previously mapped other window. This allows a platform
to process such windows differently from other windows if needed.
Menu and tooltip windows are so declared.
A call to Fl_Window_Driver::set_popup_window() also allows to distinguish a real
menu or tooltip window from a window marked by Fl_Window::set_menu_window()
or by Fl_Window::set_tooltip_window() but that's not a real menu or tooltip.
New member function bool Fl_Screen_Driver::screen_boundaries_known() returns
true by default. A platform where the position of windows inside a screen is hidden
(e.g., Wayland) returns false. This allows FLTK to refrain from trying to make sure
a computed position is inside a screen.
|
|
|
|
|
|
|
|
Fixes also a similar crash occuring after use of set_tooltip_window().
Two bool member variables are added to class Fl_Window_Driver
to indicate true FLTK menu windows (i.e., created by Fl_Menu_Item::pulldown())
and true FLTK tooltip windows (i.e., Fl_Tooltip).
|
|
- add fl_draw_radio(...) to standardize radio button drawing
- src/Fl_Light_Button.cxx: use fl_contrast() to determine color of
radio button and check (light) button check marks, and use
new fl_draw_radio() method
- src/Fl_Menu.cxx: same as src/Fl_Light_Button.cxx and use
fl_draw_check() instead of "manually" drawing the check mark
(forgotten in an earlier update)
|
|
...independently from the menu button or menu bar boxtype
|
|
|
|
Unfortunately (sigh), the KDE Wayland compositor does not seem to support
correctly, that is, as described by the Wayland protocol, popup windows
that are taller than the display : there is no means to make it draw such popup
so that part of it is above the screen top, whereas the 3 other tested compositors
(Mutter, Weston, Sway) don't have this problem.
This commit implements a new approach to draw tall menu windows, and uses
it only with the KDE compositor : instead of asking the compositor to slide the
menu window up, the menu window remains at a fixed position and the graphics
inside the window is slided up.
This requires to add a member variable, int offset_y, to class menuwindow, that
gets used only for the Wayland platform and that contains the vertical offset by which
graphics to the menu window is moved, expressed in FLTK units. An accessor
to the address of this member variable is added to class Fl_Window_Driver.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Tall menus now work also as single popup window and show the correct selected item.
Groups of popups with a menutitle, an associated menuwindow, and possibly submenus
are constructed around the menuwindow, the menutitle being a child popup of the
menuwindow. This positions these popup groups better than before.
|
|
|
|
This method can be used to draw small circles as part of the GUI.
It is independent of the current scheme.
Very small circles are approximated by drawing several rectangles.
|
|
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()
|
|
Menu windows containing sub-menus are now processed differently.
|
|
This commit is similar to the patch given in STR 3477, oxy_v5.diff:
https://www.fltk.org/strfiles/3477/oxy_v5.diff
... with modifications, and updated to current FLTK code.
|
|
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.
|
|
|
|
"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
|
|
|
|
|
|
|
|
warning C4099: 'Fl_Menu_Item': type name first seen using 'struct'
now seen using 'class'
|
|
|
|
when no menu item is selected.
|
