Single Shared library release option

[ragsaq]

Hello,

Is it possible to add an option to produce a single shared library (.dll, .so) with all the exported functions?

On a related subject, What would be the minimum number of libraries required just for GUI? (no string manipulation, no array helper classes, no json encoding, no net).

Imagine we wanted to create a C FFI wrapper for the GUI part of nappgui. Most languages wrapping nappgui have better string handling than C, as well as json parsers, net libs, ...

I noticed the individual libraries grew in size compared to the first versions. I think having an option to output a single shared library might reduce the size by sharing some of the code being copied multiple times in each shared library.

Looking at the GUI APIs, they don't take data structures as parameters that need to be created by one of the underlying libraries (sewer, ...). it's mostly passing bool, float, int, UTF8 char* pointers and other GUI class pointers. for a wrapper library, this means we don't need to use these APIs that are useful for C users but redundant for higher level classes that support C FFI.

Do you see any problem with any of the GUI APIs that would make it difficult to use the GUI part of nappGUI without using the base helper libraries?

[frang75]

Hi @ragsaq!

If you only need the GUI API, you can omit certain libraries like encode, inet, or ogl3d (no JSON, no HTTP, etc.).

What does "Just for GUI" mean? Does it mean you can't use Image objects (draw2d)? Or the parametric drawing API (draw2d) in CustomView? Does it mean you can't take advantage of Data Binding (core)? Or 2d transforms in drawings (geom2d)?

The NAppGUI stack marked in red is required for the GUI components. Even if the API is hidden, the binaries will still be present. Making the API of intermediate libraries available is very helpful in "Pure C" projects.

NAppGUI was not designed to facilitate bindings to other languages. It was designed as a robust platform for creating C applications.

Using NAppGUI in other languages ​​will be much easier when the NAppGUI-Forms API, a complement to NAppGUI-Designer, is ready. This API will be very small and easily portable since window composition will be kept out of the code.

Designer preview
#246

[ragsaq]

Just the GUI means what you answered. only libraries that have a use in GUI (draw2d and opengl, to me, fit into this category). but also if I'm not using those (because it's just a simple window with some buttons), can we remove them, or are they already interconnected?

The idea with wrapper libraries is to do all the UI + code logic in a separate language and just use C FFI to call window_create, text_set..

The NAppGUI-Forms API will be helpful but how will it help integrating with other languages? Can you share a preview of what the API will look like? will it be loading text files describing the UI, making it easier to use in other languages because we only need to "load" text for the UI?