search

frang75 / nappgui_src

SDK for building cross-platform desktop apps in ANSI-C
https://www.nappgui.com
MIT License
446 stars 44 forks source link

C++ wrapper and some notes #11

Open ragsaq opened 2 years ago

ragsaq commented 2 years ago

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:

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 commented 2 years ago

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 commented 1 year ago

@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 commented 9 months ago

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 commented 9 months ago

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:

ragsaq commented 5 months ago

Hi @frang75,

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

nappgui install creates:

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

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

SamuelMarks commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

@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.

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)