| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
Refactoring long methods into smaller parts
that are easier to understand.
|
|
Better variable names,
More descriptive integer types.
|
|
- Apple Clang 17.0.0.
- png, z, jpeg lib integer cast warnings remain
- FLTK callback function cast warnings remain.
|
|
|
|
Reorder declarations and implementations.
Rename to current FLTK standards, reformat.
|
|
Documented every function and variable in Fl_Menu.cxx.
|
|
A menu item can be designated as a headline.
Fully integrated and used in Fluid.
|
|
* define the pen/tablet support API
* add pen event handler stub as a fallback
* add pen device test "penpal".
* Add macOS pen/stylus/tablet driver.
* Add Oxygen documentation.
|
|
If set, menu items will also call the callback when highlighting changes.
The reason is given with Fl::callback_reason(). #941
|
|
A problem was visible with the menubar test app and a 2-screen system where screens are one above the other.
When moving down the huge menu, it became positioned on the wrong screen.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|