Please vote for Core Add-Ons

[melcher....@googlemail.com]

In light of Manolo's Fl_Native_Input, I decided to propose this now. I was originally waiting for a few CMake changes that Albrecht was planning.

Idea:

Add widgets, drivers, libraries, fluid plugins, and tests to FLTK core at configuration time, using a single `cmake -D...` option. This is meant as an in-between step between a truly external widget, and a widget that is an integral part of the core library.

Reasoning:

I created an issue years ago with an interrupted implementation of the SDL driver, adding work for everyone else while I could not wrap the project up. We ended up dragging the cow around for a while, until I decided to remove it from master. For the second round, I envisioned "Add Ons". Basically a way to add  The concept ist here. It only allows for adding tests, but can easily be expanded for the list above.

https://github.com/MatthiasWM/fltk-addons-1.5

https://github.com/fltk/fltk/compare/master...MatthiasWM:fltk:core_addons

How difficult is it for the developer:

The developer can create they add-on independently. He needs to add one or more files that are included by CMake. The rest of the structure is a mirror of the existing FLTK structure. So make a repo with directory somewhere. Add a test in the `tests` directory, and create `CMake/fl_addon_test.cmake`.

What changes for core developers:

Not much. Statements like `fl_include_all(FLTK_CORE_ADDONS "CMake/fl_addon_test.cmake")` will be placed at five strategic positions. That's all.

How difficult is it for the user:

The user checks out the add-one somewhere anywhere into their file system (or uses fetch_content in their project). The cmake line must then add a list of all add-on directories he wishes to use:

cmake -B build -DFLTK_CORE_ADDONS="../NativeInput/;../SDLDriver"

and this will become an integral part of their FLTK library.

Finally:

I find this immensely practical. It allows us to verify that an adding will work in the long run. If it does, going from a core add-on to code integrated into the core is easy. It's the only way for me to write new drivers without stepping on core devs toes. But it would also be helpful for other complex additions.

[Manolo]

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

In light of Manolo's Fl_Native_Input, I decided to propose this now. I was originally waiting for a few CMake changes that Albrecht was planning.

This proposal seems interesting, possibly also in the context of the proposal for a new Fl_Native_Input class.

But I have a hard time understanding how it works, so I can't vote yet.

Idea:

Add widgets, drivers, libraries, fluid plugins, and tests to FLTK core at configuration time, using a single `cmake -D...` option. This is meant as an in-between step between a truly external widget, and a widget that is an integral part of the core library.

Reasoning:

I created an issue years ago with an interrupted implementation of the SDL driver, adding work for everyone else while I could not wrap the project up. We ended up dragging the cow around for a while, until I decided to remove it from master. For the second round, I envisioned "Add Ons". Basically a way to add  The concept ist here. It only allows for adding tests, but can easily be expanded for the list above.

"The list above": what list?

 

https://github.com/MatthiasWM/fltk-addons-1.5

Is this a complete modification of the FLTK  source tree? or just a preliminary draft of what is aimed at?

https://github.com/fltk/fltk/compare/master...MatthiasWM:fltk:core_addons

How difficult is it for the developer:

The developer can create they add-on independently. He needs to add one or more files that are included by CMake. The rest of the structure is a mirror of the existing FLTK structure.

Does that mean duplicating the FLTK source tree in another git repo?

 

So make a repo with directory somewhere.

I don't understand this sentence.

 

Add a test in the `tests` directory, and create `CMake/fl_addon_test.cmake`.

Is it the test directory of the FLTK source tree?

 

What changes for core developers:

Not much. Statements like `fl_include_all(FLTK_CORE_ADDONS "CMake/fl_addon_test.cmake")` will be placed at five strategic positions. That's all.

What are these strategic positions?

 

……

 

Matthias: could you, for example, prepare and present a complete rewrite of the Fl_Native_Input proposal  in the form of an FLTK add-on?

[melcher....@googlemail.com]

Manolo schrieb am Dienstag, 6. Mai 2025 um 12:14:30 UTC+2:

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

I created an issue years ago with an interrupted implementation of the SDL driver, adding work for everyone else while I could not wrap the project up. We ended up dragging the cow around for a while, until I decided to remove it from master. For the second round, I envisioned "Add Ons". Basically a way to add  The concept ist here. It only allows for adding tests, but can easily be expanded for the list above.

"The list above": what list?

 

widgets, drivers, libraries, fluid plugins, and tests  

https://github.com/MatthiasWM/fltk-addons-1.5

Is this a complete modification of the FLTK  source tree? or just a preliminary draft of what is aimed at?

This is the example for adding tests. Widgets, drivers, libraries, and fluid extensions will need a similar "include" line. But that should be it.

The developer can create they add-on independently. He needs to add one or more files that are included by CMake. The rest of the structure is a mirror of the existing FLTK structure.

Does that mean duplicating the FLTK source tree in another git repo?

Not the source code, just the part of the directory structure that is relevant. "CMake/some_script.cmake" for the scripts that register the add-on, /tests/your_test.cxx for tests, etc.

So make a repo with directory somewhere.

I don't understand this sentence.

Sorry. Direct German to Englisch doesn't;t always work ;-) . I meant to say that you can create this add-on wherever you like. There are no restrictions. As long as the CMake variable `FLTK_CORE_ADDONS` has the path, the add-on will be included.

  

Add a test in the `tests` directory, and create `CMake/fl_addon_test.cmake`.

Is it the test directory of the FLTK source tree?

