how to catch most key presses in a subclass of Fl_Text_Editor (FLTK 1.3.8)

[Basile Starynkevitch]

Hello all,

A first simple question:

FLTK defines

typedef int(*Key_Func) (int key, Fl_Text_Editor *editor);

What is the meaning of the int returned by such Key_Func? I am guessing that 1 means the key press event is consumed, and 0 means it is falling thru (to some parent widget?)

For the RefPerSys project (GPLv3+ licensed, for Linux, its C++ variant) we want to catch most (and perhaps all) key presses in a subclass of Fl_Text_Editor. Indeed a lot of them would extend FLTK default editor.

We don't exactly know what user behavior we want our  Fltk_Editor_rps class (in file guifltk_rps.cc). It depends on how difficult is it to code for Fl_Text_Editor.

I don't understand how should that be done?

I could formulate my question in some other way: imagine I wanted to code a GNU emacs variant (in emacs, every keypress is handled by some interpreted Elisp function) using FLTK. So every key press would be handled by some interpreted (in ELisp) function.

How should I design such an application?

Regards.

-- Basile Starynkevitch <bas...@starynkevitch.net> (only mine opinions / les opinions sont miennes uniquement)

92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/

[Greg Ercolano]

On 3/14/22 11:03, Basile Starynkevitch wrote:

FLTK defines

typedef int(*Key_Func) (int key, Fl_Text_Editor *editor);

What is the meaning of the int returned by such Key_Func? I am guessing that 1 means the key press event is consumed, and 0 means it is falling thru (to some parent widget?)

    Yes, it appears to be the same as the handle() method's return value,
    which returns 1 if an event is 'handled', and 0 if not.

    In the case of key bindingings, it's the same thing.

    If the key isn't handled(), the event is propagated through the rest of the
    FLTK event hierarchy, and if no widgets respond to the event, the event
    is resent as an FL_SHORTCUT, so widgets (e.g. menus) that have hot keys
    programmed can handle the key.

For the RefPerSys project (GPLv3+ licensed, for Linux, its C++ variant) we want to catch most (and perhaps all) key presses in a subclass of Fl_Text_Editor. Indeed a lot of them would extend FLTK default editor.

    You could derive a custom class from Fl_Text_Editor and overload the Fl_Text_Editor's
    handle() method and get all the keyboard up/down events, and do with them as you like.

    When overloading handle(), be sure to still pass control to the base widget's handle()
    method at some point in your overloaded function, or you'll eclipse ALL events from the
    base class, such that it won't operate correctly (e.g. scrollbars won't work, focus handling
    would be screwed up, etc etc)

    So in your handle() code, only handle the events you want, and let the rest pass on down
    to the base class. And when you do handle certain events, e.g. keyboard up/down events,
    be sure to pass any keyboard up/down events you dont handle to the base class, to prevent
    eclipsing keyboard events the Fl_Text_Editor needs to handle itself (like e.g. PgUp/Dn, etc)