Please vote about addition of class Fl_Native_Input to FLTK 1.5

[Manolo]

Fellow FLTK developers: please vote about addition of class Fl_Native_Input to FLTK 1.5.

New class Fl_Native_Input, located below Fl_Group in the widget tree, gives FLTK support
of right-to-left text input and edition. Its derived class Fl_Native_Multiline_Input handles
multiple-line text with scrollers and optional word wrapping of long lines.
Without these classes, FLTK draws correctly right-to-left text but is terribly
buggy when attempting to input, edit or select such text.

FLTK client programs can be adapted very easily to use the new class because its API is
the same as that of Fl_Input and Fl_Input_.

The idea is to arrange for FLTK to use an input widget each platform has in place
natively that is able to handle all scripts, right-to-left included. This way, FLTK
doesn't need to re-implement the tasks of text edition and line wrapping control that
become very complex to support all scripts. FLTK just inherits such features from the
platform software.

The proposed code supports all current FLTK platforms with the restriction under X11-only
that the FLTK_GRAPHICS_CAIRO build option need be ON. Noticeably, today's default FLTK
library under Linux/Unix which is the Wayland/X11 hybrid library fully supports the new widgets.
A fallback implementation of Fl_Native_Input is available for extant or future platforms
without native text input widget.

The new widget is available in branch "text_widget" of my FLTK fork
  https://github.com/ManoloFLTK/fltk
The new code includes an example of use of Fl_Native_Input and Fl_Native_Multiline_Input
available with CMake option FLTK_BUILD_EXAMPLES=1 and typing
  make native-input

@MoAlyousef tested the new widget and reported it handles Arabic text input OK.

New CMake option FLTK_OPTION_NATIVE_INPUT controls inclusion of both new widgets in
the FLTK library. It's ON by default.

The modified branch contains only additions to FLTK master except a 2-line change
of src/Fl_cocoa.mm necessary to handle a situation that could not occur previously
with the FLTK API. Therefore, the new code cannot break any extant FLTK client program.

More implementation details are available at https://github.com/fltk/fltk/discussions/1174

My vote is +1

Manolo

[imacarthur]

On Monday, 5 May 2025 at 09:08:44 UTC+1 Manolo wrote:

Fellow FLTK developers: please vote about addition of class Fl_Native_Input to FLTK 1.5.

With the caveat that I haven't actually looked at Manolo's implementation of this yet, I'm inclined to vote +1 for this, since this is a capability I have thought about sporadically for many years, but never had the motivation/skills to make work...

I note from Manolo's post that Mo has had a look and it worked for RtoL text - do we have anyone who is familiar with the input methods for, e.g., CJK text systems?

Be interesting to see how this new widget type interacts with the various IM systems too, I think.

 

[Manolo]

Le mardi 6 mai 2025 à 10:32:05 UTC+2, imacarthur a écrit :

……

I note from Manolo's post that Mo has had a look and it worked for RtoL text - do we have anyone who is familiar with the input methods for, e.g., CJK text systems?

Be interesting to see how this new widget type interacts with the various IM systems too, I think.

The new code  uses native platform's text widgets; these widgets rather than libfltk itself handle all interactions with Input Methods (IM). 

Therefore FLTK with the proposed new classes is as good as the platform's OS in IM support.

There's a small caveat: libfltk for the X11/Wayland platform needs to inform the IM of the location of the insertion

cursor so the IM positions adequately their auxiliary windows. The unchanged fl_set_spot() function allows that.

I've verified with a Chinese language IM that its auxiliary window does appear next to the insertion cursor, as expected.

[melcher....@googlemail.com]

imacarthur schrieb am Dienstag, 6. Mai 2025 um 10:32:05 UTC+2:

On Monday, 5 May 2025 at 09:08:44 UTC+1 Manolo wrote:

Fellow FLTK developers: please vote about addition of class Fl_Native_Input to FLTK 1.5.

This is difficult for me to judge. The diff ist quite huge, and I can't judge is the functionality is there. You probably tested it thoroughly and it works,

If in any way possible the widgets should have been derived from Fl_Input/Fl_Multiline_Input. That would make Fl_Backup_Native_Input obsolete and make it easier to integrate Fl_Native_Input into existing projects.

Your code seem to be 99% an addition to core code, and not change existing driver code. Wouldn't;t it be better to add this as an external widget? My reason here is, evenry configuration option adds (doubles!) the number of test cases we have to make before a release. It also puts maintenance load on all the developers. If any of the native code doesn't compile anymore because Apple changed a macOS API, FLTK can no longer be compiled. If an external widget fails, FLTK is still usable. - In different words, if a user explicitly links Fl_Native_Input, he knows what he is doing, and can react. If he just sets some option in CMake, he will not know what's going on behind the scenes.

I am unsure about this, so without more information, it's a "0".

Please note my Mail here about Core Add-Ons, as that may be a way to integrate your feature gradually as well.

[Manolo]

Le mardi 6 mai 2025 à 11:25:56 UTC+2, melcher....@googlemail.com a écrit :

……

If in any way possible the widgets should have been derived from Fl_Input/Fl_Multiline_Input. That would make Fl_Backup_Native_Input obsolete and make it easier to integrate Fl_Native_Input into existing projects.