The entire add-on is outside of the fltk library tree. It can be at the same directory level if you like, so the FLTK_CORE_ADDONS path ist "../my_addon".

In the context of a bigger project, one could use `FetchContent` and set FLTK_CORE_ADDONS to ${my_addon_SOURCE_DIR} .

I will add examples for this to my GitHub repo.

What changes for core developers:

Not much. Statements like `fl_include_all(FLTK_CORE_ADDONS "CMake/fl_addon_test.cmake")` will be placed at five strategic positions. That's all.

What are these strategic positions?

The plan is to add four more lines like `fl_include_all(FLTK_CORE_ADDONS "CMake/fl_addon_test.cmake")` for the other add-on types in  src/CMakeLists.txt, src/drivers/CMakeLists.txt, fluid/CMakeLists.txt .

Matthias: could you, for example, prepare and present a complete rewrite of the Fl_Native_Input proposal  in the form of an FLTK add-on?

I will try to find the time tonight. I want to know myself if this is a good alternative.

 

[Albrecht Schlosser]

On 5/6/25 14:51 'melcher....@googlemail.com' wrote:

The plan is to add four more lines like `fl_include_all(FLTK_CORE_ADDONS "CMake/fl_addon_test.cmake")` for the other add-on types in  src/CMakeLists.txt, src/drivers/CMakeLists.txt, fluid/CMakeLists.txt .

Matthias: could you, for example, prepare and present a complete rewrite of the Fl_Native_Input proposal  in the form of an FLTK add-on?

I will try to find the time tonight. I want to know myself if this is a good alternative.

To answer both requests ("Core Add-Ons" from Matthias and "Fl_Native_Input widget" from Manolo):

I like the idea to be able to create FLTK add-ons in an external repository (or local code base), as Matthias proposed. I also like the idea to use native input widgets, as Manolo proposed.

However, I don't like to put code that is not yet 100% ready into the FLTK core. I didn't have enough time to review and test both proposals. Therefore my current vote WOULD BE -1 to add these proposals right now. But see below for later ...

(1) Regarding Manolo's proposal: I believe we need to review the code and we'd likely need more testers (as Ian wrote, maybe Chinese or other Eastern languages/scripts). I'm willing to review the code but I'm likely not able to test any input methods.

