RFC: better control over '@', '&', and '^' expansions in fl_draw()

[Greg Ercolano]

[this was on fltk.general -- moving this here to fltk.coredev for discussion]

On 11/6/22 09:17, Greg Ercolano wrote:

[regarding '&' affecting text drawing]

    Pretty sure that example only affects @ symbols.

    If you add an example item "&File", it gets draw[n] as "File".

    [..]

    Perhaps we need to provide such a control for those higher level
    functions, perhaps similar to what we have for symbols

    There appears to be several 'special handling' operations done
    by the high level fl_draw(s,x,y,w,h,align,callthis,img,draw_symbols)
    function, which calls the internal function expand_text_().

    Together those functions appear to support these transformations:

        > '@' symbols (arrows and such)
        > '&' symbols (underlined first character for menus)
        > '^' ctrl character drawing (e.g. 0x03 -> ^C)

    Perhaps a new fl_draw() method could be provided to allow bitflags
    (in place of the existing 'draw_symbols' boolean) that would offer
    more fine-grained control over each, e.g.

enum Fl_Draw_Flags {
    FL_DRAW_SYMBOLS    = 0x01,   // @
    FL_DRAW_SHORTCUTS  = 0x02,   // &
    FL_DRAW_CTRLCHARS  = 0x04    // ^
};

fl_draw(s,x,y,w,h,align,callthis,img,draw_symbols)  // old
fl_draw_ex(s,x,y,w,h,align,callthis,img,draw_flags) // new

    Naming could be better, but that'd be the gist.

    The "old" would be kept for old programs to work, but deprecated
    in favor of the 'new'.

[Albrecht Schlosser]

On 11/6/22 19:07 Greg Ercolano wrote:

    There appears to be several 'special handling' operations done
    by the high level fl_draw(s,x,y,w,h,align,callthis,img,draw_symbols)
    function, which calls the internal function expand_text_().

    Together those functions appear to support these transformations:

        > '@' symbols (arrows and such)
        > '&' symbols (underlined first character for menus)
        > '^' ctrl character drawing (e.g. 0x03 -> ^C)

    Perhaps a new fl_draw() method could be provided to allow bitflags
    (in place of the existing 'draw_symbols' boolean) that would offer
    more fine-grained control over each, e.g.

enum Fl_Draw_Flags {
    FL_DRAW_SYMBOLS    = 0x01,   // @
    FL_DRAW_SHORTCUTS  = 0x02,   // &
    FL_DRAW_CTRLCHARS  = 0x04    // ^
};

fl_draw(s,x,y,w,h,align,callthis,img,draw_symbols)  // old
fl_draw_ex(s,x,y,w,h,align,callthis,img,draw_flags) // new

    Naming could be better, but that'd be the gist.

Good points. I agree that such a function would be helpful in certain situations. It's obvious that a mail address containing '@' should be drawn literally w/o symbol expansion.

However, this doesn't solve the general question how to deal with strings that have embedded special characters and shall be assigned as labels or menu items *without* their special meaning. Once the string is assigned the fl_draw() method that is used to draw the string/label/menu_item is out of control of the user. I have no idea how to solve this.

[Greg Ercolano]

On 11/6/22 10:32, Albrecht Schlosser wrote:

Once the string is assigned the fl_draw() method that is used to draw the string/label/menu_item is out of control of the user. I have no idea how to solve this.

    Actually that cheat sheet link Ian replied with shows how to control even the menu items.

    That technique intercepts all label drawing including menu drawing.

    But that example still calls a high level fl_draw() to handle drawing the items with proper alignment, etc.

    This is where the flags could help, as then our custom label draw code could still call the high level fl_draw() but without the & and @ handling.

    I suppose if this were easy to add, it'd have been done by now :D

    One thing that might simplify the change so that new methods aren't needed:

    Assuming the draw_symbols flag is implemented throughout the FLTK API as an int, and expects a 0 or 1 value where:

        0=@ off, & and ^ on
        1=@ on, & and ^ on

    I wonder if a non-distruptive way to allow bitfields is if we add a global Fl::option() flag (or other global technique) that is default off, and if 'on', would allow the draw_symbols value to be bitflags with the higher grain control.

    So a 'new' app could do this:

int main() {
    Fl::option(FL_OPTION_DRAWFLAGS, 1); // enable the global feature
    ..
    fl_draw(s,x,y,w,h,align,drawfunc,0,FL_DRAWFLAGS_CTRLCHARS|FL_DRAWFLAGS_SYMBOLS);  // ^ and @ but not &
}

    ..and any existing code within FLTK that simply passes the user values through would all work properly.

    But within fltk if we set the flag to a constant, e.g.

      // old way
      fl_draw(..., 0); // draw symbols off
      fl_draw(..., 1); // draw symbols on

    ..then that code has to take into account the global setting, to keep old behavior the same:

      // new way
      fl_draw(..., Fl::option(FL_OPTION_DRAWFLAGS) ? (FL_DRAWFLAGS_ALL & ~FL_DRAWFLAGS_SYMBOLS) : 0; // draw symbols off
      fl_draw(..., Fl::option(FL_OPTION_DRAWFLAGS) ? (FL_DRAWFLAGS_ALL)                         : 1; // draw symbols on

   This logic could probably be hidden in a function or macro, e.g.

#define FL_DRAW_SYMBOLS_FLAG_OFF (Fl::option(FL_OPTION_DRAWFLAGS) ? (FL_DRAWFLAGS_ALL & ~FL_DRAWFLAGS_SYMBOLS) : 0)
#define FL_DRAW_SYMBOLS_FLAG_ON  (Fl::option(FL_OPTION_DRAWFLAGS) ? (FL_DRAWFLAGS_ALL)                         : 1)

    ..so those could be used in place of the FLTK constants that preserves old
    behavior while also supporting the new.

    I dunno, just thinking aloud.

[Albrecht Schlosser]

On 11/7/22 00:32 Greg Ercolano wrote:

On 11/6/22 10:32, Albrecht Schlosser wrote:

Once the string is assigned the fl_draw() method that is used to draw the string/label/menu_item is out of control of the user. I have no idea how to solve this.

    Actually that cheat sheet link Ian replied with shows how to control even the menu items.

OK, I must admit that I didn't look at your nice example before I replied.

    That technique intercepts all label drawing including menu drawing.

I see. But it redefines a particular label type which is really "super-global" which in turn may not be what you want to be able to store for instance "@" in a menu item in literal form, i.e. w/o parsing the string and copying it with escaping all special symbols.

    This is where the flags could help, as then our custom label draw code could still call the high level fl_draw() but without the & and @ handling.

    I suppose if this were easy to add, it'd have been done by now :D

... or nobody asked for it yet. ;-)

    One thing that might simplify the change so that new methods aren't needed:

    Assuming the draw_symbols flag is implemented throughout the FLTK API as an int, and expects a 0 or 1 value where:

        0=@ off, & and ^ on
        1=@ on, & and ^ on

    I wonder if a non-distruptive way to allow bitfields is if we add a global Fl::option() flag (or other global technique) that is default off, and if 'on', would allow the draw_symbols value to be bitflags with the higher grain control.

    So a 'new' app could do this:

int main() {
    Fl::option(FL_OPTION_DRAWFLAGS, 1); // enable the global feature
    ..
    fl_draw(s,x,y,w,h,align,drawfunc,0,FL_DRAWFLAGS_CTRLCHARS|FL_DRAWFLAGS_SYMBOLS);  // ^ and @ but not &
}

[...]

I checked two fl_draw() methods:

  - https://www.fltk.org/doc-1.4/group__fl__drawings.html#ga0c1fe5be700c7b7079caf5dfd9fde9cd
  - https://www.fltk.org/doc-1.4/group__fl__drawings.html#ga21d4007e0096cfa9c9906ebb373fa8ee

The latter seems to be the one you're actually talking about.

It is described as "The same as fl_draw(const char*,int,int,int,int,Fl_Align,Fl_Image*,int) with the addition of the callthis parameter, ..."

i.e. it refers to the former, and the former documents:

  "The draw_symbols argument specifies whether or not to look for symbol names starting with the '@' character' ".

There's room for interpretation. An `int' specifying "whether or not ..." can be 0 for NOT and 1 (or generally non-zero) for true. It does not specify which value the int should have or which bits of it would be interpreted.

Hence we could - maybe - just specify that this argument uses a bit flag with the bits as proposed by you. It would be compatible if user programs used only 0 and 1 as arguments.

However, this is all about a global behavior change, even if (as you also suggested) this would be enabled or disabled by a global option, i.e. per program.

At this point I can't imagine further what this would be good for or not. I can't think any further about this and the implications it would have on any program.

Beyond that I don't think that a global behavior change of label drawing is what we want or need, even if it could be switched on and off per program. IMHO we need to specify the drawing behavior per widget or menu item (or whatever) and not globally.

But that's only my gut feeling. I can't tell for sure what is really needed by a particular program. However, making it too complicated and then "only" being able to change the behavior globally doesn't seem adequate. Or maybe I'm missing something.

[Greg Ercolano]

On 11/7/22 08:58, Albrecht Schlosser wrote:

    That technique intercepts all label drawing including menu drawing.

I see. But it redefines a particular label type which is really "super-global" which in turn may not be what you want to be able to store for instance "@" in a menu item in literal form, i.e. w/o parsing the string and copying it with escaping all special symbols.

    Right -- it's useful only in circumstances where the entire app doesn't
    want any symbol parsing throughout.

    This is where the flags could help, as then our custom label draw code could still call the high level fl_draw() but without the & and @ handling.

    I suppose if this were easy to add, it'd have been done by now :D

... or nobody asked for it yet. ;-)

    Heh, well over the years actuall many people bump into this,
    including the OP (on fltk.general) and myself,  who just want to
    turn off all the @, &, / stuff.

    Perhaps we could provide (if we don't have already?) a public function
    that escapes/unescapes special symbols in the ways FLTK needs so
    they'll pass thru to the GUI unmolested, and can be read back and
    safely unescaped.

    Then a user having trouble could simply wrap that escape function
    around string(s) in question, e.g.

       item->label = fl_escape_label("&Email: someone@foo"); // convert string to "&&Email: someone\@foo"
       char *s = fl_unescape_label(item->label);             // get back the label "unescaped"

    Such a function could take optional bitflags to give more precise control
    over which chars get escaped, e.g. &, @, /, etc.

    From a user's perspective, such a function is hard to write;
    I can't even remember all the "special" ways to escape chars in FLTK;
    in some cases backslash, in some cases doubling the chars.
    A pair of esc/unesc functions would make that easier.

    Such a solution might remove the need for everything I've suggested so far,
    and would probably be the easy solution for users who run into this.

    So a 'new' app could do this:

int main() {
    Fl::option(FL_OPTION_DRAWFLAGS, 1); // enable the global feature
    ..
    fl_draw(s,x,y,w,h,align,drawfunc,0,FL_DRAWFLAGS_CTRLCHARS|FL_DRAWFLAGS_SYMBOLS);  // ^ and @ but not &
}

[...]

I checked two fl_draw() methods:

  - https://www.fltk.org/doc-1.4/group__fl__drawings.html#ga0c1fe5be700c7b7079caf5dfd9fde9cd
  - https://www.fltk.org/doc-1.4/group__fl__drawings.html#ga21d4007e0096cfa9c9906ebb373fa8ee

The latter seems to be the one you're actually talking about.

    Yes, that fl_draw() method with the 'callthis' argument..

    If you look at the code for that method, that's where the @, &, ^X stuff
    seems to be handled by way of local/private expand_text_() function
    which actually does the work.

    BTW, that expand_text_() function could really use some docs;
    it's very hard to tell what all it does, without picking it apart.

There's room for interpretation. An `int' specifying "whether or not ..." can be 0 for NOT and 1 (or generally non-zero) for true. It does not specify which value the int should have or which bits of it would be interpreted.

    Ya, that's why I was thinking a global option would be necessary
    to change the way the 'draw_symbols' is interpreted throughout the API:

            - Unset (default) preserves the current 'vague' draw_symbols flag where: 0=off, any non-zero=on
            - Set (new) enables draw_symbols to be 0=off for all, and bitflags to turn on specific &/@/^

    However, trying to fix this wart can maybe be avoided if we provide the user
    with a way to escape/unescape methods.

    I know it's confusing and unexpected to users to have labels/menu items
    get transformed, and once identified, hard for users to fix; telling them
    "double up your @'s and &'s" is easy to say, but hard to actually implement
    correctly.

    Arguably FLTK should provide escape/unescape functions for all of its
    'special chars' stuff. Not to mention all those extra special @ symbols
    used only in Fl_Browser, which handles changing colors, fonts and such
    within the text strings.

But that's only my gut feeling. I can't tell for sure what is really needed by a particular program. However, making it too complicated and then "only" being able to change the behavior globally doesn't seem adequate. Or maybe I'm missing something.

    Agreed it's complicated, and perahps you were missing how I'm trying to
    offer draw_symbols in a backrwards-compatible way, keeping the vague
    definition for draw_symbols, but can be made more precise with a global option.

[Albrecht Schlosser]

On 11/7/22 21:29 Greg Ercolano wrote:

On 11/7/22 08:58, Albrecht Schlosser wrote:

    I suppose if this were easy to add, it'd have been done by now :D

... or nobody asked for it yet. ;-)

    Heh, well over the years actuall many people bump into this,
    including the OP (on fltk.general) and myself,  who just want to
    turn off all the @, &, / stuff.

    Perhaps we could provide (if we don't have already?) a public function
    that escapes/unescapes special symbols in the ways FLTK needs so
    they'll pass thru to the GUI unmolested, and can be read back and
    safely unescaped.

I agree, that sounds like a much better solution to me.

    Then a user having trouble could simply wrap that escape function
    around string(s) in question, e.g.

       item->label = fl_escape_label("&Email: someone@foo"); // convert string to "&&Email: someone\@foo"
       char *s = fl_unescape_label(item->label);             // get back the label "unescaped"

    Such a function could take optional bitflags to give more precise control
    over which chars get escaped, e.g. &, @, /, etc.

Yes, maybe. I guess it would depend on the context, i.e. to what kind of string it should be applied. I'm not sure if escaping a particular symbol is the same in every context, for instance:

- how do we escape the '@' symbol: is it always '@@' or is it in other contexts maybe '\@'?

- it is clear that '&' needs to be escaped ('&&') in menus and labels but maybe not in another context (Fl_Browser)?

and so on. Maybe we need different functions for different contexts or an extra context argument, or as you say, a flag for every symbol. I tend to think that the "context" argument would be the easiest way to call such a method for the user program. It would be more difficult to decide which flags need to be set, but I can also imagine that a user wants not '@' substitution but still '&' label (shortcut) processing. Looks not easy to create a useful API.

    From a user's perspective, such a function is hard to write;
    I can't even remember all the "special" ways to escape chars in FLTK;
    in some cases backslash, in some cases doubling the chars.
    A pair of esc/unesc functions would make that easier.

I agree.

    Such a solution might remove the need for everything I've suggested so far,
    and would probably be the easy solution for users who run into this.

Yes, I agree again.

    [...] Yes, that fl_draw() method with the 'callthis' argument..

    If you look at the code for that method, that's where the @, &, ^X stuff
    seems to be handled by way of local/private expand_text_() function
    which actually does the work.

I try not to look at such code. It's old and does a lot of stuff that's hard to grok and you often don't know where exactly it is applied, due to a confusing calling structure.

    BTW, that expand_text_() function could really use some docs;
    it's very hard to tell what all it does, without picking it apart.

Is it public (ie. do we need doxygen docs), or is it only for internal usage, i.e. needs docs so devs can understand what it does?

There's room for interpretation. An `int' specifying "whether or not ..." can be 0 for NOT and 1 (or generally non-zero) for true. It does not specify which value the int should have or which bits of it would be interpreted.

    Ya, that's why I was thinking a global option would be necessary
    to change the way the 'draw_symbols' is interpreted throughout the API:

            - Unset (default) preserves the current 'vague' draw_symbols flag where: 0=off, any non-zero=on
            - Set (new) enables draw_symbols to be 0=off for all, and bitflags to turn on specific &/@/^

    However, trying to fix this wart can maybe be avoided if we provide the user
    with a way to escape/unescape methods.

I hope the latter (escape/unescape methods) is the way we will go.

    I know it's confusing and unexpected to users to have labels/menu items
    get transformed, and once identified, hard for users to fix; telling them
    "double up your @'s and &'s" is easy to say, but hard to actually implement
    correctly.

    Arguably FLTK should provide escape/unescape functions for all of its
    'special chars' stuff. Not to mention all those extra special @ symbols
    used only in Fl_Browser, which handles changing colors, fonts and such
    within the text strings.

"... only in Fl_Browser ...": that's why I was thinking about a possible escape/unescape "context" argument.

But that's only my gut feeling. I can't tell for sure what is really needed by a particular program. However, making it too complicated and then "only" being able to change the behavior globally doesn't seem adequate. Or maybe I'm missing something.

    Agreed it's complicated, and perahps you were missing how I'm trying to
    offer draw_symbols in a backrwards-compatible way, keeping the vague
    definition for draw_symbols, but can be made more precise with a global option.

No, I really got that point, but I couldn't imagine all the consequences - and it seems to be too complicated to get it right. I guess in most programs users might want parts of the features enabled, you can't say "always '@' symbol processing but never '&' (shortcut label) processing".

Hence the escape/unescape functions look like a good tool for user programs. Similar to PHP html_escape() or db_escape() functions (names may be different, but you know what I mean) which do different things in different contexts.

[imacarthur]

This is just a "thinking out loud" really, but to me the string escape methods sound like they could be the "path of least resistance" here? 

Though, as ever, the issue will then be knowing which widgets need you to escape the string and which do not!

If we did decide to convert the existing fl_draw method to take a set of flags rather than just an int, then assuming most folks will only ever have set that parameter to (0), (1) or (-1), if they set it at all, then so long as our new "flags" use bit-0 to perform the legacy behaviour, all existing code will Just Work.

Any newer code can then use higher bits to tailor the behaviour (but always with bit-0 clear in those cases.)

That's basically what we are proposing here, is it?

[Albrecht Schlosser]

On 11/9/22 14:12 imacarthur wrote:

This is just a "thinking out loud" really, but to me the string escape methods sound like they could be the "path of least resistance" here? 

Though, as ever, the issue will then be knowing which widgets need you to escape the string and which do not!

Yes, that's true, but this is something only the application programmer can know. They will learn it at the latest when the first user complains. Then it will be good to have such a function.

There is another issue I noticed meanwhile: there is a big potential for memory leaks in functions like proposed by Greg in this thread.

  item->label = fl_escape_label("&Email: someone@foo"); // convert string to "&&Email: someone\@foo"
  char *s = fl_unescape_label(item->label);             // get back the label "unescaped"
    

The latter is simple: either fl_unescape() stores the result in a static (internally allocated) buffer which is overwritten by each call and the user must copy the string or fl_unescape() allocates memory and the user must free() it when it's no longer needed.

The former would have to allocate memory for the converted string and 'item->label' wouldn't "know" whether to free the string later or not. We need to specify an API that can cope with such memory allocation (ownership) issues.

I don't say that it's not possible but it makes things harder to do right.

If we did decide to convert the existing fl_draw method to take a set of flags rather than just an int, then assuming most folks will only ever have set that parameter to (0), (1) or (-1), if they set it at all, then so long as our new "flags" use bit-0 to perform the legacy behaviour, all existing code will Just Work.

Any newer code can then use higher bits to tailor the behaviour (but always with bit-0 clear in those cases.)

I didn't think of someone setting an int that is used like a boolean value to (-1) but I remember to have seen this, likely in code posted by you, Ian.

Your idea to use bit 0 as a flag and use only higher bits for the "new" values and assume "legacy" code if bit 0 is set would likely work.

That's basically what we are proposing here, is it?

Yes, that was my idea although Greg suggested an additional Fl::option() to specify the exact behavior.

Basically we have two possible approaches:

(1) Provide functions to convert strings in user programs, escaping special characters if they shall be used literally.

(2) Modify one or more fl_draw() methods to take flags that say how to handle the given strings.

We could do both because they have really different usages.

Since widgets and item labels etc. are assigned once and used later internally by FLTK I believe approach (1) is more important than (2) which can likely only be used by user code in their own draw() methods whereas (1) would be helpful for all string assignments and input arguments like paths (filenames) in menu items.

[melcher....@googlemail.com]

Just a reminder, in Fl_Browser, we use the `@` character with a special meaning for browser lines. By adding `@.` to the item text, all further special handling of `@` is disabled. This is a crutch, but it helps to prepend `@.` to all entries, just in case they may have a `@` inside the text.

Also, the `@` format character can be changed to any other character per Fl_Browser. 

So here is my idea: we could allow `&.` to disable underscores, and maybe even `/.` to disable the special meaning of further '/' in submenu paths. We could even go so far and customise the control characters per widget or even per app. Maybe even to utf8 sequences. Maybe '‿' instead of '_'? etc.

[Albrecht Schlosser]

On 11/9/22 16:01 'melcher....@googlemail.com' via fltk.coredev wrote:
> Just a reminder, in Fl_Browser, we use the `@` character with a
> special meaning for browser lines. By adding `@.` to the item text,
> all further special handling of `@` is disabled. This is a crutch, but
> it helps to prepend `@.` to all entries, just in case they may have a
> `@` inside the text.

I know this and I don't like it. This tends to be used as a "general
prefix" in browser lines (because it's sooooo simple) and in fact it
disables all other '@' sequences in the following text. There should be
another way to switch '@' symbol processing on again (maybe repeat '@.'
?) but this makes it all even more complicated.

> Also, the `@` format character can be changed to any other character
> per Fl_Browser.

... which makes a general `escape_symbol()` function impossible. :-(

We'd need an overloaded function that uses an `Fl_Browser *` argument to
do it correctly (wouldn't be difficult).

> So here is my idea: we could allow `&.` to disable underscores, and
> maybe even `/.` to disable the special meaning of further '/' in
> submenu paths.

'/.' would definitely be a bad choice, see for instance
'/home/user/.config/filename'.

But the idea doesn't sound bad. However I would again ask for another
(or the same) sequence to switch symbol processing on again.

> We could even go so far and customise the control characters per
> widget or even per app. Maybe even to utf8 sequences. Maybe '‿'
> instead of '_'? etc.

Nice ;-)

[imm]

On Wed, 9 Nov 2022 at 14:04, Albrecht Schlosser wrote:
>
> I didn't think of someone setting an int that is used like a boolean value to (-1) but I remember to have seen this, likely in code posted by you, Ian.
>

Maybe I'm too Old Skool or something, but (-1) at least used to be
very common for "TRUE" with (0) for FALSE.

It used to be commonplace to see things like this in header files:

#define FALSE (0)
#define TRUE (~FALSE)

So then TRUE is "all bits set", and FALSE is "no bits set", making
them as different as possible for the data types.

And hence TRUE reads as (-1) if assigned to an int... Which is where
we started from.

I think maybe a lot of the "ancient" bits of fltk also use (-1) rather
than (1) to denote that they consumed an event etc.
So maybe it is not just me.

[Bill Spitzak]

It might be ok to have "@." disable the splitting of menu items at the slashes as well.

I really don't see any reason to turn off the expansion of control characters to "^X", they don't print anything useful anyway.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/a8c941d4-3118-e826-9292-4edb41a96d38%40online.de.

[Albrecht Schlosser]

On 11/9/22 16:47 imm wrote:
> On Wed, 9 Nov 2022 at 14:04, Albrecht Schlosser wrote:
>> I didn't think of someone setting an int that is used like a boolean value to (-1) but I remember to have seen this, likely in code posted by you, Ian.
>>
> Maybe I'm too Old Skool or something, but (-1) at least used to be
> very common for "TRUE" with (0) for FALSE.

Maybe I've seen this in Fortran long ago but it's always a question
whether it is defined by the standard or implementation defined.

> It used to be commonplace to see things like this in header files:
>
> #define FALSE (0)
> #define TRUE (~FALSE)
>
> So then TRUE is "all bits set", and FALSE is "no bits set", making
> them as different as possible for the data types.

I must admit that I entered the "C world" very late, maybe 1997 or so,
and I never saw this construct. But you may certainly be right.

Recently I debugged some C++ (FLTK) code and found that `bool`
true/false is 1 or 0, respectively. Again, I don't know if it's standard
or implementation defined. Anybody?

> And hence TRUE reads as (-1) if assigned to an int... Which is where
> we started from.

Yep.

> I think maybe a lot of the "ancient" bits of fltk also use (-1) rather
> than (1) to denote that they consumed an event etc.

I don't know how "ancient" these bits of FLTK are. As long as I remember
(since 2002-2003 maybe) you always had to return "1" if you consumed the
event.

Well, checking the docs: chapter "Handling Events" says you must return
"non-zero" for *some* events but explicitly say "1" for some other events.

Fl_Widget::handle() documents return values must be 0 or 1 (not non-zero).

https://www.fltk.org/doc-1.4/classFl__Widget.html#a9cb17cc092697dfd05a3fab55856d218

> So maybe it is not just me.

Maybe.