LCUI – A small C library for building user interfaces with XML and CSS | Hacker News Reader

LCUI – A small C library for building user interfaces with XML and CSS

github.com

335 pointsausjke127 comments

Cool. Recent anecdote, I've been looking into ways to setup a semi-complex GUI around an OpenGL canvas. Buttons, menus, styling, scrolling, all that jazz.

I looked into existing options like QT, but found them to be extremely large and full of things I didn't need. I don't blame them for that; they're designed to support a huge range of inputs and have a lot of associated assets. I've also heard that it's possible to build custom 'lite' distributions. But it looked imposing enough to get into as a user that I was about ready to just write buttons and dropdowns and scroll bars in raw OpenGL. It was gonna be messy.

But then, I decided to just use a web browser.

And it was so easy. You can have an OpenGL ES 3 canvas surrounded by UI elements which don't look horrendous, with just an hour or two of setup. The whole thing can respond very gracefully to things like window resizing without much added effort. It is very easy to pass values between the GL context and the UI elements. It is trivial to save/load configurations with any sort of web framework.

Something that could offer similar usability in C definitely sounds exciting. I mean, I complained about QT being bloated, but so is a modern web browser. Most people just happen to already have one pre-configured, and most developers just happen to already be familiar with how one works.

Came across this yesterday:

Nuklear

This is a minimal state immediate mode graphical user interface toolkit written in ANSI C and licensed under public domain.

https://github.com/vurtun/nuklear

https://github.com/billsix/pyNuklear

Neat, thanks for sharing!

(edit) Wow, that looks way more powerful and embeddable than I was expecting. I'll have to give it a try.

Lol I was just about to repost my pyNuklear link. Regular nuklear is fantastic if you like C, which I do too :-).

We bumped into each other yesterday on the PyQt thread, and the grandparent seemed to be asking for the same thing. ;-)

https://github.com/zacharycarter/nuklear-nim/

Nim's syntax is very python like, but it's statically typed and compiles to C. Best of both worlds.

This is a good one too: https://github.com/ocornut/imgui

Seconding Dear Imgui, it's a great small library that has a ton of bindings available. Highly recommend Flix01's addons branch https://github.com/Flix01/imgui/wiki/ImGui-Addons-Branch-Hom...

Do you have an idea why this is not just merged back into 'regular' Imgui? I like the look of some of the addons, but by having this fork no Imgui bindings will support them.

imgui is a C++ libarary, which is why I chose nuklear being a C library written in C89. Just a small distinction, but some people are working in just C.

What did you use in the browser for UI and GL?

Pretty much just CSS and Bootstrap for things like nested menus. The normal input/a tags are pretty versatile, but Bootstrap does also help a lot.

I wonder what's the point of people touting about reusable code is when as soon as a set of 71 distinct libraries, most of them optional, (disclaimer: ls /usr/lib/libQt5*.so | wc -l) full of reusable code with a common API and coding conventions is not considered since it's apparently "too much".

Do you really prefer to learn a different API and library for every different part of your app ?

You should look into the sibling comments (nuklear, DearImgui, Casey Muratori), and try doing a simple toolkit for your own use. Then you will understand the difference. Qt is huge, and opinionated, and very difficult to control.

Qt is not focused on being a useful tool that you simply put next to your other modules, and plays nice when it's called. Qt wants to be a framework that drives your application. Qt expects you to speak in its own datatypes, not type-agnostic flat memory.

I mean, I've only used Qt very briefly, but how would I, for example, use Qt widget functionality to add a nice menu to my existing 3d game? It's uncommon enough that I can't easily find how to do it, and I wouldn't be surprised if it's next to impossible.

Fully agreed.

With Qt, Qt itself is the app, your code is just a plug-in. :-)

> I mean, I've only used Qt very briefly, but how would I, for example, use Qt widget functionality to add a nice menu to my existing 3d game?

I don't think that would be very desirable: Qt widgets are made to mimick the desktop OS themes... I doubt you want these in games. However, you could use QtQuick, here is for instance an example of integration with a 3d game engine: https://github.com/MaxSavenkov/nya_qt And another which integrates with the creative coding framework openFrameworks: https://github.com/aklevy/ofUnderQml ; doing for instance a HUD à la Scaleform with these is fairly realistic given the nice scene graph of QtQuick