(2) Regarding Matthias' proposal: I'd like to take a deeper look at the CMake implementation and how this would work with more add-ons from Matthias' list, especially widgets, but also other stuff like drivers. I'm willing to contribute my part on (potentially) improving the CMake code. There are some caveats that come to mind right now (I'm still thinking about the issues), but I really need more time to check this.

My proposal is to see what Matthias can do by (re-)writing Manolo's proposal as an add-on for FLTK. This would enable us to test (a) Matthias' and (b) Manolo's proposal in a "real" test scenario w/o adding the code directly to the FLTK core repository. This would also show how a new widget can be added as an add-on which would be a great achievement for the future.

If this all works out well, then we can go ahead and integrate it in the FLTK core repository. Or decide to integrate Matthias' add-on feature and leave Manolo's proposal as an add-on. Maybe not many users will need such an RTL input widget and we don't need to put it in the core at all ? ... If it is easy to add as an extension. This might also be an opportunity to start a first poll on GitHub, for instance "Do you need right-to-left text input widgets?". This could help us to decide if it should be done.

Whatever we decide, I believe that this is not yet the time to add any of these proposals directly to the FLTK core w/o further review and testing.

Therefore I don't vote right now, but we should keep working on and testing both proposals and decide later when they are more mature.

[Manolo]

Le mardi 6 mai 2025 à 18:36:26 UTC+2, Albrecht-S a écrit :

……

(1) Regarding Manolo's proposal: I believe we need to review the code and we'd likely need more testers (as Ian wrote, maybe Chinese or other Eastern languages/scripts). I'm willing to review the code but I'm likely not able to test any input methods.

 

I understand and agree a review of the new code which does something completely new to FLTK, that is, embed a

non-FLTK widget inside an FLTK window and interact with it, would be useful. Thanks Albrecht for volunteering to do it.

Thanks Matthias for volunteering to reorganize the new Fl_Native_Input class as an FLTK add-on.

In contrast, I believe the necessity to involve testers using CJK input methods does not exist.

The reason is that the code which interacts with these IMs is not in FLTK but in each platform's native text widget,

and these widgets have been tested by millions of Windows, Unix, and macOS users.

There's a minor caveat to this under Wayland/X11 where FLTK code transmits to the running IM the location of the

text insertion cursor. The new code does that calling function fl_set_spot() exactly as plain FLTK widgets 

Fl_Input and Fl_Text_Display do it in FLTK 1.4. Again, that's been tested already.

[melcher....@googlemail.com]

I added the ability to have widget add-ons - not the NativeInput yet, just some silly scrollbar variant I had laying around.

This is how to test it from the command line. Looking at the GitHub diff, you''ll see that there are very few changes. The position of the "include_all"s are not deeply researched.

Here is the turn-by-turn to try it out:

```
git clone https://github.com/MatthiasWM/fltk.git
git clone https://github.com/MatthiasWM/fltk-addons-1.5.git
cd fltk
git checkout core_addons
cmake -B build -DFLTK_CORE_ADDONS="../fltk-addons-1.5.git/Fl_Range_Slider"
cmake --build build --target range_slider
build/bin/test/range_slider
```

[melcher....@googlemail.com]

Ok, I added Native Input for macOS to fltk-addons. Just pull both repos and:

cmake -B build -DFLTK_CORE_ADDONS="../fltk-addons-1.5.git/Fl_Native_Input"

[Manolo]

Le jeudi 8 mai 2025 à 22:44:32 UTC+2, melcher....@googlemail.com a écrit :

Ok, I added Native Input for macOS to fltk-addons. Just pull both repos and:

cmake -B build -DFLTK_CORE_ADDONS="../fltk-addons-1.5.git/Fl_Native_Input"

Great! I've cloned it here, built, and it's working (see small caveat below).

I should be able to add myself the code for other platforms.

You've missed, though, the single little change needed in FLTK core.

Without it, arrow keys don't move the cursor in the native_input demo prog.

Here is the necessary modification:

[Manolo]

Le vendredi 9 mai 2025 à 07:40:42 UTC+2, Manolo a écrit :

…… the single little change needed in FLTK core.

Without it, arrow keys don't move the cursor in the native_input demo prog.

This illustrates a constraint of the add-on model, if I understand it correctly:

  an add-on should not depend on any change of the FLTK core source code.

Class Fl_Native_Input does require a (tiny) change in the core, for the macOS

platform only. I don't think it can be done without this change.

This change takes into account a situation that does not occur in the standard

libfltk: the focus is to a subview of the main view of a window. In standard libfltk

there are no subviews, only one main view in each window or subwindow.

Therefore, the change could be added to the FLTK core with no risk even if

class Fl_Native_Input is put in an add-on. But that does break a bit the border

between FLTK core and FLTK add-on.

Matthias: is that correct? or would you see another way to go?

 

[Albrecht Schlosser]

On 5/9/25 11:03 Manolo wrote:

Le vendredi 9 mai 2025 à 07:40:42 UTC+2, Manolo a écrit :

…… the single little change needed in FLTK core.

Without it, arrow keys don't move the cursor in the native_input demo prog.

This illustrates a constraint of the add-on model, if I understand it correctly:

  an add-on should not depend on any change of the FLTK core source code.

...

I agree, that's something a simple "add-on" can't do. I'm not talking about the option to add the few statements in question to the FLTK core anyway. This could be done in this case (as you, Manolo, wrote), but this is not a general solution of this issue.

Anyway, this is a good test that demonstrates that some "add-ons" may also need patches in the core which should hopefully be a rare (?) exception.

Matthias: is that correct? or would you see another way to go?

Replying for myself, not for Matthias: Theoretically our CMake code could apply patches to the FLTK source code (by using another "hook") in the configure or generate stage, but this would break the rule that CMake does not modify the source tree when building a project.

Users needing patches to apply their own add-ons would be able to use CMake's FetchContent module and apply their own patches *before* building FLTK with their add-ons, but this is something that should be avoided if possible.

However, this would be in the user's responsibility if they were using an add-on in their private code. It's a totally different story if someone wanted to offer an add-on for public use. Then one patch might conflict with patches of another add-on, they might not apply cleanly after FLTK changes, etc. etc..

[Manolo]

Le vendredi 9 mai 2025 à 07:40:42 UTC+2, Manolo a écrit :

……

I should be able to add myself the code for other platforms.

I tried, but did not succeed with the Wayland/X11 platforms.
It's necessary to add a link dependency for the FLTK+add-on

to Pkgconfig::GTK3

How to do that in the add-on scheme?

In the classic scheme where the core FLTK is modified, that

is done by this part of file src/CMakeLists.txt :

if(FLTK_OPTION_NATIVE_INPUT AND FLTK_USE_CAIRO)
  list(APPEND OPTIONAL_LIBS PkgConfig::GTK3)
endif(FLTK_OPTION_NATIVE_INPUT AND FLTK_USE_CAIRO)

[melcher....@googlemail.com]

Manolo schrieb am Freitag, 9. Mai 2025 um 11:03:21 UTC+2:

Le vendredi 9 mai 2025 à 07:40:42 UTC+2, Manolo a écrit :

…… the single little change needed in FLTK core.

Without it, arrow keys don't move the cursor in the native_input demo prog.

This illustrates a constraint of the add-on model, if I understand it correctly:

  an add-on should not depend on any change of the FLTK core source code.

Class Fl_Native_Input does require a (tiny) change in the core, for the macOS

platform only. I don't think it can be done without this change.

 

Matthias: is that correct? or would you see another way to go?

Yes, I saw that but forgot to push it ;-) . It's not possible to change existing source code this way. You can change CMake variables though (intentional) and modify the build setup to point to another file, but in this particular case, it would not make much sense.

The Wayland additional link dependency modification is ok that way. Just by reading it, I don't know what's wrong. Maybe OPTIONAL_LIBS is not set yet when the add-on is included. This is just a proof of concept at this point, and either the position of the include_all line can move, or the instantiation of OPTIONAL_LIBS can move - if that is what is causing your issues.

 

[Manolo]

Le samedi 10 mai 2025 à 00:44:15 UTC+2, melcher....@googlemail.com a écrit :

The Wayland additional link dependency modification is ok that way. Just by reading it, I don't know what's wrong. Maybe OPTIONAL_LIBS is not set yet when the add-on is included. This is just a proof of concept at this point, and either the position of the include_all line can move, or the instantiation of OPTIONAL_LIBS can move - if that is what is causing your issues.

 

OK. I've found the following patches allow for an add-on to require additional libraries at link stage:

1) patch to the FLTK source tree, adapted to allow for add-ons (fltk-for-addons)

2) patch to the add-on source tree (addons-optional-libs)

These initialize a new cmake variable named FL_ADDON_OPTIONAL_LIBS containing extra libraries

