
Libui: GUI library in C - avitex
https://github.com/andlabs/libui
======
jventura
This is a very good approach for the current times!

As far as I understand from the source code, libui is a thin C wrapper that
makes calls to each platform native ui framework. For instance, to create a
window on OSX it calls the corresponding Cocoa function, for Linux the
corresponding GTK function, etc. So, unlike Qt and GTK which are heavy cross-
platform libraries because they can "draw" their own widgets themselves, this
library seems to just call other functions. In that sense, the resulting
widgets are as native as they can be!

Qt, Gtk and others are from those old days when everyone wanted alternatives
to native frameworks that could "draw" their own widgets. That is why Qt and
GTK are/were useful to build the native desktop frameworks of Linuxes.. In
these modern times that everyone has moved to Web, things on the desktop-land
are far more stable and it is common agreement that Cocoa is perfectly fine
for Mac, Win32 is perfectly fine for Windows and GTK is perfectly fine for
Linux. This is great news, so now it is the best time to make thin wrappers
around these stable things so that we can all go make useful software..

As for the why C and not anything else, is just that all these UI native
frameworks can be easily called from C, and C is the common denominator of
other higher level languages. So, in theory, each programming language that
can interface with C (99.9% of them can) can call the functions of this libui.
This means that, in theory, we can all start building 100% native desktop
applications in our favorite languages with a lightweight library.. Now I'm
off to start pylibui.. ;)

~~~
distances
> [...] GTK is perfectly fine for Linux. This is great news, so now it is the
> best time to make thin wrappers around these stable things so that we can
> all go make useful software..

Hoping not to start any kind of framework quarrel, but my understanding was
that quite many applications (such as Wireshark, Subsurface, and OpenShot) are
moving from GTK to Qt very much due to Qt being more stable. Or is the main
reason cross-platform compatibility?

~~~
random443
My personal reason is that GTK 3+ lost his track in what constitutes a
_desktop_ widget set. It's also getting slower at each release, it keeps
breaking visual consistency and basic features get removed or heavily
deprecated in favor of a "dumbed down" approach. So if the non-technical users
are actually migrating to dumb web-apps and couldn't care less, the technical
crowd which demand power features and efficiency are getting fed up. As a
developer, I certainly am. The trend started already with the latest 2.x
series in GTK, not with GTK 3.

My standards for quality on the desktop are way higher than what the "web" is
supposed to give you today. It must be fast, consistent, and don't have any
glitch.

The looks are a secondary point (and GTK 2 engines, or Qt4 for the matter)
already give you _great_ customization possibilities, which are way beyond
what most other systems can do already.

GTK 3 and QML (Qt5) would like to target the same space as web applications.
It doesn't make sense. Applications which are written with a web UI in mind
will translate _very_ poorly on the desktop, and the opposite is also true. My
experience with QML was abysmal, and definitely not worth the extra
dependency. Maybe you think that you button must be big and fat and have extra
space to be tapped on-to, but on a desktop this is all wasted space on the
screen that I want to use for _data_.

GTK 3 is trying to innovate a bit on the UI front, but many of the changes
come with usability regressions on the desktop which I don't find acceptable
anymore. Overlay scrollbars are a good example. In principle, they're a great
idea. However the implementation is riddled of bugs which makes using
scrollbars with a mouse a pain.

The CSS theming is nice, but they keep breaking the styles at each minor
release. It's also incredibly slow. Whereas GTK+ and QML aim for rendering in
a GL context, the reality is that if you want predictable performance they're
going to be useless anyway.

~~~
audidude
> It's also getting slower at each release, it keeps breaking visual
> consistency and basic features get removed or heavily deprecated in favor of
> a "dumbed down" approach.

This is simply not true.

We are closer to hitting 60 fps (or whatever your EDID actually presents) than
ever before, and staying locked to that. The more complex of an interface you
create, the harder that is, but that is no different today than ever before.
Work is underway doing something similar to the webrender concepts which will
improve render times even further.

