GUI Builder for MUI

[Wajinn]

Would be nice if there was a GUI Builder for MUI. Might be something to consider.

[malisipi]

I'm sorry to announce MUI will maintenance-only mode since you are using the library is long time. However if you need to have bugfix or basic features, I will still implement it.

I also want to implement the feature however when I developing MUI, I made bad decisions.

• MUI' source code have come so complex that I can hardly create new things without breaking legacy features.
• Since bad widget struct decisions it uses more memory than excepted.
• Bad event handlers, I don't know why I placed in one place instead of separating.
• Poorly supported third-party widgets.
• No layout support, so you cannot use grid/flex (and other good) layouts. (I may implement fake layouts with frame however it'll new other hack that makes developing much harder)
• Frame widgets is not actually a parent (not collapsing other widgets), it was leaked to anchor system. Anchor system is too complex to develop new things.
• Built-in dialogs is actually a hell. They're hijacking the main layout and replace it with widget system.
• I was developed some menu-only areas (since I have no layout engine), it also really harmed the anchor system.

And there're a lot of issues that swept under the rug. I may still work on MUI and replace chunks of the library however I lost my interest a little with it. Maybe you understand why there're no new commit in the recent past.

MUI needs a rewrite some parts to solve this issues however I guess creating new library from scratch should more easy. So, I decided to maintain MUI without new features.

Thanks for your support especially since you are supporting the library from start.

And I will implement cross-platform windowing framework, software (my custom implementation and maybe Cairo) and hardware accelerated (OpenGL in first, maybe Vulkan support in future) UI. And I implement a interface to create custom backends easily (like Nuklear did).
I have some drafts about it. It is supporting Windows/Linux (Wayland) and Haiku (and will support other platforms including Web in future) atm. I am currently working on ui engine, multi-window handling and events hooks.

60 frame per second that rendered on software with 0.8% usage of CPU and 1.9 MiB usage of memory as unoptimized build is looking promising for me.

In future, I may backport the windowing engine to V as GG/Sokol replacement (like that I made in MFB). And maybe add a compability layer-like thing to support MUI code.

If you want to see the new library, I can tag if you want when I released.

As last, thank you for all of your support. ❤️

[tzSharing]

The library is no longer working properly with the latest version v, and all examples do not work.
Error message that has appeared:

builder error: cannot import module "malisipi.mui" (not found)
    1 | import malisipi.mui as m

...
builder error: 'commdlg.h' not found
...

...
Error 10057 sending data to server (1)
Error performing handshake
Error 10057 sending data to server (1)
Error performing handshake
Error 10057 sending data to server (1)
Error performing handshake
^C

Also looking forward to your new gui library.

[malisipi]

The commdlg.h is not bundled with V's TCC, so you need to install full WinAPI of TCC or use alternative compiler (like GCC).
You can find more information about how to install full WinAPI for TCC in "How to use TCC on Windows" title that placed under FAQ section

The library has a little warning (about latest const changes) that should be fixed until 2025. (I will fix it soon). There're no error or warning about the library except that. It should build fine with latest V.

Also looking forward to your new gui library.

I'm glad to hear.

[tzSharing]

I retested with the gcc compiler and found that the examples in the examples directory still did not work, as shown in the figure:

If you change it to "import mui as m" or "import mui", it will work normally.

import mui

mut window:=mui.create(mui.WindowConfig{ title:"Labels - MUI Example", height:400, width:400 })
window.button(mui.Widget{ id:"button", x: 20, y:50, text:"Button" })
window.run()

But there is another problem, which is that it runs very, very slowly, and the above code takes about 3 minutes to appear in the UI interface.

C:\Users\TZ\Desktop>v -cc gcc run main.v
C:/Users/TZ/.vmodules/mui/screen_reader_windows.c.v:9:1: warning: const () groups will be an error after 2025-01-01 (`v fmt -w source.v` will fix that for you)
    7 | fn C.mui_does_narrator_alive() bool
    8 |
    9 | const(
      | ~~~~~
   10 |     narrator_vbs=os.temp_dir()+"/mui_speak.vbs"
   11 | )
Unhandled Exception 0xC0000005
print_backtrace_skipping_top_frames is not implemented

C:\Users\TZ\Desktop>

[malisipi]

If you change it to "import mui as m" or "import mui", it will work normally.

Sometimes V installs the library to ~/.vmodules/mui (without malisipi). How you installed the library? The command (v install malisipi.mui) should not create the confusion (should install to ~/.vmodules/malisipi/mui).

But there is another problem, which is that it runs very, very slowly, and the above code takes about 3 minutes to appear in the UI interface.

GCC is slow on Windows. You may try using TCC after installing full WinAPI.

[tzSharing]

How you installed the library?

I directly copied "v install https://github.com/malisipi/mui" in your "readme" document to install。This is the path "C:\ Users\ TZ\ .vmodules\ mui" after my installation.

[malisipi]

I directly copied "v install https://github.com/malisipi/mui" in your "readme" document to install。This is the path "C:\ Users\ TZ\ .vmodules\ mui" after my installation.

I am pretty sure about V have changed some behavior about package manager. Legacy behavior of package manager was installing modules as ~/.vmodules/<Owner Name>/<Package Name>. If V installs the library to directly .vmodules, using import mui shouldn't make problem. You might need to change import malisipi.mui lines to import mui in your project to avoid compile errors.

[Wajinn]

I'm sorry to announce MUI will maintenance-only mode since you are using the library is long time. However if you need to have bugfix or basic features, I will still implement it.

I also want to implement the feature however when I developing MUI, I made bad decisions.

And there're a lot of issues that swept under the rug. I may still work on MUI and replace chunks of the library however I lost my interest a little with it. Maybe you understand why there're no new commit in the recent past.

@malisipi

I think it would be great, if you would reconsider putting it into maintenance-only, and still work on MUI from time to time or per user requests. As you will be doing bugfixes and some basic features, you and others may yet replace large chunks of it, which means it can still evolve. That's as much as could be asked for any project.

It is quite common to look back and see other ways something can be done, but the new direction may not always be better, or at least the core concept and idea of the original might have been better than realized.

Your anchoring system, concepts of adding widgets, space saving for writing code, ease in which GUIs can be created, etc... Are in my opinion, excellent, and can be seen as improvements in comparison to VUI.

As a user, I've quite enjoyed experimenting with MUI, and seeing its progress. The idea of it, is wonderful for V, particularly as a young language. That others appreciated it, is also indicated by the stars it has received.

[Wajinn]

@tzSharing

I've used MUI on both Windows (8.1 and 11) and Linux without problem, with TCC. Ran some test apps with no issue, on V 0.4.7 c0f7244. Additionally, used MUI with some experimental Android apps.

For Windows, to get it working with TCC, downloaded the zip named winapi-full-for-0.9.27, from download-mirror.savannah.gnu.org/releases/tinycc/. However, used an alternate compile of v -cc tcc -cflags "-isystem folder\winapi\". Wasn't forced to use GCC.

On Linux (Mint 22), had no issues with running MUI examples directly (that I can recall), though would sometimes get a warning about "xapp-gtk3-module" (depending on example or GUI built).

Import line used for MUI is- import malisipi.mui as m.
Per https://vpm.vlang.io/packages/malisipi.mui, the install command is, v install malisipi.mui as oppose to
v install https://github.com/malisipi/mui, so possibly why different directory.

[malisipi]

I think it would be great, if you would reconsider putting it into maintenance-only, and still work on MUI from time to time or per user requests. As you will be doing bugfixes and some basic features, you and others may yet replace large chunks of it, which means it can still evolve. That's as much as could be asked for any project.

I may continue to developing MUI however widget system is requiring so memory since I am using a map with union (you can look to image that placed below). Unions is not memory effective especially if types is very different length (however i don't know while developing the library, I learn a lot of things with it). I need to change that to make MUI more lightweight however this change will broke nearly every application. If you think it will worth, i may prototype new MUI version. Most of other changes is internal so they're shouldn't break much of application. In my free-time, I may work on other internal changes.

Your anchoring system, concepts of adding widgets, space saving for writing code, ease in which GUIs can be created, etc... Are in my opinion, excellent, and can be seen as improvements in comparison to VUI.

If my other UI-kit draft works fine, I will support V library. The other library (if I finish) will have still anchoring system, basic widgets. Much of things will not be so different than MUI. Also will have powerful font handling, grid/flex like layouts, software-rendering support, perfect third-party widget support (internal widgets will use same API with third-party support (MUI have different event-handling system and third-party widgets cannot have same functionality)). You can use emojies and material font in text easily. This will help native-like looking Android UIs.

As a user, I've quite enjoyed experimenting with MUI, and seeing its progress. The idea of it, is wonderful for V, particularly as a young language. That others appreciated it, is also indicated by the stars it has received.

I also enjoyed as a developer the library and V language. I am so glad you are sharing the feeling with me.

[Wajinn]

I may continue to developing MUI however widget system is requiring so memory since I am using a map with union... I learn a lot of things with it). I need to change that to make MUI more lightweight however this change will broke nearly every application.

Such greater memory efficiency would be worth breaking changes, and nearly everyone would understand the necessity, in my opinion. V is also a language in beta, most users would understand the experimental or stability side of the equation.

If you think it will worth, i may prototype new MUI version. Most of other changes is internal so they're shouldn't break much of application. In my free-time, I may work on other internal changes.

The thing about MUI, is it being mostly built on V's existing gg and gx modules (based on sokol). These are technologies already integrated and invested in by the V language and team. There is no friction about its usage and it leaves a greater possibility of contributions or ability to fork by those of the V community. Hopefully, this other perspective is something worthy to consider.

If my other UI-kit draft works fine, I will support V library. The other library (if I finish) will have still anchoring system, basic widgets. Much of things will not be so different than MUI. Also will have powerful font handling, grid/flex like layouts, software-rendering support, perfect third-party widget support (internal widgets will use same API with third-party support (MUI have different event-handling system and third-party widgets cannot have same functionality)). You can use emojies and material font in text easily. This will help native-like looking Android UIs.

The strong V support and that it will be similar to MUI is sure to be greatly appreciated. This looks to be an exciting direction and project. The great thing, that all user can be thankful for, is that there is both.