14 ms·

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

335 points by ausjke 9y ago

pecg 9y ago
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.
- jbreiding 9y ago
  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.
  - learc83 9y ago
    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.
- flukus 9y ago
  > 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 9y ago
    Woa, XSLT to create an executable.. it's so twisted I hope someone does this.
- deleted 9y ago
  [deleted]
- zbentley 9y ago
  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.
- baybal2 9y ago
  >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.
edsiper2 9y ago
FYI: The tutorial guide is missing: http://lcui.org/guide/ http://lcui.org/guide/
- lcsoft 9y ago
  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 9y ago
    You have tests. and the lib is small enough just read the source.
    - ComputerGuru 9y ago
      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.
akandiah 9y ago
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 9y ago
  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 9y ago
    Thanks. Did you strip the binaries?
- flukus 9y ago
  Not an issue an any OS with a half decent package manager.
  - mort96 9y ago
    How is the quality of the package manager related to the size of the binary?
    - flukus 9y ago
      You can dynamically link and only have to distribute small binaries.
dmitriid 9y ago
Don’t forget, there’s also https://sciter.com https://sciter.com
- tbodt 9y ago
  Interesting that most of their showcase apps are antivirus apps.
  - princekolt 9y ago
    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...
  - deleted 9y ago
    [deleted]
  - c-smile 9y ago
    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-one-application/ 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 https://sciter.com/images/wt-langs.png All that...
    - 9y ago
stuaxo 9y ago
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 9y ago
  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.
fuber2018 9y ago
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 9y ago
  https://github.com/lc-soft/LCUI/issues/127 https://github.com/lc-soft/LCUI/issues/127
krugloid 9y ago
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 9y ago
  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.
  - lcsoft 9y ago
    But small means less features, such as: unsupport rounded border, transitions, animations, etc.
  - zserge 9y ago
    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.
pjmlp 9y ago
Even if written in C, I would gladly use this over Electron.
- akandiah 9y ago
  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 9y ago
    But that’s the enterprise way!
    - userbinator 9y ago
      That's not enterprise enough. Shipping a whole JVM with your app, now that is Enterprise.
      - tracker1 9y ago
        Depending on deployments, aren't VMs and Docker like that in practical use?
        pjmlp 9y ago
        Yeah, but J2EE servers are bad, while Docker is cool.
        tonyedgecombe 9y ago
        Our industry really is this bonkers.
        oblio 9y ago
        Can J2EE servers package Ruby, Python, PHP, etc.? :)
edmundhuber 9y ago
Is LCUI reusing a layout engine from another project? That is, how is it interpreting XML/CSS?
- mythz 9y ago
  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.c 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_parser.c https://github.com/lc-soft/LCUI/blob/develop/src/gui/css_par...
vram22 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        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).
pankajdoharey 9y ago
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.
kodablah 9y ago
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 9y ago
  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.
  - rmetzler 9y ago
    > 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.
  - cntlzw 9y ago
    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 9y ago
      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.
- 9y ago
leggomylibro 9y ago
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 9y ago
  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
  - leggomylibro 9y ago
    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.
  - billsix 9y ago
    Lol I was just about to repost my pyNuklear link. Regular nuklear is fantastic if you like C, which I do too :-).
ComputerGuru 9y ago
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 9y ago
  And it makes sense, because WebGL.
  - ComputerGuru 9y ago
    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.
waruqi 9y ago
great!
mwcampbell 9y ago
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.
- daveguy 9y ago
  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.
  - mwcampbell 9y ago
    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?
    - daveguy 9y ago
      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.
petre 9y ago
There's also DlangUI http://buggins.github.io/dlangui/ http://buggins.github.io/dlangui/
known 9y ago
Looks good for Mobile apps
jlebrech 9y ago
nice, does it support wasm?
- lcsoft 9y ago
  No
hartmel 9y ago
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 9y ago
  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 9y ago
    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.
- kitd 9y ago
  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/ https://pivot.apache.org/
