m2libui – Libui wrapper (Cross-Platform Native UI)

About Monkey 2 Forums Monkey 2 Projects m2libui – Libui wrapper (Cross-Platform Native UI)

This topic contains 28 replies, has 7 voices, and was last updated by  Hezkore 11 months, 4 weeks ago.

Viewing 15 posts - 1 through 15 (of 29 total)
  • Author
  • #13276


    m2irc is a libui library wrapper for Monkey2.
    It makes creating native UI elements, such as windows, buttons, sliders etc. a breeze.
    Notice that this wrapper is very unfinished and needs your help to be completed!

    GitHub: https://github.com/Hezkore/m2libui/
    Win Examples: http://hezkore.com/release/m2libui/

    * Download or Git Clone to your Monkey2 ‘Modules’ folder
    * Recompile module
    * Compile & run tests inside the ‘tests’ folder

    There are some issues and I’ve marked those with PROBLEM in the source and tests.
    I recommend reading those before doing anything else to avoid confusion!

    This only compiles on MSVC 2017 (32bit or 64bit) right now and you’ll need M2 1.1.09 or newer.
    It does not compile via MinGW, which is what M2 uses by default.
    (you should be using MSVC on Windows anyways as MinGW is super slow)
    You can probably get it working on MinGW with the right imports, so feel free to help.

    Imports for MacOS and Linux are not complete.
    I only have terminal Linux and no Mac setup at home, so I cannot do anything about that right now.
    Feel free to add those imports and I’ll include it in the official repo.



    Hey, now if this sees fruition, it will be an awesome addon.



    Here’s what I’ve got so far: https://github.com/Hezkore/m2libui
    And Windows executable: http://hezkore.com/release/m2libui/

    There are some problems with it, and I’ve clearly shown them in the code (Look for ' PROBLEM)
    So to clear up any confusion, read the ' PROBLEM and ' NOTICEin the code before you do anything!
    Those are also the parts I need help with.

    About 80% or so of the gadgets are there.
    Missing some ‘Font’ and ‘Color’ buttons.
    There are also some ‘Area’ Structs I haven’t quite figured out yet.
    But “actions”, like OnClickedetc. works.

    I think it needs another layer ontop of this (so we’re not calling raw Extern funcs) to be more user friendly.
    But yeah, it works pretty good and it’s getting there!
    Reminds me a bit of MaxGui.

    With a bit of work; I think it might just be what Monkey2 needs! 🙂



    Good finding!

    Some information regarding on how Monkey2 builds stuff, there are two ways, one is to build-everything-from-source situation and the other is to include the native shared libraries which are distributed with the final application. Consider these example for more inspiration:
    Example of having sources: monkey2\modules\chipmunk
    Example of having shared libraries (which deals with the multiplatform libraries): monkey2\modules\openal

    I don’t know about specifically the pros and cons of building either from source or from libraries. By default you would consider that building everything from source is the way to go, unless you literally can’t mess with the source such as dealing with protected (OS libraries) or proprietry (where you can’t use the source).

    Regarding some of your notes from github…


    DLL must be in Root dir (possible to integrate instead?)

    For doing such integration, there are third party tools to help with that, however monkey has either one way or the other. Search for: “pack exe with dll together”, you should see tools like “ExeBundler” etc… But this choice would be more of a matter according to how people want to ship the application.


    (Class uiControl) Should be a struct I guess? Is in C source…
    But classes (like buttons etc.) can’t extend structs…

    I don’t have enough knowledge about this but there various example how is done in the modules. Use AstroGrep (the application) and search these regular expressions, to see how to match a native datatype to the monkey datatype.

    Such an example can be this one: Class aiScene Extends Void=”const aiScene” (aiScene is a C struct in cexport.h)
    Where you have Monkey2 declare a class, but map it to a native struct, sweeeeet!



    Can you give us a quick ‘How to Start’ bit of help? i.e. Do I put it in my MX2 module folder or do I just include the mx2 file in a new project within monkey etc?



    Thanks @cocon I’ll do some exploring with this new information! 🙂

    @amon you should be able to just place it anywhere and compile/run the .monkey2 file, it’s the wrapper AND example in one file.
    Though you’ll probably have to be using M2 with MSVC (20017 I think?) and x64, since that’s what I compiled the libui lib for.
    Otherwise you’ll probably have to recompile libui yourself.
    That’s why I think it needs to be compiled with M2, so that it works like every other M2 module.



    Okay new info, but no progress sadly.

    Turns out you can compile libui into a static library.
    Which means there’s no need for a DLL, at the price of a slightly larger executable.
    I’ve tried doing it with MinGW-W64 and it does output a “.a” file.
    But importing it to Monkey2 doesn’t seem to work – https://pastebin.com/raw/iWH5bXVT
    For anyone wanting to do this, the process is:

    1. Grab libui
    2. Create a “build” folder in the libui root folder
    3. Make sure you’ve got MinGW-W64 installed
    4. Open CMD in your “build” folder and call cmake -DBUILD_SHARED_LIBS=OFF -G "MinGW Makefiles" ..
      (the -DBUILD_SHARED_LIBS=OFF line is what gets rid of the DLL)
    5. Then from CMD in the “build” folder again, call mingw32-make
      (you can call mingw32-make -j <number of CPU cores/threads> to compile faster)
    6. If everything went as it should, the “build/out” folder should now have some new files in it
      If not, continue to step 7
    7. It seems the code isn’t made for cmake to output for mingw (atleast not for my version), but you can just edit line 75 in “windows/CMakeLists.txt” to read resources.rc.obj instead of resources.rc.*
      Then just clear out your “build” folder and start from step 4 again

    I’ve also tried to make cmake output for MSVC (and 64bit in my case) as a static library.
    It seems to fail (says success 2 failed 1), and the error message is just garbage, but there’s a “.lib” and “.pbd” file output anyways.
    Tried importing the “.lib” to M2 but fails…
    Steps for that were:

    1. Grab libui
    2. Create a “build” folder in the libui root folder
    3. Make sure you’ve got MSVC 2017 installed
    4. Open CMD in your “build” folder and call cmake -DBUILD_SHARED_LIBS=OFF -G "Visual Studio 15 2017 Win64" ..
      (the -DBUILD_SHARED_LIBS=OFF line is what gets rid of the DLL)
    5. Open “ALL_BUILD.vcxproj” in your “build” folder
    6. Then I just right click the “ALL_BUILD” item in the solution explorer and select “Build”

    No matter what, I can’t get it to work as a static library.
    So I guess we’ll have to stick with the DLL for now?
    To compile the DLL, I just did the previous steps for MSVC but without “-DBUILD_SHARED_LIBS=OFF” with cmake.
    I’ve tried to get MinGW to output the DLL as well, but there’s an actual error saying libui doesn’t do that with MinGW right now, so you’ll have to use MSVC.

    That also means that this will only compile if you’re using M2 with MSVC! (which you should be anyways)

    And @cocon, doing something like Class uiControl Extends Void="const uiControl" does work.
    BUT! It makes things unable to be cast into other things.
    For example I’ve now got Class uiControl Extends Void="const uiControl" and Class uiWindow Extends Void="const uiWindow"
    uiWindow is really just extending uiControl in the C code, so I should be able to do things like uiControlShow( uiControl ) and put my window there, even though it’s a “uiWindow” and it wants a “uiControl”
    And that works with my old method of just extending it, but doing this new Extends Void="const uiWindow" method it tells me it can’t cast “uiWindow” into a “uiControl”
    So I’m reverting back to what I’ve got on GitHub.
    Still some casting issues with that (can only cast “down”?) like “uiControl” can’t seem to be cast into “uiWindow”
    But at least “uiWindow” can be cast down to “uiControl”

    So in the end, no progress has really been made.


    Mark Sibly


    Mark saves the day!
    It now compiles with Monkey and as a static library, so no DLL 🙂

    I’ve updated GitHub and the compiled example.
    A new problem has arisen though!
    The “modern” theme in Windows 10 isn’t being applied.

    This is how it looks now:

    This is how it looked with the DLL:

    I’ve Googled the issue and it appears there needs to be a manifest file.
    Looking into the issue…



    I tried this on MinGW, and it complained about some missing functions, like “RemoveWindowSubclass”
    I went ahead and looked those up and they seemed to be apart of “Comctl32.lib”
    So I added #Import "<libcomctl32.a>" and it does compile but when launched I get this error dialog:
    “The procedure entry point TaskDialog could not be located in the dynamic link library G:\code\monkey2\m2libui\src\m2libui.products\Windows\M2libui.exe.”

    I’m guessing it’s because Monkey2 uses 32bit MinGW?
    Or maybe it’s cause the wrong “Comctl32” is being used, as there seems to be multiple versions?

    I’ve also tried compiling this on Linux, but get:
    libui-master/unix/uipriv_unix.h:6:21: fatal error: gtk/gtk.h: No such file or directory
    #include <gtk/gtk.h>

    I tried “sudo apt install libgtk-3-dev” (and libgtk2.0-dev) but same error.



    Hi, when I used C# for some applications I had to use this function: Application.EnableVisualStyles() in order to have visual styles. Here is something mentioned about this: https://stackoverflow.com/questions/4308503/how-to-enable-visual-styles-without-a-manifest. I think that libui wants to instruct the linker on using the manifest file:

    I see that the linux GUI depends on GTK and it needs the GTK source (#include <gtk/gtk.h>), perhaps this means GTK library will have to be included as well along with it’s dependencies (like cairo for graphics and others). If it brings too much weight to the module, perhaps for just this special occasion Linux can rely on shared libraries instead.



    The EnableVisualStyles() function seems perfect!
    But I can’t really figure out how to add it to M2…

    “system” seems to be what it’s included in.
    But how do I get that into M2?


    But I’ve managed to get the manifest files to work.
    Compiled one for x86 and one for x64 so we should be okay with those.

    I’ve updated the source code as well.



    > I can’t really figure out how to add it to M2

    Perhaps windows has some sort of distinction between MinGW and MSVC? As a last resort you could consider these information if they are of any use. I will have a look as well just in case I figure out something.
    (search term: mingw windows.h visual styles)


    Perhaps only a small piece of C function (like WindowsEnableVisualStyles) would be created in C and then it be called only once in Monkey. That way the tremendous effort to do the work inside Monkey, where figuring out the datatype conversions would take more time.



    @cocon It’s fine, I’m using the manifest files and it’s working on both x86 and x64 Windows.
    They make sure the visual themes are applied.


    The newest commit has (I believe) all gadgets wrapped.
    And I’ve fixed a lot of the old issues.

    There are some issues left that I’d like to try and solve now.
    One is uiTabAppend crashing.
    And also uiFontButton along with uiColorButton crashing the app when clicked.

    Other than that, I think things are mostly working as intended.

    Perhaps I’ll try and wrap the drawing methods at some point.
    Which lets you draw 2D stuff to the “Area” control.




Viewing 15 posts - 1 through 15 (of 29 total)

You must be logged in to reply to this topic.