C++ wrapper and some notes

[ragsaq]

Nice project! I was experimenting with the examples and started writing some C++ wrapper classes, similar to WTL (http://wtl.sourceforge.net/)

I have a fork with my changes and a new hello world C++ example: https://github.com/ragsaq/nappgui_src

My suggestions are:

• try and refactor the CMakeLists.txt so that the includes use #include <header> instead of #include "header"
• try and get the library included in vcpkg: https://github.com/microsoft/vcpkg
• put all includes in a nappgui folder, to avoid conflicts: #include <nappgui/gui.hxx>
• use editorconfig (https://editorconfig.org/) or clang-format. some of the files have mixed tabs/spaces. it would help to keep it consistent and would help contributors to use the same style.

once the library is included in vcpkg my C++ wrappers would integrate better (right now, I just copied the headers to the same folders)

the hello world example I did compiles to around the same size to the C API. each class just stores a pointer, so it's cheap to copy by value and wrap existing pointers/interface with the C API.

[frang75]

Hi @ragsaq !
Thank you very much for your contributions. I am currently developing version 1.3 of NAppGUI, which includes some refactoring of CMakeLists.txt to work with dynamic libraries. The use of clangformat will be provided. I will study the grouping of headers too.

We are in contact!

[SamuelMarks]

@ragsaq I'm happy to help on the vcpkg side. @frang75 I'm working on a PR for you to add Clang support; now that 1.3.0 is out.

[ragsaq]

Hi @frang75, what is the best way to use nappGui without adding our project to the demo folder?

I want to do a project where I can write a cmake project like this:

cmake_minimum_required(VERSION 3.12.4 FATAL_ERROR)

project(HelloCpp)

# do something like this?
add_subdirectory(nappgui_src)

# alternatively, write a findNAppGUI cmake module so we can do this
# find_package(NAppGUI REQUIRED)

set(SOURCE_FILES
    src/Main.cpp
    src/Example.cpp
    src/Example.h
)

add_executable(${PROJECT_NAME} ${SOURCE_FILES})

target_include_directories(${PROJECT_NAME} PRIVATE src ${NAppGUI_INCLUDES})
target_link_libraries(${PROJECT_NAME} PRIVATE ${NAppGUI_LIBRARIES})

set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD 20)
set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD_REQUIRED ON)

Is this currently possible? I know there are extra steps for the icons, but can you provide an example where we have more control of the CMakeLists.txt?

The reason I suggested integrating into vcpkg is so that something like the above would be possible, but I'm fine with having nappgui as a git submodule or as a sub directory.

[frang75]

Hi @ragsaq!

At the moment, the best solution is:

1. Build and install NAppGUI
   https://nappgui.com/en/guide/build.html#h1

cmake -S ./src -B ./build
cmake --build ./build --config Debug
cmake --install ./build --prefix ./install --config Debug

2. In your CMakeLists.txt