sytelus 9y ago
This is very cool. Are there any C++11 libraries like this? Also, being GPL sucks for desktop UI projects.
voctor 9y ago
There's also https://www.nidium.com https://www.nidium.com
ensiferum 9y ago
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.
andrewmcwatters 9y ago
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.
adultSwim 9y ago
Is everything done at compile-time? Making UI design easy sounds great. Bundling a web browser in every program does not.
lasagnaphil 9y ago
Another nifty C++ UI library: nana http://nanapro.org/en-us/ http://nanapro.org/en-us/
ris 9y ago
> C Anyone already running a profile-guided fuzzer on this then?

335 points by ausjke 9y ago

pecg 9y ago

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.

jbreiding 9y ago
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.
- learc83 9y ago
  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.
flukus 9y ago
> 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 9y ago
  Woa, XSLT to create an executable.. it's so twisted I hope someone does this.
deleted 9y ago
[deleted]
zbentley 9y ago
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.
baybal2 9y ago
>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.

edsiper2 9y ago

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

lcsoft 9y ago
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 9y ago
  You have tests. and the lib is small enough just read the source.
  - ComputerGuru 9y ago
    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.

akandiah 9y ago

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 9y ago
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 9y ago
  Thanks. Did you strip the binaries?
flukus 9y ago
Not an issue an any OS with a half decent package manager.
- mort96 9y ago
  How is the quality of the package manager related to the size of the binary?
  - flukus 9y ago
    You can dynamically link and only have to distribute small binaries.

dmitriid 9y ago

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

tbodt 9y ago
Interesting that most of their showcase apps are antivirus apps.
- princekolt 9y ago
  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...
- deleted 9y ago
  [deleted]
- c-smile 9y ago
  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-one-application/ 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 https://sciter.com/images/wt-langs.png All that...
  - 9y ago

stuaxo 9y ago

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 9y ago
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.

fuber2018 9y ago

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 9y ago
https://github.com/lc-soft/LCUI/issues/127 https://github.com/lc-soft/LCUI/issues/127

krugloid 9y ago

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 9y ago
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.
- lcsoft 9y ago
  But small means less features, such as: unsupport rounded border, transitions, animations, etc.
- zserge 9y ago
  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.

pjmlp 9y ago

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

akandiah 9y ago
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 9y ago
  But that’s the enterprise way!
  - userbinator 9y ago
    That's not enterprise enough. Shipping a whole JVM with your app, now that is Enterprise.
    - tracker1 9y ago
      Depending on deployments, aren't VMs and Docker like that in practical use?
      - pjmlp 9y ago
        Yeah, but J2EE servers are bad, while Docker is cool.
        tonyedgecombe 9y ago
        Our industry really is this bonkers.
        oblio 9y ago
        Can J2EE servers package Ruby, Python, PHP, etc.? :)

edmundhuber 9y ago

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

mythz 9y ago
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.c 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_parser.c https://github.com/lc-soft/LCUI/blob/develop/src/gui/css_par...

vram22 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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).

pankajdoharey 9y ago

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.

kodablah 9y ago

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 9y ago
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.
- rmetzler 9y ago
  > 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.
- cntlzw 9y ago
  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 9y ago
    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.
9y ago

leggomylibro 9y ago

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 9y ago
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
- leggomylibro 9y ago
  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.
- billsix 9y ago
  Lol I was just about to repost my pyNuklear link. Regular nuklear is fantastic if you like C, which I do too :-).

ComputerGuru 9y ago

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 9y ago
And it makes sense, because WebGL.
- ComputerGuru 9y ago
  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.

waruqi 9y ago

great!

mwcampbell 9y ago

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.

daveguy 9y ago
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.
- mwcampbell 9y ago
  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?
  - daveguy 9y ago
    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.

petre 9y ago

There's also DlangUI http://buggins.github.io/dlangui/ http://buggins.github.io/dlangui/

known 9y ago

Looks good for Mobile apps

jlebrech 9y ago

nice, does it support wasm?

lcsoft 9y ago
No

hartmel 9y ago

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 9y ago
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 9y ago
  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.
kitd 9y ago
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/ https://pivot.apache.org/

sytelus 9y ago

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

voctor 9y ago

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

ensiferum 9y ago

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.

andrewmcwatters 9y ago

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.

adultSwim 9y ago

Is everything done at compile-time? Making UI design easy sounds great. Bundling a web browser in every program does not.

lasagnaphil 9y ago

Another nifty C++ UI library: nana http://nanapro.org/en-us/ http://nanapro.org/en-us/

ris 9y ago

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