I'm not sure what you mean by visual consistency, other than we create new
widgets as designers ask for them. Just because applications choose to use
something other than say a GtkComboBox for everything is hardly our fault. I
welcome a future where application developers can decide what UI concepts work
for them.

That doesn't mean you can't use deprecated widgets. This is no different than
any other platform. We experiment with new ideas, keep what works well, and
deprecate what doesn't based on feedback and user testing. GTK+ is one of the
few libraries that generally stays ABI stable for a decade, so deprecated is
more of an indicator than "this will be removed next month" like developers
are used to with web APIs.

> GTK 3 and QML (Qt5) would like to target the same space as web applications.
> It doesn't make sense. Applications which are written with a web UI in mind
> will translate very poorly on the desktop, and the opposite is also true. My
> experience with QML was abysmal, and definitely not worth the extra
> dependency. Maybe you think that you button must be big and fat and have
> extra space to be tapped on-to, but on a desktop this is all wasted space on
> the screen that I want to use for data.

Where do you get your information? Because they seem to be fairly miss-
informed.

GTK+ is most definitely not trying to be a web application toolkit. The "big
buttons" are that size because people have all sorts of accessibility needs
different from your own. Or you're on HiDPI and we don't have 1.5x scaling
(yet) as it requires more plumbing in the compositor to do 3x scaling in the
toolkit and 2x downscaling (and input transformations) in the compositor. I
hope to see this before long.

Personally, I'd like to see a "condensed" theme variant of sorts. Finally,
thanks to all the CSS node work in 3.20, you can pretty much get that with a
couple CSS lines.

> The CSS theming is nice, but they keep breaking the styles at each minor
> release. It's also incredibly slow. Whereas GTK+ and QML aim for rendering
> in a GL context, the reality is that if you want predictable performance
> they're going to be useless anyway.

It's no secret to GTK+ developers that the theming API was always sort of a
gray area. As of 3.20 the theming API, for the first time in nearly 18 years,
is considered stable.

GTK+ does not render with GL today. (There is integration to embed GL into the
scene, though). That might land for 3.22, but it's a lot of work and I would
not be surprised if it doesn't make it until 3.24 as it's part of the drain-
the-swap redesign of the drawing model. Presumably vulkan will be supported
too.

~~~
twotavol
> The "big buttons" are that size because people have all sorts of
> accessibility needs different from your own

What accessibility needs are you targeting when you make the buttons and
titlebars bigger? Why did this change drop suddenly? Was there a cry from the
majority of your users that the widgets are too small to use with desktop
inputs?

Usually when there are accessibility issues you add options to deal with that,
you don't change everything for a relatively tiny percentage of your user
base. Would you make all your widgets have max contrast and double the font
size by default because it improves accessibility for the visually impaired?

~~~
audidude
> Usually when there are accessibility issues you add options to deal with
> that, you don't change everything for a relatively tiny percentage of your
> user base. Would you make all your widgets have max contrast and double the
> font size by default because it improves accessibility for the visually
> impaired?

There are way more types of impairments than visually impaired. We do have
high contrast themes to help with a subset of visual impairment. (Even visual
impairment is a wide-spectrum).

Many of us may not particularly like touch screens, but an incredible number
of computers that run Linux/BSD these days have touch screens. Things should
work out of the box for these computers whether or not you want one.

So we can make arbitrary guesses at what the "majority" is but the reality is
we have a lot of hardware that we should support. Getting real statistics
about users in F/OSS is difficult due to the high overlap of people interested
in personal privacy. So we try to make as informed of decisions as we can.

Additionally, more computer users than you might image have various
difficulties in using the computer. Even if its not a majority, say one in
ten, is still a large number of users.

Count yourself lucky that you don't have an impairment (right now). It is
common that people have an impairment at some point in time (RSI, broken arm,
etc).

I certainly agree that HiDPI is often way too large today (again due to the
need for compositor integration), and I also agree we should have a condensed
mode. However, I'd probably argue to implement a condensed mode on top of an
effective 1.5x scaling (3/2) rather than yet another option in the
toolkit/themes.

