Hello everyone,

I know this project for a long time. I always thought of it as a good project, but not sure why it does not get used more, compared to, let us say, wxWidgets.

So here I have some questions:

1. For a Mac/Windows/Linux desktop app, does Ultimate++ fit well? I just want to use the GUI part, mainly.

2. In case I need to add other external dependencies, an sqlite orm or sqlpp11 for example and others, and since I use Meson for projects, will the package system get in the way for adding/removing dependencies? I want to have meson invocation as my top-level command, use theIDE for layout creation and have everything else run from Meson. I will not use TheIDE for anything else, since I use CLion mostly.

3. Can I streamline my layouts from the GUI into my build system or I have to stick in some way to TheIDE?

4. How well tested is Ultimate++ in Windows/Mac/Linux?

5. Is it possible to show/embed OpenGL and the like?

6. What are your perceived advantages/disadvantages compared to WxWidgets, limited to desktop app development for GUI only? I do
not care about any other thing such as sockets or db access, since I will be using other projects for that.

Hello Mirek,

Thanks for your prompt reply. I gave it a small try yesterday to U++ + TheIDE and the feelings are quite good so far. It looks like it is working well and it is battle tested.

It is true that it is not native rendering, but for my purposes it will not make a big difference (it is mainly for internal tooling).

1. What would be the effort involved (maybe man-hours?) in, let us say, have Meson wraps for the GUI part of U++?
https://mesonbuild.com/Wrap-dependency-system-manual.html

If you are not familiar with Meson wraps, these are basically overlays (patched builds) + meson.build files written to be able to consume libraries as subprojects in a standard way, think of something like Conan. I would be interested in having something that can make use of Meson standard workflow and be able to consume U++. Conan would also be ok if there is more interest, since Conan can be used from both CMake and Meson AFAIK.

Why this workflow? Basically because I already use emacs + lsp and CLion for code completion.
I would still use TheIDe as the layout designer. I am really impressed that it worked so well. U++ looks like polished and the API nicer to use than wxWidgets, since everything ends up embedded in normal C++, even layouts.

As something out of my reach now, I think that if you have few resources, and unless you are under some kind of restriction, it would be nice to make U++ consumable by CMake + Meson. The library is all worth. The missing part would be a layout designer out of TheIDE. Nowadays IDEs have a really good completion engine via compile_commands.json and/or CMake but it seems that U++ is locked down under theIDE. This would free resources to focus on:

1. integrating with Conan to be able to consume from CMake/Meson --> this could bring new users
2. free from TheIde maintainance, unless it has reasons to exist still. Nowadays there are really powerful IDEs (the layout designer should be kept somewhere, as a plugin for other software or from theIde anyway).

I would be interested in porting U++, in a modular way to be consumed by Meson (Conan is ok, so Meson + CMake is viable). Thank you.

1. What would be the effort involved (maybe man-hours?) in, let us say, have Meson wraps for the GUI part of U++?
https://mesonbuild.com/Wrap-dependency-system-manual.html

Hello again Mirek,

I did not know all the links. That is exactly what I need in order to prepare packages, I think.

I have little time to invest, hence my question for the man-hours effort. I will try some experiment but I cannot commit dates yet, I will keep in touch if I have something to show, and be sure that if I have, I will package it conveniently for others to be able to use it.


The best return on investment is to prepare a Conan recipe to be able to consume U++ (at least the GUI subset and the dependencies it drags) from CMake/Meson.


Reasons to choose this strategy of Conan packaging (mentioned in previous post), but I repeat (and add) here:

- it does not need changes to the build system (or it would need minimal changes, if it does).
- it does not need additional Meson build system maintainance, only a recipe on top of the existing build system.
- it makes things available in CMake/Meson and even MsBuild/autotools (modulo bugs) because Conan tries to integrate with all of those
and, as far as my knowledge goes, tries to be build-system agnostic for the ones it has no integration with.

Good to know.

But I guess that in order to draw in Linux/Windows/Mac it will need additional dependencies to link against (OpenGL/Cocoa/Whatever).


So you are basically suggesting that it is maybe better to write the build files directly in another build system? It is a possibility if that is not difficult.


1. do a port to Meson.
2. compile and create a conan recipe from the new Meson build system.

What I wonder is that if U++ developers (I assume you are one of them) keep using the assemblies/packages/nests, etc. the "U++ way", Meson build system would get out of sync.

This would create maintainance burden, that is why I was thinking of using what is updated by developers directly.

Another possibility is adopt a more mainstream build system (CMake/Meson come to my mind, I have a strong preference for Meson) and provide Conan packages to consume by any other build system. But this, as far as I understand, makes TheIDE packaging system "obsolete" in the sense that TheIDE consumes, as of today, the packages in the format expected by TheIDE, so if some package is added, what happens to that from the point of view of availability for consumers from CMake/Meson/MsBuild/Autotools/Whatever?

FWIW my own personal use would be to use a mainstream IDE (CLion) or Emacs, a more mainstream build system and the layout designer from TheIDE.

What do you think?