and later call macro append_optional_libs() for each such library.

 

[Albrecht Schlosser]

BTW: Mozilla call their extensions "addons" (not "add-ons"). I suggest to use (and I use below) this spelling for FLTK as well. I hope you agree to do this also in the "official version".

On 5/10/25 08:26 Manolo wrote:

Le samedi 10 mai 2025 à 00:44:15 UTC+2, melcher....@googlemail.com a écrit :

The Wayland additional link dependency modification is ok that way. Just by reading it, I don't know what's wrong. Maybe OPTIONAL_LIBS is not set yet when the add-on is included. This is just a proof of concept at this point, and either the position of the include_all line can move, or the instantiation of OPTIONAL_LIBS can move - if that is what is causing your issues.

@Matthias, to clarify: the problem was that the CMake variable `OPTIONAL_LIBS` was not used in your version (rewritten as an addon). Dealing with this variable (and `OPTIONAL_INCLUDES`) is something I plan to improve (maybe rewrite completely) anyway.

I read Matthias' message yesterday late in the evening (too late to reply) and I would have written something like: yes, we obviously need another mechanism ("hook") to add link libraries and maybe more, like link directories.

OK. I've found the following patches allow for an addon to require additional libraries at link stage:

1) patch to the FLTK source tree, adapted to allow for add-ons (fltk-for-addons)

2) patch to the add-on source tree (addons-optional-libs)

These initialize a new cmake variable named FL_ADDON_OPTIONAL_LIBS containing extra libraries

and later call macro append_optional_libs() for each such library.

Thanks, Manolo, well done. At least as a proof of concept. To complete this, we would also need something for link directories, but that's already (partially) included in Matthias' patch [1]. So yes, the addon concept seems to be evolving nicely. Thanks to Matthias as well.

I didn't have enough time yet for a real code review. So far I noticed (IIRC) that Manolo's patch already adds a "driver" for macOS to support the Fl_Native_Input widget. If this attempt scales well, then I'm looking forward to see full platform drivers (SDL etc.) being provides as addons, as Matthias suggested. This would be awesome!

I would also like to take a deeper look at (i.e. review) Matthias' addon related CMake code [1] ...

Cheers
Albrecht

PS:

[1] So far I noticed an issue that needs to be fixed in the final version: in file Fl_Range_Slider/CMake/fl_addon_src.cmake we have in line 18:
```
include_directories(${FL_ADDON_BASE})
```

This is one of these global CMake property assignments we must avoid because they don't work well with "Modern CMake". This works for now (proof of concept) but may miss setting correct "PUBLIC" properties to be inherited by user programs and may fail if the resulting lib will be installed [2]. Anyway, it's good as a starting point, I'm looking into this anyway ...

[2] Note: unfortunately there are still some occurrences of 'include_directories()' in current 'master' that need to be fixed as well. :-( This is one of the points on my to-do list.

[melcher....@googlemail.com]

Albrecht-S schrieb am Samstag, 10. Mai 2025 um 15:38:23 UTC+2:

BTW: Mozilla call their extensions "addons" (not "add-ons"). I suggest to use (and I use below) this spelling for FLTK as well. I hope you agree to do this also in the "official version".

Sure. OK.

 

On 5/10/25 08:26 Manolo wrote:

Le samedi 10 mai 2025 à 00:44:15 UTC+2, melcher....@googlemail.com a écrit :

The Wayland additional link dependency modification is ok that way. Just by reading it, I don't know what's wrong. Maybe OPTIONAL_LIBS is not set yet when the add-on is included. This is just a proof of concept at this point, and either the position of the include_all line can move, or the instantiation of OPTIONAL_LIBS can move - if that is what is causing your issues.

@Matthias, to clarify: the problem was that the CMake variable `OPTIONAL_LIBS` was not used in your version (rewritten as an addon). Dealing with this variable (and `OPTIONAL_INCLUDES`) is something I plan to improve (maybe rewrite completely) anyway.

That is very easy to fix without adding another variable. Just move the line 662 `set(OPTIONAL_LIBS)` to the beginning of src/CMakeLists.txt . That will make it available in the addon. Then you can insert the line `list(APPEND OPTIONAL_LIBS Pkgconfig::GTK3)` and it should work fine. There are some other places where a similar strategy makes sense.

 

[Manolo]

Le samedi 10 mai 2025 à 22:52:38 UTC+2, melcher....@googlemail.com a écrit :

……

That is very easy to fix without adding another variable. Just move the line 662 `set(OPTIONAL_LIBS)` to the beginning of src/CMakeLists.txt . That will make it available in the addon. Then you can insert the line `list(APPEND OPTIONAL_LIBS Pkgconfig::GTK3)` and it should work fine. There are some other places where a similar strategy makes sense.

 

I had tried that already, and tried again this morning. It fails with this error at CMake generate time:

"CMake Error at src/CMakeLists.txt:687 (target_link_libraries):
  Target "fltk" links to:
    Pkgconfig::GTK3
  but the target was not found."

The line 687 in question is

  target_link_libraries     (${target} PUBLIC ${OPTIONAL_LIBS})
inside the add_optional_libs() macro definition.

[Albrecht Schlosser]

Although it *can* work if done correctly, this is definitely the wrong way to do it. I made a quick test with another approach that seemed to work for me, but that was only a "simulation" in another environment.

We need to define a clean API which authors of addons can use. Accessing (local) CMake variables of the FLTK core should absolutely be avoided (forbidden), as well using such local macros like add_optional_libs() etc.. These variables and macros are implementation details that can be changed at any time, and if addons used such a fragile interface we could either not change such code anymore (which I definitely plan to do), or every change could break addon code of users.

I'm working on a better concept, and I strive for more isolation of CMake code of addons and the FLTK core. One thought is to provide convenient functions the addon author can call, and then to keep this API as stable as possible. As soon as it is published officially it should not need to be changed much. Hopefully. This is not easy to achieve, but that's the only chance to "do it right".

Two things for better isolation would be

(a) use functions rather than macros where possible and
(b) use something like add_subdirectory(addons).

Both functions and subdirectories have their own scope in CMake which contributes to better isolation than calling macros.

As an example, please see attached file 'fltk_addon_cheat.diff', which is really a quick hack. The diff is against branch core_addons of Matthias' fork. This does four things as simple examples:

1) it removes two files from the list of sources (IMGCPPFILES) and
2) it adds these files as sources to library targets at the very end of src/CMakeLists.txt
3) it adds target_link_libraries() to the images targets
4) it adds target_link_directories() to the targets