set(NAPPGUI_HOME "/path/to/install/dir")
set(NAPPGUI_LIBS "sewer;osbs;core;geom2d;draw2d;osgui;gui;inet)
target_link_directories(${PROJECT_NAME} "${NAPPGUI_HOME}/platform/config")

foreach(lib ${NAPPGUI_LIBS})
   target_include_directories(${PROJECT_NAME} PRIVATE ${NAPPGUI_HOME}/inc/${lib})
   target_link_libraries(${PROJECT_NAME} ${lib})
endforeach()

This process will be simplified en NAppGUI 1.4:

• Unify include directories (See issue organize public headers into a single include directory #54)
• Add support for CMake find_package()
• Add support for use NAppGUI CMake modules in external projects (e.g.: nap_desktop_application will do all the extra stuff (icons, resources, etc).

[ragsaq]

Hi @frang75,

I tested the last commit to see how the new cmake is.

nappgui install creates:

• bin
• cmake
• inc
• lib
• prj

I want to get nappgui integrated into vcpkg so that I can mix it with other libraries.
vcpkg uses this folder structure:

• bin
• debug
  • bin
  • lib
• include
• lib
• share - cmake files go here under share/nappgui
• tools - the nrc.exe program goes here under /nappgui/nrc.exe

I copy pasted the install output into these folders to see if I could get it working with vcpkg.

1> [CMake] CMake Error at C:/vcpkg/installed/x64-windows/share/nappgui/nappgui-targets.cmake:148 (message):
1> [CMake]   The imported target "nappgui::sewer" references the file
1> [CMake] 
1> [CMake]      "C:/vcpkg/installed/x64-windows/share/lib/sewer.lib"

It's going 1 folder up because that's where nappgui expects the lib folder to be. Is it possible to update the cmake scripts so that we can specify the names of the include, cmake and prj folders? I want to mimic the same folders used by vcpkg so I can copy paste the files in there and get it working.

An even better solution would be to work on an install script for vcpkg and submit it to the vcpkg repository by the time 1.4 is released.

[frang75]

Hi @ragsaq!

I think a good solution could be include a CMake parameter for installation format. In this way:

cmake -S . -B build -DCMAKE_INSTALL=VCPKG
cmake --build build  ....
cmake --install build ....

If its ok for you, I will add a task for NAppGUI 1.4.1

[ragsaq]

That's fine. The folder structure that vcpkg uses is the same that linux uses.

see /usr/*** and /usr/local/*** and you will find the same names.

[frang75]

I will follow this guide: https://learn.microsoft.com/en-us/vcpkg/reference/installation-tree-layout

[SamuelMarks]

Great. If you need any help @ tag me or email samuel [ a t ] offscale.io

I'm available to code-contribute.

(I'm super keen on getting this to work well with CMake and vcpkg, so I can then wrap it up in dozens of higher-level programming languages. And so, down the line, I can code-generate small cross-platform GUIs from JSON files. Long-term feature goal: WebAssembly support.)

[frang75]

Hi @SamuelMarks! It will be useful for me to get same (tree/ls/dir) over a real vcpkg package. In order see how files are stored in a real package and implement the changes in CMake well.

It sounds soo interesting your wrapper proposal. I will try to get the vcpkg support asap.

[SamuelMarks]

@frang75 Great to hear!

Ok, so if I had the power, I would lean on your existing modularity to create the following; taking @ragsaq 's namespace suggestion. Each "thing" in bold can be a shared library, but with some config & cmake hacks you can amalgamate so you have no size gain in final binary/lib.

• core:
  • #include <napp_core/core.h>
  • …
• draw2d:
  • #include <napp_draw2d/draw.h>
  • …
• geom2d:
  • #include <napp_geom2d/pol2d.h>
  • …
• gui:
  • #include <nappgui/button.h>
  • …
• inet:
  • #include <napp_inet/inet.h>
  • …
• nappgui.h:
  • #include <nappgui/nappgui.h>
  • …
• osapp:
  • #include <napp_osapp/osapp.h>
  • …
• osbs:
  • #include <napp_osbs/osbs.h>
  • …
• osgui:
  • #include <napp_osgui/osgui.h>
  • …
• sewer:
  • #include <napp_sewer/sewer.h>
  • …

---

As for sewer itself, I expect that'll be a big source of language-wrapping (FFI) issues. Not sure the best resolution here but just wanted to note this.

---

WebAssembly wise, GTK+3 does have broadway but would require a lot of work to get the WebSocket to connect to a WASMified daemon (of X; I guess). Alternatively can run an entire OS in the browser; but that would be an even greater overhead + slow to launch.

---

Now; to connect two of the problems: the multiple [9!] shared libraries concept + FFI; this would greatly simplify creating and testing NAppGUI wrappers by porting each of the 9 libraries separately (yes yes I know there is an order of the porting due to dependencies). It would also enable some components to be used without a GUI.

---

Anyway on the vcpkg side would heavily recommend splitting up NAppGUI into as many separate vcpkg [cmake] package as possible. If you need a hand just message and I'll get portin'

(otherwise watching keenly)