~~~
twotavol
Why are you lecturing me on visual impairment and disabilities? At no point
did I claim you ignore that user base.

>Many of us may not particularly like touch screens, but an incredible number
of computers that run Linux/BSD these days have touch screens. Things should
work out of the box for these computers whether or not you want one.

Okay so after all that we get to the root of the issue. Instead of a good
traditional desktop experience, you want to provide a mediocre desktop/touch
hybrid experience. Instead of doing one thing well, the aim is to do multiple
things poorly.

~~~
audidude
I am trying to not come off as lecturing. My apologies if it was interpreted
as such. You were making claims and I'm simply trying to provide examples of
how other peoples computing experience might not match your own.

> Okay so after all that we get to the root of the issue. Instead of a good
> traditional desktop experience, you want to provide a mediocre desktop/touch
> hybrid experience. Instead of doing one thing well, the aim is to do
> multiple things poorly.

No need to get disparaging here. Clearly we don't want to provide a "mediocre"
experience, nor do I think we do.

I also don't agree that supporting touch is some sort of hybrid experience
these days. We aren't trying to be a mobile platform. We aren't trying to be a
phone platform. Peoples traditional desktops (including many home
workstations) have touch. These are real desktops bought by real people who
get real work done.

~~~
rootlocus
I work with a lot of people who have desktops. I have two. I haven't seen
anyone use a traditional desktop with touch. No one. Not once. My girlfriend
is a 2d artist and she uses a wacom tablet for digital painting in photoshop.
That's it.

I always disliked the huge buttons that come by default with some desktop
environments, and I'm amazed the argument is "people use touch". As far as I
and everyone around me is concerned, no they don't.

If it's an accessibility issue, it should be an optional solution for those
who need it, not the default.

------
striking
Finally.

I'm hoping that a native UI toolkit that can be used via FFI from nearly any
language might take a chunk out of the Web-as-application-delivery-platform
mindset.

I don't blame anyone for making non-native apps with Electron and HTML5,
because it's so difficult to make them work on every platform. But here's to
hoping someone finally got it right, and that native applications can take
back some ground.

Death to the battery-eaters and memory-fillers. Let the OS do the heavy
lifting.

~~~
karim
Well, plenty of people tried this approach (off the top of my head, wxWidgets,
Tk (the TCL framework, still powering Python, Perl and Ruby GUIs), FLTK).
Unfortunately, all those frameworks fail for the same reason: they're all 90%
there but fall short on the small details.

Still, let's hope that libui does great --- it's already quite a feat to have
the basic window controls working the same on three different platforms.

~~~
ArkyBeagle
I've used Tk many, many times as a foundation of a temporary strawman
interface while the real UI experts ... do whatever it is they do. I've also
used it for custom instrumentation GUIs.

That 90% constitutes a lingua franca.

Not knocking the nice UI/UX folks - they work their corner, I work mine, and
it's nice to have a technology to bridge schedules. My observation is that
that 10% consumes as much as 1000% of the schedule at times :)

~~~
Arnt
The first 90% are easy, the next 90% wear you out, and the final 90% are what
makes a good product...

In my experience, the story of using a layered UI like this is that for a
short while you use it, then customers start asking for features it cannot
deliver and you start writing platform-specific code, then after a while the
portable code is a minority. At some point there's a meeting in which someone
points out that a particular platform is 90% of the value and wouldn't it be
better to make do with just that 90%? Are these other platforms really worth
the effort?

~~~
ArkyBeagle
ObDisclosure: I'm in the embedded/middleware space.

I dunno. My peers don't write UI much at all; I do these things as force
multipliers for my own nefarious purposes.

None of it gets "published" in a formally supported way, so I don't have any
accountability for 'em. They're intentionally ugly but not dissonantly so. The
design is "look, but don't touch." I mainly use them to anticipate integration
errors and do something useful to aid in diagnosis of those. The theme here is
"it ain't me, babe" or "holy cow, thanks for finding that" \- determination on
that axis.