The next step would be to put similar statements into a well-defined function that the addon can call, and to invoke the addon code in the same or a similar way as it is done in that file already with `fl_include_all(FLTK_CORE_ADDONS "CMake/fl_addon_src.cmake")`.

This is work in progress, I'm still investigating...

@Manolo: for the time being you could try to use something like my code in your addon. Note that it must be called late in src/CMakeLists.txt, i.e. after all the library targets have been defined, rather than before this is done, as it is now in Matt's branch. Therefore the `fl_include_all()` call would need to be moved down to where my patch adds the code. My hack uses `gtk-3` literally for simplicity.

[Manolo]

Le dimanche 11 mai 2025 à 13:02:18 UTC+2, Albrecht-S a écrit :
   @Manolo: for the time being you could try to use something like my code in your addon.

I've found the following patches allow for the Fl_Native_Input addon using your approach (Albrecht's):

1) patch to the FLTK source tree, adapted to allow for addons (fltk-for-addonsV2.patch.txt)

2) patch to the Fl_Native_Input addon source tree (addons-Fl_Native_InputV2.patch.txt)

@Matthias: would you agree to commit these or a variant of them to your addon FLTK fork?

[Albrecht Schlosser]

On 5/16/25 16:12 Manolo wrote:

Le dimanche 11 mai 2025 à 13:02:18 UTC+2, Albrecht-S a écrit :

   @Manolo: for the time being you could try to use something like my code in your addon.

I've found the following patches allow for the Fl_Native_Input addon using your approach (Albrecht's):

1) patch to the FLTK source tree, adapted to allow for addons (fltk-for-addonsV2.patch.txt)

2) patch to the Fl_Native_Input addon source tree (addons-Fl_Native_InputV2.patch.txt)

Thanks, Manolo, your new patches look like a step in the right direction, although they are IMHO not yet perfect. First of all I'd like to have a better separation than calling CMake *macros*, but this is something I still need to work on. I've been busy with private activities recently and I've also been working on removing deprecated functions and methods from FLTK 1.5 which is more work than anticipated (to do it right and with sufficient documentation for users).

Some notes:

1. fltk-for-addonsV2.patch.txt:

If we are calling macros, then all the variables set/defined in the addons must be initialized once in the calling CMake code (the "core", i.e. src/CMakeLists.txt) and the addon specific code must only *add* more items, e.g. with `list(APPEND ...)`. This ensures that we can call more than one addon specific macro with `fl_include_all(...)`. Otherwise every called addon would reset the list and the last called addon macro would "win".

Example in Fl_Native_Input/CMake/fl_addon_src.cmake:
```
+  set(FL_ADDON_SOURCES)               # put this in src/CMakeLists.txt before fl_include_all(...)
+  set(FL_ADDON_INCLUDE_DIRECTORIES)   # put this in src/CMakeLists.txt before fl_include_all(...)
+  set(FL_ADDON_OPTIONAL_LIBS)         # put this in src/CMakeLists.txt before fl_include_all(...)
+  list(APPEND FL_ADDON_SOURCES ${FL_ADDON_BASE}/src/Fl_Native_Input.cxx)
```

The first three lines (blue) initialize the variables which must be done in the calling CMake file, and only the last line *adds* a source file which would be correct in this context.

+if(FLTK_BUILD_SHARED_LIBS)
+  target_sources(fltk-shared PRIVATE ${FL_ADDON_IMAGE_SOURCES})
+  target_link_libraries(fltk-shared PRIVATE gtk-3)
+endif()

The 3rd line should read:

+target_link_libraries(fltk-shared PRIVATE ${FL_ADDON_OPTIONAL_LIBS})

('gtk-3' was likely a left-over from my previous suggestion).

2. Fl_Native_InputV2.patch.txt

+  set(FL_ADDON_SOURCES)               # remove this (see above)
+  set(FL_ADDON_INCLUDE_DIRECTORIES)   # remove this (see above)
+  set(FL_ADDON_OPTIONAL_LIBS)         # remove this (see above)