Both seem to integrate an existing thing into the QML runtime by using Qt-defined hooks and subclassing Qt-defined classes. I can't really understand it or map out the control flow. There's lots of magic involved.

I don't think Qt, or QML for that matter, is flexible enough to fit into an existing, complex architecture with its own concepts and data structures. What I need is something that I can feed my own inputs through a simple plain data API, and get back plain data results that I can further process, preferably without any other side effects.

I don't want to structure my code heavily towards a framework. I don't think that is flexible or maintainable. I don't want to use a framework that takes over the process and the processes' I/O and the main loop, and that I can't extend without plugging hard to maintain code into lots of magical sockets. Which also only gets you so far; you'll never be able to bend the framework to do quite what you need; and you'll waste hours and hours reading documentation and browsing obscure github projects to find clues how to bend it a little more. And of course, these clues will be invalid in the next version. This is my experience with Qt at least (as well as with CMake, for example).

> I don't think Qt, or QML for that matter, is flexible enough to fit into an existing, complex architecture with its own concepts and data structures. What I need is something that I can feed my own inputs through a simple plain data API, and get back plain data results that I can further process, preferably without any other side effects.

What makes you think you can't ? Pass input events to the relevant Qt objects once per frame, tell it to render to an FBO and do whatever you want with the result.

> through a simple plain data API,

I'm working on large app made in Qt and the number of times where I call Qt functions taking Qt containers as arguments, eg QList or QVectors can be counted on the fingers of one hand. What do you have in mind for instance ?

> I don't think that is flexible or maintainable.

The number of reliable large applications based on frameworks certainly shows otherwise. Even in video games, could you cite more than five big AAA game in the last decade that were not based on UDK, CryEngine and its variants, or Unity3D ?

> I don't want to use a framework that takes over the process and the processes' I/O and the main loop,

That's what I was referring to when I mentioned code reusability. Event loops & IO have been abstracted away for a long time, yet people refuse to use these abstractions for reasons unknown to me and keep reinventing game loops in every game, instead of just referring to some lifecycle schema like Unity3D's (https://docs.unity3d.com/Manual/ExecutionOrder.html) or Qt's (http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html). These schemas did not come out of thin air, but of years of experimenting on different categories of apps and seeing what works and what does not ; 99% of the time you don't need to deviate from them, especially if you're not making an AAA.

> This is my experience with Qt at least (as well as with CMake, for example).

I feel like we're living in a parallel world. Qt maintains API and ABI compatibility for major versions, the last breakage was in Qt 4 -> 5 transition 6 years ago. And a large part of the apps I use still have CMake 2.6 - 2.8 level buildscripts while we're at 3.10, and they still work as-is.

> What do you have in mind for instance?

Well I had to do a little dashboard application and the interfacing from C++ to QML was... laborious, to say the least. It was quite hard to find the right magic words to do seemingly simple things like getting a list of dropdown items over to QML. If you don't have to work with Qt containers most of the time, I figure you have good abstractions in place. (So you're not working directly with Qt after all?) I wanted to do that too, but my employer wasn't happy with me not using enough QStrings and QStringLists and what not.

> Even in video games, could you cite more than five big AAA game in the last decade that were not based on UDK, CryEngine and its variants, or Unity3D?