Yes, I would have preferred to derive Fl_Native_Input from Fl_Input. Unfortunately, I didn't find that possible because the new widgets

can include horizontal or vertical scollers, and for the X11/Wayland platform these are separate (classic FLTK) widgets which, together with the

core text widget, constitute a group. That's the only reason why Fl_Native_Input derives from Fl_Group.

[melcher....@googlemail.com]

I am not entirely sore, but I believe it is possible to add Scroll Bars to a regular widget by overriding draw() and handle(). But I would have to test if it is entirely possible, and what else needs to be done. 

It's good time though to add and API to allow composite widgets without the need to use groups.

[Manolo]

Le mardi 6 mai 2025 à 11:57:07 UTC+2, melcher....@googlemail.com a écrit :

I am not entirely sure, but I believe it is possible to add Scroll Bars to a regular widget by overriding draw() and handle(). But I would have to test if it is entirely possible, and what else needs to be done. 

Great. I'm willing to modify Fl_Native_Input if you can suggest me how to modify its draw() and handle methods.

With other platforms (macOS and Windows), a single native object contains text and scrollers.

But I failed to obtain that with the GTK3 text widget.

It's good time though to add and API to allow composite widgets without the need to use groups.

Very interesting.  Do you have ideas of what could be this API?

[Manolo]

Le mardi 6 mai 2025 à 11:25:56 UTC+2, melcher....@googlemail.com a écrit :

……

Wouldn't;t it be better to add this as an external widget? My reason here is, every configuration option adds (doubles!) the number of test cases we have to make before a release. It also puts maintenance load on all the developers. If any of the native code doesn't compile anymore because Apple changed a macOS API, FLTK can no longer be compiled. If an external widget fails, FLTK is still usable. - In different words, if a user explicitly links Fl_Native_Input, he knows what he is doing, and can react. If he just sets some option in CMake, he will not know what's going on behind the scenes.

I believe it's also important to consider the general issue of the usability of FLTK in the

international, multi-language context. Are we satisfied with FLTK being completely

unusable with R-t-L languages? Isn't removing this obstacle logical after having made

FLTK Unicode-friendly and able to draw R-t-L text thanks to Pango?

[melcher....@googlemail.com]

Manolo schrieb am Dienstag, 6. Mai 2025 um 12:32:34 UTC+2:

I believe it's also important to consider the general issue of the usability of FLTK in the

international, multi-language context. 

I very much agree. We will have to change a lot more though to achieve that, if I understood the details of RtL text. First example that comes to mind: menu items should be able to align right and allow the icon to be on the right. 

[Manolo]

Le mardi 6 mai 2025 à 11:57:07 UTC+2, melcher....@googlemail.com a écrit :

I am not entirely sure, but I believe it is possible to add Scroll Bars to a regular widget by overriding draw() and handle(). But I would have to test if it is entirely possible, and what else needs to be done.

Great suggestion. I will try to do that. I add that resize() should also need overriding.

[Albrecht Schlosser]

I did already think about adding so-called "subwidgets" to any widget type to achieve that, and I have a working proof of concept. See below.

Definition: Subwidgets are widgets that are added to another widget (class) for some internal purpose. These widgets are handled directly by the class and are not added as children to its parent (Fl_Group) class (if derived from Fl_Group at all). Subwidgets can be added to any class (for instance to classes derived from simple classes like Fl_Input).

I was working on a proof of concept in class Fl_Scroll_New [1] which handles its scrollbars as subwidgets. The main advantage in *this* case is that user code doesn't have to be aware of the extra widgets (scrollbars), and that a lot of error-prone code to move the scrollbars around could be removed.

This new widget demonstrates that event handling of subwidgets need not be done by Fl_Group. The conclusion is that *any* widget can have subwidgets that are not added to the list of children, for instance: a plain old text widget can have its own scrollbars.

There are some more widget classes in the FLTK core that could be derived from more "natural" parent classes but are now derived from Fl_Group to use their own children that would better be implemented as subwidgets.

My proof of concept can be found in my fork in branch Fl_Scroll_New [1]. This could also be used as an example to add a widget as an add-on to FLTK. Note that this proof of concept may not be complete, there may be more to do, but it works (see demo test/scroll_new.cxx).

BTW, I wonder if we need to change Fl_Scroll_New::draw() as well, but it *appears* to work w/o any changes (which I don't understand right now, but it's been a while since I wrote that POC). I would have assumed that we need to draw the subwidgets ourselves in this class, but anyway, this can be done later.

See commit log for further details. Excerpt:
```

Main changes:
  
 - replace embedded scrollbars with scrollbars allocated by new
 - do *not* add scrollbars to the base class Fl_Group
 - add event handling of scrollbars
 - remove dealing with scrollbars as "children" (of Fl_Group)
 - remove fix_scrollbar_order() which is obsolete
 - remove on_insert() and on_move() which are obsolete as well
 - add test program test/scroll_new.cxx

```

Enjoy reading and testing...

[1] https://github.com/Albrecht-S/fltk/tree/Fl_Scroll_New

[Manolo]

This has been implemented and committed to https://github.com/ManoloFLTK/fltk/commits/text_widget/

With this, class Fl_Native_Input derives from Fl_Input (no longer from Fl_Group as before).