There could be other ways to implement what we want, but I believe that your (Manolo's) new patch, modified as described above, would be a step forward.

@Matthias: would you agree to commit these or a variant of them to your addon FLTK fork?

For me this looks doable, although I didn't test it. Again, this is the 'macro' variant (IMHO not the best/final solution), but it looks better (for me) than before. As I wrote, a step forward.

@Matthias: I'm aware that this may not solve the idea to replace an entire list of source files with another list -- for instance to replace an entire driver with another one, as we discussed of-list -- but I suggest to do the most common step first, i.e. just *add* source files, link directories, etc. to the build (as the name "addon" implies, btw.). This should be doable with the given approach, and I think it's worth adding it to the branch.

[Manolo]

Le vendredi 16 mai 2025 à 20:53:54 UTC+2, Albrecht-S a écrit :

Thanks, Manolo, your new patches look like a step in the right direction, although they are IMHO not yet perfect.

Here is a V3 of my proposed patches :

 

[Albrecht Schlosser]

Well done, this looks very clean now.

Sorry, I forgot one question about the added code in Fl_Cocoa.mm:

+  if ([[self window] firstResponder] != self) {
+    return NO;

IIRC there was an issue with two consecutive '[[' in an old macOS version, or something similar. The solution was to use parentheses like this:

+  if ([([self window]) firstResponder] != self) {
+    return NO;

Shouldn't this be done here as well?

[Manolo]

Le samedi 17 mai 2025 à 13:44:10 UTC+2, Albrecht-S a écrit :

Sorry, I forgot one question about the added code in Fl_Cocoa.mm:

+  if ([[self window] firstResponder] != self) {
+    return NO;

IIRC there was an issue with two consecutive '[[' in an old macOS version, or something similar. The solution was to use parentheses like this:

+  if ([([self window]) firstResponder] != self) {
+    return NO;

Shouldn't this be done here as well?

This is typical objective-c code. There are 103 occurrences of '[[' in file Fl_cocoa.mm. I don't remember the issue you think about

but it must have been a misunderstanding.

The real question is different.

Fl_Native_Input requires a tiny but unavoidable change to FLTK-core.

How to do that in the addon model?

I confess I'm still quite wary of this model exactly because new stuff often requires accompanying changes to the core.

[Gonzalo Garramuño]

El 8/5/25 a las 17:44, 'melcher....@googlemail.com' via fltk.coredev escribió:

Ok, I added Native Input for macOS to fltk-addons. Just pull both repos and:

cmake -B build -DFLTK_CORE_ADDONS="../fltk-addons-1.5.git/Fl_Native_Input"

Mathias, I have v0.1.2 of my Vulkan driver that you could try cleaning up and testing with your addons framework.

$ git clone https://github.com/ggarra13/fltk.git
$ git switch vk
$ vulkan_*.sh for your different platforms (Windows needs MSys2 for the shell script to work).

There's three Vulkan demos:

vk_shape  - similar to the gl one.
vk_shape_textured - shape with a texture and depth updated
vk_cube - similar to the gl one but of course without FLTK widgets.

The code is now in use in my viewer and these are my findings so far:

1) Vulkan, at least with NVidia drivers, is not equivalent to OpenGL in terms of performance.  I could not get 60fps at 4K.  The best I got was 40fps.
2) Transparent textures perform badly on NVidia graphics cards (my RTX 3080) -- ie. text rendering
3) AMD graphics card on my macOS Intel performs really good (but...)
4) macOS Intel implementation through Vulkan is buggy. I got redraw issues with the same code that works fine on Windows and Linux.

-- 
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 5/17/25 14:08 Manolo wrote:

Le samedi 17 mai 2025 à 13:44:10 UTC+2, Albrecht-S a écrit :

Sorry, I forgot one question about the added code in Fl_Cocoa.mm:

+  if ([[self window] firstResponder] != self) {
+    return NO;

IIRC there was an issue with two consecutive '[[' in an old macOS version, or something similar. The solution was to use parentheses like this:

+  if ([([self window]) firstResponder] != self) {
+    return NO;

Shouldn't this be done here as well?

This is typical objective-c code. There are 103 occurrences of '[[' in file Fl_cocoa.mm. I don't remember the issue you think about

but it must have been a misunderstanding.

The report was in issue #1245, the fix was done by PR #1246 in commit 8b8d92a313f97d5e0e2290ec880758d8606e83c3. The report was about macOS 10.6.8, maybe with a "special" (MacPorts) compiler, I didn't check this further. Please read yourself.

Fact is that '[[' introduces attribute syntax in C++11 and higher. Why this was relevant, and whether it concerns the code above or not, I can't tell. Was it maybe a bug in the older compiler?

The real question is different.

Fl_Native_Input requires a tiny but unavoidable change to FLTK-core.

How to do that in the addon model?

I don't know (yet). We could provide a way to apply patches before building, but this should IMHO be done outside control of the FLTK CMake files, i.e. by the user. This is not quite like a simple "addon" (it's more than that simple). If you define using an addon to add a new widget subclass or something similar, then such code changes should not be necessary - in most (admittedly simple) cases.

I confess I'm still quite wary of this model exactly because new stuff often requires accompanying changes to the core.

The questions I'm seeing is what the addon model is good for, which kind of problems it can solve, and which kind of problems it cannot solve, and of course what we want to use (offer) it for. This is what we are trying to find out here in this thread. I wouldn't expect to have already all answers right now.

The main use case of an addon I can imagine is that a user makes a special widget and publishes the header and the c++ files somewhere. Other users who want to use these widgets would have to put them either in their own code base or add them to the FLTK code base, with all required CMake changes, etc.. This could be simplified if the code was published as an addon. There are likely other cases; I imagine to add user provided schemes and - in the future - "themes", i.e. color palette settings, as discussed recently on GitHub as well. We need to find out how far we can go. If I had the answers already, I would post them right now. ;-)

Things we can't solve (yet ?) are for instance (a) replacing lists of source files with a different set, as Matthias wrote for driver cases (not seen yet in practice) and (b) patching source files as in your case.

---

Another question is whether we can or should add your suggested change to Fl_Cocoa.mm to the core anyway. Would it be useful, would it do any harm, or ... ? Of course, this wouldn't solve the issue of patching the core code in general if necessary, but it would resolve *this* case. I'm asking these questions because I have no idea what this code does, and why it would be needed for the addon.

[Manolo]

Le dimanche 18 mai 2025 à 00:44:35 UTC+2, Albrecht-S a écrit :

On 5/17/25 14:08 Manolo wrote:

Le samedi 17 mai 2025 à 13:44:10 UTC+2, Albrecht-S a écrit :
IIRC there was an issue with two consecutive '[[' in an old macOS version, or something similar. The solution was to use parentheses like this:

+  if ([([self window]) firstResponder] != self) {
+    return NO;

Shouldn't this be done here as well?

This is typical objective-c code. There are 103 occurrences of '[[' in file Fl_cocoa.mm. I don't remember the issue you think about

but it must have been a misunderstanding.

The report was in issue #1245, the fix was done by PR #1246 in commit 8b8d92a313f97d5e0e2290ec880758d8606e83c3.

 Thanks for this pointer.

That issue arose because two '[' characters of different syntactic values where consecutive, the first was opening a C-style array index,

the second was opening an Objective-C message. This situation, I understand, can be a problem for compilation and should be avoided.

But the hundreds of other occurrences of '[[' (or more '[[[') are accepted by all objective-C++ compilers, old or recent.

That's visible because issue #1245 did compile those hundreds of occurrences correctly but barked only at the mixed-type '[[' series.

The modification to Fl_cocoa.mm under discussion here reads

  [[self window] firstResponder]

which is pure Objective-C++. No mixed-type, consecutive '['.

So, please, Albrecht, stop worrying every time you read '[[' because you'll see many. (:=)

[Manolo]

Le dimanche 18 mai 2025 à 00:44:35 UTC+2, Albrecht-S a écrit :

Another question is whether we can or should add your suggested change to Fl_Cocoa.mm to the core anyway. Would it be useful, would it do any harm, or ... ? Of course, this wouldn't solve the issue of patching the core code in general if necessary, but it would resolve *this* case. I'm asking these questions because I have no idea what this code does, and why it would be needed for the addon.

The change to Fl_cocoa.mm discussed here is to add these 3 lines:

  if ([[self window] firstResponder] != self) {

    return NO;

  }

This would not be useful nor would do harm to FLTK, unless an Fl_Native_Input

 object gets created, because the if condition involved would always be FALSE.

When an Fl_Native_Input widget has focus and a shortcut (e.g., ctrl-O) is typed ,

the condition becomes TRUE, and libfltk would fail processing adequately this shortcut

if the "return NO;" statement is not executed.

Thus, this code change can be inserted to FLTK without any risk, but makes sense only

if class Fl_Native_Input is added, or more exactly if FLTK begins to use

focus-accepting macOS native cocoa widgets, something that is not true as of today.

Overall, it doesn't seem natural to separate this code addition to Fl_cocoa.mm from

the creation of the Fl_Native_Input class, although this would do no harm.

Generally, I'm afraid that the addon model will nearly always stumble on big or small

changes to the core required by a proposed addition. For example, didn't classes

Fl_Flex and/or Fl_Grid require the creation of the virtual member function

Fl_Group::on_remove(int) ?

[Albrecht Schlosser]

On 5/19/25 08:49 Manolo wrote:

That issue arose because two '[' characters of different syntactic values where consecutive, the first was opening a C-style array index,

the second was opening an Objective-C message. This situation, I understand, can be a problem for compilation and should be avoided.

OK, understood. Thanks for the explanation.

The modification to Fl_cocoa.mm under discussion here reads

  [[self window] firstResponder]

which is pure Objective-C++. No mixed-type, consecutive '['.

So, please, Albrecht, stop worrying every time you read '[[' because you'll see many. (:=)

Sure. My problem was (and still is) that I don't understand Objective-C and didn't realize the distinction you explained. With this in mind, looking back at the original report, I understand the problem. Thanks.

[Albrecht Schlosser]

On 5/19/25 09:17 Manolo wrote:

Le dimanche 18 mai 2025 à 00:44:35 UTC+2, Albrecht-S a écrit :

Another question is whether we can or should add your suggested change to Fl_Cocoa.mm to the core anyway. Would it be useful, would it do any harm, or ... ? Of course, this wouldn't solve the issue of patching the core code in general ...

This would not be useful nor would do harm to FLTK, unless an Fl_Native_Input

 object gets created, because the if condition involved would always be FALSE.

[detailed explanation removed]

Thus, this code change can be inserted to FLTK without any risk, but makes sense only

if class Fl_Native_Input is added, or more exactly if FLTK begins to use

focus-accepting macOS native cocoa widgets, something that is not true as of today.

OK. The conclusion is that we *could* add it to the core if we *wanted* to leave Fl_Native_Input as an addon. That's only an answer to a hypothetical question and doesn't mean that I recommend to do it (now). I'm only investigating...

Overall, it doesn't seem natural to separate this code addition to Fl_cocoa.mm from

the creation of the Fl_Native_Input class, although this would do no harm.

I agree with your assessment "it doesn't seem natural ...".

But it might be useful in other cases, later, at any yet unknown time in the future. Again, pure hypothetical statement. I'm only trying to investigate options.

Generally, I'm afraid that the addon model will narly aelways stumble on big or small

changes to the core required by a proposed addition. For example, didn't classes

Fl_Flex and/or Fl_Grid require the creation of the virtual member function

Fl_Group::on_remove(int) ?

The latter is correct, but I doubt that "nearly always" is a correct estimation.

Fl_Flex and Fl_Grid are *big* widgets with very special demands, dealing with group members. These new widgets revealed missing functionalities in the core, and after adding the mentioned new core methods, even other core widgets like Fl_Scroll could benefit from this addition.

Thus, trying to add functionalities (e.g. widgets) might reveal missing features or deficiencies in the core that can potentially be fixed in the core and enable users to use their addons. That's how I imagine future development for better support of addons.

That said, maybe Fl_Native_Input is not suitable for usage as an addon, and we may add it to the core instead. Maybe full drivers (as Matthias wants to do) are also not doable as "simple addons". However, my intention is to find out how the addon mechanism can be used to add widgets and other stuff like schemes and color themes etc.. Personally I modified Fl_Scroll (working name: Fl_Scroll_New) which simplifies widget addition and removal. I'm pretty sure that this widget could be implemented as an addon, which is just another example. I'll try to do this in my own repo.

Again, even if I repeat myself: my goal is to find out what kind of stuff can be used with the addon mechanism so users can create their own widgets and more and offer (publish) them as FLTK addons. Our task is to define a good and hopefully simple "addon API" to make this as easy as possible. That's what I want to find out.

Imagine that user X develops a lot of new widgets [1] and publishes them as individual addons. We (FLTK devs) wouldn't have to consider adding these widgets to the core, but other program developers could use them. If it turned out that such wigets were useful for the FLTK core, i.e. for FLTK users in general, we could integrate them later. That, or something like that, is my vision.

[1] See discussion of "FLEET": https://github.com/fltk/fltk/discussions/1255

[melcher....@googlemail.com]

tl;dr: add-ons are not completely thought out yet. This is just a tech demo, but SDL and Native_Input would be great starting point. And yes, I *do* want Native_Input in the core, but I would prefer if it had time to mature (have users actually use it and give feedback), and an add-on would be one convenient way to do that.

Apologies guys, I was busy with work and another project on top of that. Thanks for the lively discussion. A few things for clarification.

The add-ons were born as a way to write the SDL driver without disturbing core development. Extending it to support widgets, modules, Fluid, and test apps seems like a natural extension.

The add-on is meant to give a bigger addition time to ripen before it is added to the core. That's all. It's meant to remove the support burden from the team while still making it as easy as possible for users to link the add-on. For SDL, experience has shown that this is really important, or we will drag unfinished code around in the core.

I suggested this for Native Input to give users a chance to thoroughly test the code before we add it to the core. By no means do I want to block it from being part of the core. I think it is a great addition, and it should be part of FLTK, but the code should already behave well and be tested by then. In this particular case, I would hope that Mohammed integrates the code into his projects for testing and will give Manolo the feedback he needs to make it perfect.

Yes, there is sometimes no sharp border between an add-on and changes to the core. I don't see that as a conflict: Manolo's change to the core for example is not harmful, and allows other native widgets. So it should be in the core anyway. Same with Fl_Group:: on_insert, on_move, and on_remove. These were written to support Flex and Grid, but are just as useful for Fl_Scroll and others.

I am with other projects for the next two week, but I will keep FLTK in mind, and I hope to get back to full speed by the mid of June.

 - Matthias

[melcher....@googlemail.com]

Thank you, Gonzalo. I will hopefully have a little bit of time tonight or tomorrow.

[Gonzalo Garramuño]

Thanks to you, Matthias!  BTW, the Vulkan drivers are a basic
framework.  I did not add any built-in classes to it as there are other
frameworks for that, so it is a bare skeleton framework, like the one
you get for OpenGL3.

On 5/20/25 9:07 AM, 'melcher....@googlemail.com' via fltk.coredev wrote:
> Thank you, Gonzalo. I will hopefully have a little bit of time tonight
> or tomorrow.

--
Gonzalo Garramuño
ggar...@gmail.com

[Manolo]

Le mardi 20 mai 2025 à 14:05:42 UTC+2, melcher....@googlemail.com a écrit :

add-ons are not completely thought out yet. This is just a tech demo, but SDL and Native_Input would be great starting point.

 

OK. I have committed to FLTK master (7347d6e) the small change necessary to allow adding class Fl_Native_Input as an addon.

Matthias: could you, please, push the small attached V4 patch to your core_addons branch? I will then create a git repo for

Fl_Native_Input as an FLTK addon candidate. TIA.

[Manolo]

Matthias: there's now a new github repository https://github.com/ManoloFLTK/Fl_Native_Input containing

class Fl_Native_Input in the form of an FLTK addon. You're invited to accept being allowed to commit changes there.

[Manolo]

Le mercredi 21 mai 2025 à 09:58:19 UTC+2, Manolo a écrit :

Matthias: there's now a new github repository https://github.com/ManoloFLTK/Fl_Native_Input containing

class Fl_Native_Input in the form of an FLTK addon.

Writing the README  of this new repo, I realize that addons also need a way to extend the FLTK documentation.

[Albrecht Schlosser]

I'm aware of this, and ISTR that I mentioned this, but maybe off-list with Matthias. I'll take care of this later, it should be pretty simple to integrate, w/o more additions to the user's addon code.

Thanks for your Fl_Native_Input repo, README.md looks good (code not yet tested). I suggest to write a note that this kind of addon is still experimental, for development only, and could be changed at any time.