
LCUI – A small C library for building user interfaces with XML and CSS - ausjke
https://github.com/lc-soft/LCUI
======
leggomylibro
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.

~~~
mixmastamyk
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/vurtun/nuklear)

[https://github.com/billsix/pyNuklear](https://github.com/billsix/pyNuklear)

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

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

------
vram22
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)](https://en.wikipedia.org/wiki/IUP_\(software\))

[http://webserver2.tecgraf.puc-rio.br/iup/](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."

~~~
flukus
LibUI ([https://github.com/andlabs/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.

~~~
vram22
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.

~~~
vram22
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.

~~~
aepiepaey
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](https://travis-
ci.org/andlabs/libui.svg?branch=master) (from just [https://travis-
ci.org/andlabs/libui.svg](https://travis-ci.org/andlabs/libui.svg)).

~~~
vram22
Thanks for that info.

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

~~~
colde
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.

~~~
Kuraj
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.

------
krugloid
Since Sciter was mentioned, I'll probably mention
[https://github.com/zserge/webview](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.

~~~
chocolatebunny
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.

~~~
zserge
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.

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

~~~
paulddraper
And it makes sense, because WebGL.

~~~
ComputerGuru
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.

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

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

~~~
tenken
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.

~~~
cntlzw
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.

~~~
Avamander
_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.

------
akandiah
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/](https://lcui.lc-soft.io/guide/zh-cn/)

~~~
ausjke
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!

~~~
ComputerGuru
Thanks. Did you strip the binaries?

------
dmitriid
Don’t forget, there’s also [https://sciter.com](https://sciter.com)

~~~
tbodt
Interesting that most of their showcase apps are antivirus apps.

~~~
c-smile
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](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...](https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-one-
application/) 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](https://sciter.com/images/wt-
langs.png)

All that...

~~~
aepiepaey
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 ¯\\_(ツ)_/¯

------
edsiper2
FYI: The tutorial guide is missing:
[http://lcui.org/guide/](http://lcui.org/guide/)

~~~
lcsoft
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.

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

~~~
ComputerGuru
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.

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

~~~
tbodt
[https://github.com/lc-soft/LCUI/issues/127](https://github.com/lc-
soft/LCUI/issues/127)

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

~~~
badsectoracula
> 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).

~~~
mwcampbell
> 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.

~~~
badsectoracula
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.

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

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

~~~
mythz
No, it only has these dependencies [https://github.com/lc-
soft/LCUI#prerequisites](https://github.com/lc-soft/LCUI#prerequisites)

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

The CSS parser at: [https://github.com/lc-
soft/LCUI/blob/develop/src/gui/css_par...](https://github.com/lc-
soft/LCUI/blob/develop/src/gui/css_parser.c)

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

------
voctor
There's also [https://www.nidium.com](https://www.nidium.com)

------
petre
There's also DlangUI

[http://buggins.github.io/dlangui/](http://buggins.github.io/dlangui/)

------
lasagnaphil
Another nifty C++ UI library: nana

[http://nanapro.org/en-us/](http://nanapro.org/en-us/)

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

------
adultSwim
Is everything done at compile-time?

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

------
stuaxo
Fantastic.

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

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

~~~
ausjke
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.

------
ris
> C

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

------
known
Looks good for Mobile apps

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

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

~~~
akandiah
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.

~~~
colejohnson66
But that’s the enterprise way!

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

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

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

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

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

------
jlebrech
nice, does it support wasm?

~~~
lcsoft
No

------
waruqi
great!

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

~~~
flukus
> 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.

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