But I also put adequate instrumentation in to exploit in the first place.
Seems to be a lost art.

To me, the perfect user interface is no user interface at all - maybe a "push
to start" button - a physical button. Second best is command line/scripting,
third is the sort of thing I write.

In the embedded space, you might get a perception that this is cheating. I
just smile.

------
etwigg
Nice work, but I wish SWT had picked up more steam outside the Java community.
It's the same idea, but with a decade+ of banging on the corner cases for the
use cases of the Eclipse IDE.

In addition to all the standard controls, it's also got OpenGL and browser
embedding since before Electron was cool.

Using it on the JVM is very easy, but there was a short-lived attempt to
maintain a C++ API.

\- How it looks: [https://www.eclipse.org/swt/](https://www.eclipse.org/swt/)

\- From Jython:
[https://github.com/danathughes/jythonSWT](https://github.com/danathughes/jythonSWT)

\- From JRuby:
[https://github.com/neelance/swt4ruby](https://github.com/neelance/swt4ruby)

\- From C++ (defunct): [http://www.pure-native.com/](http://www.pure-
native.com/)

It's built out of small chunks of C code:
[https://github.com/eclipse/eclipse.platform.swt/search?p=1&q...](https://github.com/eclipse/eclipse.platform.swt/search?p=1&q=extension%3A.c&type=Code&utf8=%E2%9C%93)
that are wrapped in a Java API with a straightforward coding style that seems
amenable to automatic source translation. And it doesn't need GC - it actually
requires the Java programmer to manually dispose resources, which is easy
because it always requires objects to have a parent, so everything goes away
when the pane / window / whatever gets disposed.

~~~
tomp
Wouldn't you have to embedd JVM to use SWT?

Reminds me of a quote by Joe Armstrong, creator of Erlang, on OO programming:

"You wanted a banana but what you got was a gorilla holding the banana and the
entire jungle."

~~~
etwigg
Pure-native was a full C++ port. The Java part of SWT uses manual memory
management, and is written very simply. I think you could autoconvert it to
C++ and present the API that way.

------
apayan
andlabs (Pietro) is writing this library in C as a support for the Go ui
library he's been building.
[https://github.com/andlabs/ui](https://github.com/andlabs/ui)

However, as others have pointed out, this will be very useful for many other
languages as well. I would love to see a Renaissance of native cross platform
apps.

~~~
fit2rule
>I would love to see a Renaissance of native cross platform apps.

Along similar lines, I have been using the MOAI environment, with the Hanappe
GUI framework, to deliver apps across every platform you can port MOAI too,
sort of .. fulfilling .. the once-jaunted "write once, run anywhere" dream,
while also giving me a usable UI environment for the modern world.. ship
bytecode/Lua files, run the same code everywhere (the MOAI client lives).

Seriously, worth an hour or so of lab-bench time, if one is considering the
prospect of having an app/run-time equilibrium, albeit with a modicum of
effort:

[http://github.com/moai/](http://github.com/moai/)
[http://github.com/makotok/Hanappe](http://github.com/makotok/Hanappe)
[http://github.com/makotok/Flower](http://github.com/makotok/Flower)

(Flower is another branch, similar concept: build your entire UI as a mini-
lib, bring it with you everywhere you need it...)

~~~
twotavol
A simple write up with screenshots or something would be nice.

------
hoodoof
Juce is another interesting UI lib
[https://www.juce.com/](https://www.juce.com/)

Works with Windows, Mac OS, Linux, iOS and Android.

Strangely, juce seems to have a revamped website that has no pictures or
screenshots of the juce user interface and its widgets. Weird. Not sure how
effective that marketing is...

~~~
douche
I know, we always do this, but...

I hate this website. I feel like I'm looking at a Medium post, stuff is
popping around as I scroll, hero carousel, unclear Metro-style tiles that turn
black and disappear the text on mouse-over, the works. Spent way too much time
trying to figure out where the API docs and examples were hidden.

~~~
roywiggins
Agreed 110%.

Gimme a screenshot of something built with it, a snippet of a Hello World,
tell me where it runs, point me to the docs, and point me to a download.

I can't use scrolling pictures of people looking at code(!), I'm not about to
watch a keynote, I don't want a "developer story", I don't want links to
"companies using"! I shouldn't need to click twice to get to "features," that
ought to be the first thing I see!

The remainder might well be useful for some audiences, and as jumping-off
point to get a sense of the ecosystem and community around the software, but
put it at least a little bit below the fold.

~~~
hoodoof
Judging from all the jobs listed on the Juce careers page it looks like they
got a bunch of investment money and spent it on "going corporate".

Here's what Sensei Jeff has to say about that:
[https://blog.codinghorror.com/if-it-looks-corporate-
change-i...](https://blog.codinghorror.com/if-it-looks-corporate-change-it/)

------
laurentoget
These APIs are notoriously hard to get right and coherent, and releasing at
such an early stage will make it hard to change anything when building up on
this.

That said I do not know of any cross platform library in C, so this does seem
to fill a niche.

~~~
mahmud
Umm, Gtk?

~~~
geon
Correct me if I'm wrong, but GTK isn't really native on anything but Gnome.
Instead apps are just skinned to (mostly) look like each platform.

~~~
creshal
Yes. GTK on Windows is borderline useless unless you pour significant effort
into optimizing your program for it; and under OSX no amount of effort will
make it feel anywhere close to native.

~~~
pritambaral
I wonder how Deluge looks/feels on Windows or OS X. I've heard only good
things about its native looks, but haven't ever used it on anything but Linux.

~~~
Langdal
It looks OK, but it is easy to see that it is not native:
[http://i1-win.softpedia-
static.com/screenshots/Deluge_1.png](http://i1-win.softpedia-
static.com/screenshots/Deluge_1.png)

------
kensai
Very interesting indeed. It supports MacOS X which is a nice addition to my
other favorite, the IUP.

[http://webserver2.tecgraf.puc-rio.br/iup/](http://webserver2.tecgraf.puc-
rio.br/iup/)

~~~
jnbiche
Yes, IUP would have been the killer toolkit if it only supported OSX. I love
the IUP API in both C and Lua.

~~~
catwell
I wish it had good OS X support too.

The best hope so far is probably what's described in this email: [http://lua-
users.org/lists/lua-l/2016-03/msg00019.html](http://lua-
users.org/lists/lua-l/2016-03/msg00019.html)

------
register
I was looking for this for quite a long time. Choosing C allows one to bind
easily to a moltitude of "managed" languages. I Always found IUP
([http://webserver2.tecgraf.puc-rio.br/iup/](http://webserver2.tecgraf.puc-
rio.br/iup/)) approach very interesting but it lacks an OS X binding. I will
see how the two libraries compare one to each other.

------
MrBra
Excuse me for the following dumb question.

In past I've used Java/SWT and C#/WinForms. Both of those come with a concept
of the UI thread, which is the thread which you should use to read from and
write to the UI.

What I don't understand about these multiplatform libraries is: do they also
provide this mechanism, or are they actually only responsible for drawing the
widgets and forms, leaving to the developer (and the guest language they are
using to leverage the library) to implement that part through threads or some
different pattern (i.e. reactor pattern)?

------
ausjke
Very interesting. Just built it on ubuntu 16.04 smoothly, the only dependency
is gtk-3.0.

What's the difference between libui and libsdl? The latter is also in C and
supports many platforms. For large applications I may just use QT and for some
embedded GUI I can use libsdl, what's the goal for libui?

~~~
douche
SDL is pretty barebones, if you want to build a UI with it. You've got to
build up all your widgets yourself from scratch - rendering & compositing,
handling input events, etc.

SDL really shines in simple cross-platform abstractions - window creation,
basic rendering, input handling, threading, timers, basic audio, platform-
agnostic file handling, etc. The older version (1.2) also had extensions for
fonts, networking, and some other things, but I'm not sure if that applies for
2.0. Beats the snot out of messing with Win32 for getting started with game
programming.

~~~
FreeFull
SDL 2 still has the _gfx, _image, _mixer, _net and _ttf extensions available.
The only reason to still go with SDL 1.2 for anything new would be if you
still want to target old, obscure platforms.

------
nurettin
I've done my share of startness-upness and web development on both asp.net and
rails. After designing desktop user interfaces using various versions of
delphi, using visual and non-visual components that are bound to databases is
great ease. (optionally using an API layer to do server-side processing) the
amount of complexity, speed and ease of use you can cram into a single form
while remaining responsive and user-friendly compared to wizard-style web
pages is much staggering. The ability to step between dynamically loaded
libraries while debugging is such freedom.

Overall it was an easier and more productive development experience for me.

------
RustyRussell
I couldn't see how to do other things in the event loop. Like, waiting for
socket input. Did I miss it?

~~~
andlabs
I haven't implemented that, and I'm not sure how I would add support for
implementing that in a portable way without creating a complete networking
abstraction interface either... In the meantime, you could do your socket work
on a thread and use uiQueueMain() to send updates to the main thread.

------
c-smile
I was considering that approach (using native OS widgets) on initial stages of
my Sciter ([http://sciter.com](http://sciter.com)) development.

It didn't went through for the simple reason: set of common widgets in GUI
OSes is quite small: buttons, editboxes, selects and that is it. What about
menus, toolbars, treeviews/virtual lists, etc. etc. ?

So yes, you can do with that common set something extremely simple like
alert() or prompt() in browsers. But nothing close to full scale applications.

Yet graphic primitives... GDI on Windows does not know anything about alpha
channel or anti-aliasing... But CoreGraphics does. What would be the common
set in this case?

Again, idea of reusing OS widgets and native platform's look and feel in
multiplatform GUI toolkits is a perpetual dream of programmers since initial
version of Bible was written. wxWidgets or SWT are such examples.

But event they failed to achieve one of their primary goal - native platform's
look and feel. Does anyone know any wxWidget or SWT application that look
native on, say, OSX ?

So if you are designing application of "one red button 'Start'" then this
approach will work of course. But even in that case ... how to create really
red button in OSX? Or on Windows? You will want something custom drawn... but
you haven't common graphic primitives and so on.

------
swah
I guess Sublime Text uses something like this (custom made of course) and
everyone loves Sublime (at least regarding speed and cross platform good
looks).

------
infogulch
Working with Atom has opened my eyes to the idea that the web technologies are
the ultimate UI platform. HTML+CSS can build any user interface and allow
extreme customization.

Atom is slow and chromium a resource hog, but these are limitations of the
current implementations, not inherent to the technologies themselves. A Servo-
based UI toolkit with well thought out DOM bindings could solve both of these
problems spectacularly.

But I'm glad this exists and I'm excited to see a light cross platform UI
library that works across multiple OSes _and_ languages. I'll probably use
this for my future native UI needs.

~~~
c-smile
"Atom is slow and chromium a resource hog..." Check Sciter
([http://sciter.com](http://sciter.com)) then. It is single dll/so/dylib of
4-8mb without any external dependencies.

~~~
infogulch
Licensing & Prices > Indie+ (Windows, OS X, Linux versions) > $1260 + yearly
upgrade fee

> We have no intention to cover full CSS1/CSS2 attibute map.

Yeah that's not gonna work out for many projects.

~~~
c-smile
1\. there is a free version. 2\. "We have no intention to cover full CSS1/CSS2
attibute map." is a very old statement. CSS 2.1 is implemented in full.

~~~
infogulch
Thanks for refuting my first impressions. I may have to take a closer look
even though it's closed-source.

"is a very old statement". I found this from the home page: Developers >
Resources For ... > Web Programmers > CSS Property Map [0]. :)

Some questions. How does the render performance compare to modern browsers?
TIScript: why?

[0]:
[http://sciter.com/docs/content/css/cssmap.html](http://sciter.com/docs/content/css/cssmap.html)

~~~
c-smile
1\. Render performance.

On Windows Sciter uses Direct2D that is native H/W accelerated graphics
rendering layer. Yet it allows to render UI directly into DirectX surface :
[http://sciter.com/sciter-and-directx/](http://sciter.com/sciter-and-directx/)

2\. Why TIScript ?

Check "10 years road to Sciter" article:
[https://sciter.com/2014/07/](https://sciter.com/2014/07/)

------
red_admiral
The main thing holding me back from investigating this further is requiring
GTK3+ on linux, when my mint box works just fine with GTK2/Mate.

~~~
cm3
I can understand why the author interfaced with the Gtk API and also why they
thought Gtk3 is the right version, but Gtk3 - even at 3.20 - is full of
regressions, slow-downs and major themeing obstacles and breakage. Therefore,
I wish Qt would be chosen as the X (Linux, BSD) UI API instead by new
projects. Many big projects moved to Qt because of the aforementioned issues.

------
_pmf_
> that uses the native GUI technologies of each platform it supports.

WPF is native on Windows, Win32/WinForms is also native on Windows. I'm
assuming it uses Win32, although a third party FFI to WPF would be very, very
nice.

~~~
zuck9
Windows also has DirectUI, very alike WPF which it uses internally (and also
has some 3rd-party OSS implementations).

WinForms/Win32 is the first UI platform that Windows supported. It's getting
less used because of the new UI platforms.

I don't really understand how do they define WPF, UWP, XAML and DirectUI now
or how do they compare. XAML was the language used behind WPF but it seems
they have changed the terms.

The start menu in Windows 10 was created in XAML:
[https://news.ycombinator.com/item?id=9968679](https://news.ycombinator.com/item?id=9968679)

Edit: Found this:
[https://news.ycombinator.com/item?id=11498366](https://news.ycombinator.com/item?id=11498366)

~~~
mwcampbell
You mentioned third-party OSS implementations of DirectUI. Can you provide
links?

~~~
zuck9
[https://github.com/duilib/duilib](https://github.com/duilib/duilib)

------
lossolo
Btw cross platform Go GUI by the same author is based on that:

[https://github.com/andlabs/ui](https://github.com/andlabs/ui)

------
chris_wot
See
[https://news.ycombinator.com/item?id=11736127](https://news.ycombinator.com/item?id=11736127)

------
Rexxar
Why not make a pure C wrapper around wxWidgets ? It use native controls too
and it's not hard to make C call C++ code.

~~~
register
More easily said than done. Wxwidgets is itself already a wrapper over the
underlying C APIs provided by the OSes. This makes sense if the target
language is C++. But it is a real maintanace nightmare if the target is a
"managed" language. Then it must be de-wrapped as a C api and every time there
is a change in WxWidget it's probable that the C-inteface must be updated as
well. Having a straiforward C implementation reduces much of this maintanance
overhead.

------
jandrese

      Documentation
    
      Needs to be written. Consult ui.h and the examples for details for now.
    

:(

~~~
andlabs
It needs to be written because when I put that note down the API wasn't
stable. Now that it's mostly stable I can start writing the documentation,
which should be very detailed. There's already bits of it in the docs/ folder,
for a taste.

------
andlabs
Just a quick note: I will now be putting announcements and updates on the
README.

------
mzs
Can it handle printing too? That's a cross platform PITA too.

~~~
andlabs
That's planned, yes. (I have to do it anyway, because in most cases it's the
print dialog that gives you the printer device cntext...) This is also why
it's uiDrawContext, not uiAreaDrawContext.

------
childintime
Rust needs this

------
kodfodrasz
Why would anyone write a GUI app in C? Almost every alternative is better for
the job.

~~~
accatyyc
How so? The likely reason is that a C lib is usable from many other
environments. Look at ncurses for example. Heavily used from many languages,
and written in C.

Another reason is that the underlying tools used by this library are likely in
C as well, so it's probably the easiest language to use for the task.

~~~
kodfodrasz
Ok, but my question was not about FFI, but writing a GUI app...

~~~
samuellb
C is easy to package and distribute. I once built a Python + GTK application
for a school project. On Ubuntu that was no problem at all, but on Windows it
was a complete mess because I had to bundle Python + GTK for Windows + all
their dependencies. I think the result was around 200 MB of dependencies and
~100 kB of actual Python code. C + libui would have been much better in this
regard.

------
blub
This is so funny. Yesterday there was another discussion on how C needs to be
replaced due to security/corectness concerns (the K&R topic), today people are
fascinated by a UI(!!!) library built in it.

And they actually consider using this library.

~~~
accatyyc
C is simply the Correct Tool For the Job when writing cross-platform (native)
UI's. It's simple, it's callable from almost any other language, and all OS
GUI API's are already in C.

There has been a lot of negativity/arguments against C here lately, which in
my opinion has been very exaggerated.

Seriously, how often do you guys write GUI apps that _also need to be secure_?
An application isn't secure just because you write it in another language,
there's a lot more work to it. If there is even such a thing as secure.

~~~
kodfodrasz
Any app i write needs to be secure as much as reasonably possible.

If you communicate over a Network with not fully trusted remote endpoints, and
handle text you have a fair chance of remote code execution in C. A git front
end. A text editor. Anything written in C has a fair chance to making a
mistake.

Your very basic attitude is an example to the problem the industry is having!

We will always make mistakes, no matter how hard we try, but not caring for
such an important topic from upstart is a not simply a mistake, but an
outright sin!

Security, robustness are some examples which are way too hard to add to a
software when not taken into account upfront at design time!

C is not the right tool for these tasks.

~~~
accatyyc
I'm not really sure I agree with communicating over the network in your GUI
anyway. A git frontend shouldn't handle the connections, this is what libgit
is for. Which would probably use curl or similar internally. Both of those are
written in C, and are also reasonably secure as far as I know.

I stand by my point. Simply "not using C" isn't magically going to make your
application so much more secure.

~~~
kodfodrasz
Ok, so that example maybe was not perfect. So what? Many apps nowadays talk
with remote APIs. Imagine a twitter client, a SCADA app, pretty much anything
nowadays, instead of nitpicking. Btw when you use libraries written in C that
very much the same as communicating over the network from your app. Same
process, same address space.

Also note: local files may also be rigged... Other languages protect for whole
classes of vulnerabilities with negligible costs.

About the reasonable security: [http://www.tripwire.com/state-of-
security/latest-security-ne...](http://www.tripwire.com/state-of-
security/latest-security-news/critical-git-vulnerability-allows-for-remote-
code-execution/)

[https://curl.haxx.se/docs/vulnerabilities.html](https://curl.haxx.se/docs/vulnerabilities.html)
(Kudos to the curl authors for this nice overview!)

------
hoodoof
I was recently thinking that operating systems should ditch their custom
desktops in favor of a browser based UI.

Microsoft tried this idea out and it didn't work a few years back but it still
seems to me that a browser based OS UI would be far more effective than things
like Gnome and KDE and all that stuff.

Edit: well I guess Google had the same idea long ago and called it ChromeOS -
browser as OS interface.

~~~
skoczymroczny
We would have to probably ditch the content creation applications we have
right now too. I mean, Electron and web based apps are nice for stuff like a
weather widget, simple music player or a gallery application, but I don't see
it being used for 3D editing applications, audio editing applications and
similar uses. There aren't even any good UI frameworks for doing html desktop
like looking applications, most are designed for mobile with their big buttons
and touch optimization.

~~~
roywiggins
> 3D editing applications

You can do 3D editing on the web, at least in a fairly basic way.

[http://threejs.org/editor/](http://threejs.org/editor/)

~~~
feiss
[https://clara.io/](https://clara.io/)