I don't play many games, and if AAA means "graphically impressive but possibly not a conceptual innovation", then my answer would be "no". I would be hard pressed to quote 5 AAA games at all. (I sometimes play FIFA on a friend's PS3 (yes it's dull), and here we have the first exception. Whatever)

However I happen to "know" that many Indie game developers prefer to control their own codebase, that they know in and out, and that they can cut and trim and slice and dice, to try out new ideas. (This includes more commonly known titles like Super Meat Boy, Braid, The Witness).

> keep reinventing game loops

Why should I not "reinvent" a game loop? It's a trivial thing to do. No big deal. I'd rather do it myself than starting with a big preconceived framework that starts with words like "Awake", "OnEnable", "OnLevelWasLoaded", "OnApplicationPause" (What's a level? Why would I have such a thing?).

> I feel like we're living in a parallel world.

I would like my applications to last much longer than 6 years. And I would really be surprised if there were not more problems. Regarding CMake, I wasted >20h in multiple attempts fighting an existing CMake build system including a tangled mess of CMake scripts. It's really hard to understand and maintain. The documentation is not good, it doesn't try to teach you the underlying conceptual models. I then decided to just put my build description in a python file and generate the build system myself. 3h until it first worked, very little maintenance afterwards. Plus, I now have the flexibility to easily add more facets as the system evolves, and to easily derive other useful dev tools from the python structures. (Small downside, would possibly have to write more build system generators if there were multiple supported platforms. But while CMake makes some of this a no-brainer, it's almost never just "now compile for this other platform", and other aspects to porting get relatively harder with CMake).

> Even in video games, could you cite more than five big AAA game in the last decade that were not based on UDK, CryEngine and its variants, or Unity3D?

It seems you are less informed than my first impression was. I did a few web searches, and the AAA titles using especially Unity seem to be far and far between. It's not good enough technically for top-notch performance (seems to require a garbage collector).

Also there are so many types of games that they cannot possibly supported by just two generic engines. For example, Open-World games need their own. Or military games like Call of Duty have their own. (And of course many Indie games have their own, as I said in the other comment).

Also most bigger publishers breed their own engines to save the fees for licencing a third party engine.

> For example, Open-World games need their own.

Bethesda games, generally open world, use an engine (https://en.wikipedia.org/wiki/Gamebryo for older games and https://en.wikipedia.org/wiki/Creation_Engine for most recent), they certainly don't go reimplementing it.

> Or military games like Call of Duty have their own.

No, they used the id engine and improved it over time.

> Also most bigger publishers breed their own engines to save the fees for licencing a third party engine.

Like ? for instance Bioware (as part of EA) uses Unreal engine. You mentioned FIFA games: they also use engines shared across a huge swath of games: https://en.wikipedia.org/wiki/Ignite_(game_engine) and https://en.wikipedia.org/wiki/Frostbite_(game_engine)

The only big release I know not using an engine shared across multiple game series is the recent Witcher games engine.

Modularity. In a project of mine, https://github.com/billsix/hurtbox, I switched from "dear imgui" to "nuklear" trivially. I imagine that switching a project from qt to gtk or wxwidgets would be a massive rewrite.

Curious to know why you switched?

Yeah I don't even bother with thinking about building desktop applications. User interfaces are over 9001 times easier and faster to build as web pages / pwas.

Is the browser really lighter weight than Qt?

I view this all as a huge step backwards. This is exactly why my glorified IRC client takes over a gigabyte to run.

The killer app is if this was all done at compile time. Use common web technologies to design the UI, translate that into lightweight GUI code.

A bit of a stretch, but you can use Electron (https://electronjs.org/) which ties to nodejs, and use nodejs to call out to C.

Or a webview using Webkit or IE11. There is a cross-platform wrapper in C99 [1]

[1]: https://github.com/zserge/webview

This is awesome, thanks for sharing !

I like this approach, I'm keen to try it too – is the project open source? Which browser engine did you use?

One advantage of this approach compared to the minimal UI libraries is that you can expect it to work well with a massive array of hardware – elements like scroll boxes should work seamlessly with touchscreens, apple trackpads and regular wheel mice, text input elements should respect the user's navigation key bindings. Accessibility features like voiceover should be supported. The downside is of course the weight of the browser engine compared to a tiny C library, however it'd be an interesting experiment to see how much bloat could be stripped out of a browser if you only care about a subset of features, i.e, WebGL can go, legacy layout modes can go etc

We're currently looking at pxCore / pxScene. It's a fairly small couple of libraries with a portable frame buffer layer (core) and hardware accelerated 2D scene graph (scene) with an optional JavaScript API (you can also just use C++ too).

> Something that could offer similar usability in C definitely sounds exciting

For painting, I have positive experience with this cross-platform C library: https://github.com/memononen/nanovg It’s tiny, has very few dependencies, and the performance is good even on relatively slow hardware like Broadcom or Mali embedded GPUs.

However, it lacks higher level stuff. There’s no layout, input handling, styles, controls, advanced typesetting, or animations.

Amusing.

> options like QT, but found them to be extremely large and full of things I didn't need

> But then, I decided to just use a web browser.

I'm a bit unclear, do you mean you fully switched to using a WebGL canvas with HTML-based controls? Or more like a browser-widget embedded in your application with HTML UI widgets, that somehow controls a separate OpenGL canvas?

The IUP C GUI library (for desktop apps) seems interesting too. Checked it out a bit. It's from the same University in Brazil as the Lua language, IIRC.

https://en.wikipedia.org/wiki/IUP_(software)

http://webserver2.tecgraf.puc-rio.br/iup/

"IUP is a multi-platform toolkit for building graphical user interfaces. It offers a simple API in three basic languages: C, Lua and LED. IUP's purpose is to allow a program source code to be compiled in different systems without any modification. Its main advantages are:

high performance, due to the fact that it uses native interface elements. fast learning by the user, due to the simplicity of its API."

LibUI (https://github.com/andlabs/libui) is another promising one with plenty of bindings. A portable wrapper around native widgets, just needs the table API to be completed.

Thanks, will take a look. I think I had come across it here on HN, but had not tried it out yet. Did not know that there were many bindings.

It says there:

ATTENTION: THIS PROJECT IS STILL BEING DEVELOPED AND IS NOT UNMAINTAINED. PLEASE DO NOT ASSUME THAT JUST BECAUSE THERE HASN'T BEEN A COMMIT ON THE MASTER BRANCH IN MONTHS IT HAS BEEN ABANDONED. THANK YOU!

but a bit below, it shows Build failing.

If you actually click that and check the build status, you can see that the most recent build of the master branch was successful.

The only failing builds are for pull requests and other branches.

The image URL in README.md should probably be changed to https://travis-ci.org/andlabs/libui.svg?branch=master (from just https://travis-ci.org/andlabs/libui.svg).

Thanks for that info.

I m not sure everybody knows how long this concept has matured, and I cannot prevent myself to quote XUL (I wrote thousands of lines of XUL and I loved how it was easy to create GUI for this time)

About 20 years ago, in 1998, Netscape Communicator 5.0 was released as an alpha version and introduced the new toolkit to build the GUI of the browser with XML, CSS and Javascript. Shortly after, the Mozilla foundation started and Netscape 6 was released.

At this time, around year 2000, it was an outstanding technology, and it could have become the defacto standard for cross platform GUIs...

Sadly, the Mozilla Foundation didn't sponsored this technology enough (in my opinion) to make it become the leader for cross-platform GUI development. Because of lack of interest as a core technology by Mofo, the problems with tooling around build and packaging, documentation, legacy components, newcomers accessibility were not resolved.

Firefox 57 removes the support of XUL for extensions but if I m not wrong it still uses XUL in some windows and the gecko engine (which render XUL).

After XUL, we saw interests of this concept of XML-based toolkits by Adobe (Flex), Microsoft (XAML), Gnome (Glade), QT (QML, maybe the winner ?), HaxeUI. There are probably more.

XUL is the oldest implementation of XML-based GUI toolkit that I know. There are probably some before.

Yeah, XML GUI is nothing new. But there are huge differences in usability. Having worked with at least a few of those, i got to hand it to Microsoft. Working with XAML is a pleasure compared to any other UI framework i have had to work with.

It really works well, and their Blend tool, makes it easy enough for even non-developers to design the UI component.

I still hold onto WPF for my pet projects.

It was around when I was taking my baby steps with GUI development, and nothing else I tried later came even close.

XUL was what popped into my mind too. There have been quite a few on the JVM too, the best being Apache Pivot [1], which had a really good componentisation story.

[1] - https://pivot.apache.org/

Since Sciter was mentioned, I'll probably mention https://github.com/zserge/webview which is a thin wrapper over native browser engines (webviews) and allows to bind HTML/CSS UI to the native code. It results in fairly small executables, and works well with C/C++/Go or there are some 3rd-party Rust or Nim bindings.

The big problem with that is that you end up using different browsers on different platforms (IE10/11 for Windows, webkit for Linux and MAC) which is a bit problematic to support.

LCUI doesn't seem to rely on a specific browser but still remains fairly small so that seems pretty good.

But small means less features, such as: unsupport rounded border, transitions, animations, etc.

To be fair, it's not that bad (I have made a couple of apps based on the webview) - IE11 is a rather decent browser supporting all the niceties from CSS3, flexbox etc. It's not that different from making layouts for web pages, when you have to support IE11 anyway. All the IE11 pitfalls are covered on stackoverflow, so it didn't feel like wasting much time to make windows version of the app look exactly like linux or macOS.

This looks really cool, my first instinct was "like xslt!" but this is way nicer and more pragmatic.

It's a shame that it requires X11 on Linux, though. As the renderer must already be decoupled from the rest of the code to support Windows and Linux, I imagine it shouldn't be too hard to rip out the X11 bindings and write to a framebuffer directly instead.

I have not had a chance to try it out for myself yet, but I have recently learned that webkit includes a direct-to-opengl renderer such that one can skip the Qt or GTK backend and write HTML/CSS/JS that outputs to the framebuffer directly.

And it makes sense, because WebGL.

Not really. WebGL basically exposes the OpenGL APIs from within the browser context. This backend focuses on drawing the browser chrome itself via the OpenGL API, which is wholly independent (one is a consumer, one is a provider). This was a patch that was upstreamed into WebKit a while back from a fork.

Generally speaking these "home inventended" UI tookits are a novel idea but not usable in practice because they always fail to follow standard desktop conventions and things like moving widget focus, cut/copy/paste, RTL text etc. are always broken in some funky ways. Also there's a reason why a lot of effort has been put into standardizing the look and feel of applications. It really sucks when some "we're special" app has their own buggy toolkit that doesn't work properly. Sigh.

Always strange to see code and variables in English and comments in Chinese, but I see it frequently. Not sure whether it's a good or bad thing, just seems a bit inconsistent and a way to ward off potential contributors. It seems you will have to know two languages to contribute, one for the comments and one for the variable and function names.

Still better than a language like Go or PHP where the keywords are in English, but the programmers variables are in Spanish, french or German.

Icy Glare ... Hahaha. Give me clean mono-language "source" code any day please.

> Give me clean mono-language "source" code any day please.

Unfortunately, not many programming languages with German keywords exist. ;-)

No, as a German, I understand your concern. The problem is, you need to be fluent in the language AND use names that fit the variables. I work in High Performance Computing and the code physicists write isn't accessible to me most of the times, just because they use one and two letter variables from their formulas in their code.

Unfortunately you have to name your variables in the context of the domain language. The domain language is usually in your native language. The keywords are in English. It looks horrible but there is no way around it. And you lucky native English speakers have never experienced the horror that are umlauts in filenames across filesystems and encodings.

shudder that reminds me that you can't Control+F "üõöä" properly in Chromium, both "uooa" and "üõöä" are matched, that's for me far more infuriating that breaking filename encoding.

At the beginning of this project, the author naive to think Chinese comment will attract more Chinese contributors. However, it does not actually work. So the author will consider commenting in English. In the new code.

It's just hard for people to express complex ideas (comments e.g.) in other languages rather than their native language. And variables in code are just basic words, nothing on gramma or other stuff.

How big are the resulting binaries? This is something that's always stopped me from using frameworks like this.

Also, from what I can see, the documentation seems to be in Chinese: https://lcui.lc-soft.io/guide/zh-cn/

8KB for hello world, checked all its *.so except for libicu(utf-8) it is pretty standard jpeg/png/xml/stdc++ libraries, size does not seem like an issue,

the the GPL license might be of an issue though, then again, the author said he will switch to LGPL in 1.0.0 release, so all is good!

Thanks. Did you strip the binaries?

Not an issue an any OS with a half decent package manager.

How is the quality of the package manager related to the size of the binary?

You can dynamically link and only have to distribute small binaries.

Don’t forget, there’s also https://sciter.com

Interesting that most of their showcase apps are antivirus apps.

You know, I wouldn't be surprised if most Anti-virus applications nowadays were basically the same core software but each with a few different kinds of frosting on top...

Not a surprise actually as AV software:

1. shall not be CPU consuming. That famous 13% CPU consumption on blinking caret (https://github.com/Microsoft/vscode/issues/22900) is not acceptable.

2. shall be as compact as possible.

3. shall follow modern UI trends on the long run and without major code refactoring. See: 10 years of UI evolution of Norton 360: https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-o... with Sciter.

4. Shall support Section 508 / Accessibility as they used by governments and in official institutions.

5. Shall support flexible layouts and screen sizes used in the wild. UI nailed down to pixel grids in light of high-DPI Retina's is not an option anymore. Sciter UIs work on 500 mln PCs and Macs and counting.

6. UI these days shall be GPU accelerated, Retina has 9 times more pixels than 96ppi "classic" screens.

7. Code-behind-UI shall be flexible and GCable as UI objects ownership graph is complex and may contain loops: "on-this-button-click-hide-that-and-expand-those-and-disable-the-button-until-done".

8. Shall support multiple languages and adjust layout to them: https://sciter.com/images/wt-langs.png

All that...

Disclosure: c-smile is the author of sciter.

I've found that antivirus in general (apart from their bad security practices) consistently fails at multiple of those points. For example:

Consumes a lot of resources.

Fails to follow design guidelines of the platform, but then again, maybe "modern trends" are more important than following the design language of the platform ¯\_(ツ)_/¯

That has dependencies on the UI toolkits, judging by the binary names (gtk dependency).

FYI: The tutorial guide is missing: http://lcui.org/guide/

The tutorial is only available in Chinese and no English. The author may consider taking the time to write an English version of the tutorial.

You have tests. and the lib is small enough just read the source.

That’s actually the author you’re replying to :)

It’s a quirk of the translation/language barrier that it may seem that he’s attacking the author, but just replace “the author” with a first person pronoun and re-read.

Library is GPL (not LGPL), so usage will be limited to those who don't mind the entire app's source code being released.

https://github.com/lc-soft/LCUI/issues/127

Like most other less-popular GUI toolkits that aren't just wrappers over the host platforms' native widgets, this one is inaccessible to people with disabilities, such as blind people (who use a screen reader). To fix this, toolkits like this one need to implement each host platform's accessibility API. On Windows, that's UI Automation; for Unix, that's AT-SPI. This is a lot of work, but it's necessary if the toolkit is going to be used for any software that might be important for a job, education, or generally living one's life.

To anyone else thinking of developing your own GUI toolkit, please reconsider. It would probably be better for you to just use one of the established ones, unless you have the resources to flesh out all of the tedious but important stuff like accessibility.

Edit: I'm sorry if I offended any developers or sounded like I was devaluing your work. That wasn't my intent, and I actually tried hard to keep the tone of this comment under control. It's just very frustrating every time I read about yet another inaccessible GUI toolkit.

Reconsider, but hopefully this will encourage the developers to address accessibility. I think it is important that automation is considered in the same category as accessibility. Automation could lead to great strides in accessibility.

Can you expand on what you mean by automation? Do you mean something like the Windows UI Automation API, which is an accessibility API that doubles as a way to automatically test UIs? Or do you mean something more like COM Automation or AppleScript?

All of the above. I believe automation apis such as windows UI automation, COM or applescript all contain valuable information for accessibility (some more than others). Whether that is simply all the text displayed on the screen (not that getting that done is simple) or conversion of a complex series of mouse clicks into a simple operation. I think system automation apis are comparable to accessibility apis. As one improves so should the other. Would be interested in discussing further.

As someone that has an amazing work colleague that is blind but also an amazing software developer, I very strongly agree with the idea of your comment.

I'm genuinely annoyed and sad when I'm dealing with shitty UI/UX and realize that something may be completly unaccessible for his use.

He made me more aware of the general problems and it's something I always keep in the back of my mind when explaining or doing things (things like pictures, diagrams, white board drawings, etc are a no-no).

I would like to see more people aware and thinking of this and not forget of the issue for new experiences with new UIs.

> for Unix, that's AT-SPI

Some time ago i looked into this since i am creating a toolkit (unrelated to the linked one) and thought that it would be nice to add some accessibility support - at least for screen readers. Unix doesn't have an accessibility API nor does X, AT-SPI is basically GNOME's version which works via ATK and/or D-Bus. D-Bus is not an acceptable requirement for my case since it is a system that adds a lot of extra unnecessary complexity and implementing ATK (like Firefox) does is an even bigger no-no And really the only thing that uses AT-SPI is Gnome's Orca (KDE users use that too) and that project doesn't look very healthy (lots of bug - including several major bugs that are there for years, the wiki is a mess that has notes from 2011 about "cleaning it up").

So i just dropped the idea since it doesn't seem to be any way for this to work with X itself - nobody bothered to specify any protocol that works with pure X. It is something i might look into myself in the future, but honestly it is not a big priority for me.

> This is a lot of work, but it's necessary if the toolkit is going to be used for anything other than games or toys.

There are a ton of programs that do not provide accessibility features tech and are not games nor toys (in fact i'd guess that the majority of programs you'd find in a Linux distro do not provide anything like that - and a quick look at Orca's bugtracker makes it clear that even those that seem to do it have many issues). Also i think you'd have a better response from the people who are writing the actual code if you aren't trying to devalue their work by calling it games and toys.

> It would probably be better for you to just use one of the established ones,

It would be even better if the established toolkits didn't suck as much and broke their APIs every 2-3 years, making the programs that depend on them have a shorter lifespan than the supported versions of Windows (let alone reaching a point where they can even dream about Windows' backwards compatibility).

> trying to devalue their work by calling it games and toys.

I'm sorry; that's not what I meant to do. I only meant that I know it's not reasonable to expect developers of games and other software that's just for fun to go out of their way to implement accessibility. But for any software that might be used in a job, for education, for interacting with a company or government agency, or even for communication in general, accessibility is really important. I know a blind guy who almost lost his job because he couldn't use a specific piece of inaccessible software; he only kept his job because the company found something entirely different for him to do. And yes, a lot of important software is not accessible. We need to change that.

About AT-SPI and D-Bus, could you implement AT-SPI support as a plugin, so it's there for those who need it but doesn't add D-BUS as a hard dependency? That's what Qt does.

Oh i see, sorry about the misunderstanding then.

> About AT-SPI and D-Bus, could you implement AT-SPI support as a plugin, so it's there for those who need it but doesn't add D-BUS as a hard dependency? That's what Qt does.

I'll need to look into it, if i go into that route i'll most likely make it an optional build-time feature that is enabled by default if the relevant header files are found and try to load it dynamically instead of making it a plugin (the toolkit can be compiled as a static library to create self-contained executables). This is also what i'm doing with OpenGL support that may not always exist - the toolkit and application work, it just disables the OpenGL stuff.

But this is something i'll check in the future, at the moment the toolkit is barely usable even by people with perfect sight :-P.

Sounds like a good solution. Thanks for taking the initiative to look into this already!

In the past, the author found the word "accessibility" from the example code in the Boostrap.css documentation, and the author has considered let LCUI support accessibility, but the author's free time is limited, So before the stable version is completed, the main task now is to make the project functions work stably.

you can recommend a cross-platform C library for the accessibility support.

Not C per se, but FreePascal's LCL library has native accessibility support [1], and there are plenty of examples showing how to mix Pascal and C [2].

[1]: http://wiki.freepascal.org/LCL_Accessibility [2]: https://github.com/williamhunter/pascal-bindings-for-c

Why people do that? It is always a good learning experience.

While this is true, I think focusing on _implementing_ accessibility from the get go is a bad idea. You should instead design the toolkit so that you have an idea of how it could be implemented in the future and if the toolkit gets popular.

How about forgetting about GUI altogether? To keep things concrete, I intend to write a file encryption utility and a password manager. The first versions will be command line programs.

But of course, over 90% of computer users have this "unable to command line" disability, so they need a GUI. I was thinking of writing my own. Small, simple, and completely oblivious to accessibility issues—except maybe font sizes.

Would that be okay? I mean, who cares about GUI accessibility if you can do the same thing on the command line? Unless the command line is not accessible for some unfathomable reason?

That'd be fine, especially considering that someone else could write their own GUI front-ends for your utilities.

Is LCUI reusing a layout engine from another project? That is, how is it interpreting XML/CSS?

No, it only has these dependencies https://github.com/lc-soft/LCUI#prerequisites

The xml layout parser is at: https://github.com/lc-soft/LCUI/blob/develop/src/gui/builder...

The CSS parser at: https://github.com/lc-soft/LCUI/blob/develop/src/gui/css_par...

Interesting software. It has some features similar to GTK and CSS support like QT/QML. Though i am not 100% sure if the lib supports advanced ui scenarios and auto scaling. Nonetheless interesting ui to get started building interfaces for beginners.

There's also https://www.nidium.com

There's also DlangUI

http://buggins.github.io/dlangui/

Another nifty C++ UI library: nana

http://nanapro.org/en-us/

This is very cool. Are there any C++11 libraries like this? Also, being GPL sucks for desktop UI projects.

Is everything done at compile-time?

Making UI design easy sounds great. Bundling a web browser in every program does not.

Fantastic.

I wonder how easy it is to use this with languages like python ?

I'm also curious about what the lc-finder is.

a hello world is 8k in size, but it does link to libicudata which is 25MB which is for utf-8, other libraries such as libjpeg, libpng, libc, libX11, libstdc++ are pretty standard, with the largest libstdc++ is about 1.5MB, so if you can somehow get rid of libicu, your executable will be of typical size.

> C

Anyone already running a profile-guided fuzzer on this then?

Looks good for Mobile apps

What I really want is CEF in a C API. I know it exists, but the way Chromium dictates its usage on macOS makes it really limiting for FFI purposes.

UIs in OpenGL are a pita, and the best I've ever seen done that didn't involve HTML-like or HTML-based design was in VGUI. Attempting to build a modern UI kit for a basic game engine today easily results in producing a lump sum on the order of 10k SLOC just to add some critical functionality to your app/game.

Even if written in C, I would gladly use this over Electron.

The problem with Electron are the large resulting binaries. Sure, it gives you everything, but you don't want to ship a whole browser engine every-time you ship a small app.

But that’s the enterprise way!

That's not enterprise enough. Shipping a whole JVM with your app, now that is Enterprise.

Depending on deployments, aren't VMs and Docker like that in practical use?

Yeah, but J2EE servers are bad, while Docker is cool.

Our industry really is this bonkers.

Can J2EE servers package Ruby, Python, PHP, etc.? :)

Yes, JRuby, Jython, Quercus, the remaining etc might also have a JVM implementation. :)

The problem with Electron is that I already have a browser on my computer, actually three (FF, IE, Chrome), I don't need more.

Plus it doesn't add anything positive the UI/UX beyond a few devs wanting a .exe instead of an URL, and not having to deal with the quirks of each browser/OS.

I never liked MSHTML, Active Destkop, XUL, and I really don't see why Electron should be treated in any different way, just because learning how to use native APIS or writing an simple abstraction layer is "too complicated".

If devs want to do a web app, do a web app, deal with browser quirks, use web workers, just don't package a browser with it.

nice, does it support wasm?

great!

This looks good, I think that it would be worth giving it a shot. My main problem is XML, it is always incredibly slow to parse, and there is not an accepted defined way to express the content, s-expressions would do a much better job, perhaps a combination between C parsing scheme definitions of UIs could work.

I think this depends of the levels of nesting and complexity, but a libsax based parser is not "incredibly" slow.

A Dom based parser could be, but also depends of number of nodes and nesting.

I'm not sure why the OP thinks that parsing XML is any slower than any other data representation method that allows arbitrary nesting.

Love sax by the way. I just switched over one of our sites to use a sax based parser because the default rails .to_hash was choking on 100MB+ XML files.

> My main problem is XML, it is always incredibly slow to parse

They could always add an option to compile it, much like xaml, it may even be as simple as a xslt transform.

Woa, XSLT to create an executable.. it's so twisted I hope someone does this.

For most UI toolkits, isn't XML parsing happening pretty infrequently (and mostly at startup)?

Speeding up start times is a laudable goal, but this comment makes it sound as if the performance implications are more significant than that.

>XML, it is always incredibly slow to parse

I don't see libxml2 being slower than any other markup language parser. In comparison to how slow some JSON (an easier to parse language) parsers are, libXML2 is actually quite fast.

Reply on news.ycombinator.com