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.. ;)
> [...] 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?
It's not a new approach, though. SWT (for the JVM) and wxWidgets (C++, with bindings for more than a dozen languages) have been following it for years.
I think this is useful when you need simple dialogs. For example if you want to display a license agreement, or similar. It is overkill to bundle Qt libs to display simple dialogs.
But if you want a complex and powerful UI toolkit (let's say you want to create an editor), you need a toolkit like Qt.
You can't do that with just wrappers to native toolkits. You will only get the greatest common divisor.
Had some troubles compiling on OSX Mavericks, but now that I've just tested it, it sure looks 100% native to me and perfectly integrates with the platform (file dialogs, osx font dialog, etc.) and much much better and lighter than Qt and other cross-platform tools I've been using so far.
I'm definitely going to try to implement a python wrapper around this as it seems usable enough as it is now.. :)
I have to partially disagree. With stuff like webapps or Electron, we still have the same GUI on all platforms rather than using the native widgets. Also JavaFX is drawing it's widgets themselves, and I wouldn't call JavaFX 'old days'.
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.
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.
The OS probably won't do the heavy lifting for a text editor. Native text controls/widgets are sufficient for simple tasks (like this textarea I'm using right now), but for anything more complicated, editor authors usually have to implement their own stuff. And that quickly gets really complicated... (still not as bad as a full-blown HTML renderer/layout engine/scripting system -- usually).
I actually think that CSS is better for drawing with modern GPUs than native UI frameworks are. CSS is declarative, which enables global optimizations--very important on GPUs, where state changes are expensive and overdraw hurts. By contrast, native UI frameworks were designed for slow CPU rendering in the '90s via legacy APIs like GDI.
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.
It's built out of small chunks of C code:
https://github.com/eclipse/eclipse.platform.swt/search?p=1&q...
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.
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
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.
>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:
I've tried to stay away from the "web tech on the desktop" trend. network-connected/cloud apps are great, but the current web tech does nothing to solve it.
Things like atom inherit js etc. which gains a little bit of speed up and familiarity, but also performance overheads and complexity.
Not actually good, js-devs are the worst for a kind of NIH and low cross-pollination. Sometimes, a string custom and/or C-API is the nest for bringing in multiple communities.
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...
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.
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.
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/) approach very interesting but it lacks an OS X binding. I will see how the two libraries compare one to each other.
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)?
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?
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.
The way I understood it, libui is a widget toolkit (e.g. GTK, wxWidgets, Qt, etc) -- while SDL is low-level library to handle drawing, input (i.e. you'd need to implement your own widgets using the low-level primitives that are available to you).
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.
I was considering that approach (using native OS widgets) on initial stages of my Sciter (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.
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).
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.
"Atom is slow and chromium a resource hog..."
Check Sciter (http://sciter.com) then. It is single dll/so/dylib of 4-8mb without any external dependencies.
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.
> 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.
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.
Just using WPF controls without having access to the features that WPF provides is kinda pointless, though. Also nearly (?) all other platform-native toolkits use simple immediate-mode rendering, while WPF heavily uses templates and retained-mode vector graphics, so abstracting away custom drawing code for controls might prove a bit hard, for example.
If you only have a button and a text field and want to make stuff happen when the button is clicked, then I doubt there is any difference in whether it uses Win32 or WPF.
[+] [-] jventura|9 years ago|reply
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|9 years ago|reply
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?
[+] [-] icebraining|9 years ago|reply
[+] [-] riq_|9 years ago|reply
But if you want a complex and powerful UI toolkit (let's say you want to create an editor), you need a toolkit like Qt. You can't do that with just wrappers to native toolkits. You will only get the greatest common divisor.
[+] [-] jventura|9 years ago|reply
I'm definitely going to try to implement a python wrapper around this as it seems usable enough as it is now.. :)
[+] [-] skoczymroczny|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] striking|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] Arnt|9 years ago|reply
What's old is eventually new again.
[+] [-] mhd|9 years ago|reply
[+] [-] atilaneves|9 years ago|reply
[+] [-] pcwalton|9 years ago|reply
[+] [-] etwigg|9 years ago|reply
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/
- From Jython: https://github.com/danathughes/jythonSWT
- From JRuby: https://github.com/neelance/swt4ruby
- From C++ (defunct): 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... 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|9 years ago|reply
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."
[+] [-] apayan|9 years ago|reply
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.
[+] [-] pjmlp|9 years ago|reply
I only use web applications when there isn't a native alternative that I can make use of.
Actually I moved back to the world of native applications and there is plenty of work.
[+] [-] fit2rule|9 years ago|reply
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/makotok/Hanappe 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...)
[+] [-] Chris2048|9 years ago|reply
Things like atom inherit js etc. which gains a little bit of speed up and familiarity, but also performance overheads and complexity.
Not actually good, js-devs are the worst for a kind of NIH and low cross-pollination. Sometimes, a string custom and/or C-API is the nest for bringing in multiple communities.
[+] [-] fithisux|9 years ago|reply
[+] [-] hoodoof|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] gbugniot|9 years ago|reply
[+] [-] tomc1985|9 years ago|reply
[+] [-] aksx|9 years ago|reply
[+] [-] laurentoget|9 years ago|reply
That said I do not know of any cross platform library in C, so this does seem to fill a niche.
[+] [-] geon|9 years ago|reply
Why? Release early and get feedback. Backward compatibility isn't holy. And it's just an alpha. No one expects the api to be stable.
[+] [-] zem|9 years ago|reply
[+] [-] kensai|9 years ago|reply
http://webserver2.tecgraf.puc-rio.br/iup/
[+] [-] jnbiche|9 years ago|reply
[+] [-] register|9 years ago|reply
[+] [-] MrBra|9 years ago|reply
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|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] maheart|9 years ago|reply
The way I understood it, libui is a widget toolkit (e.g. GTK, wxWidgets, Qt, etc) -- while SDL is low-level library to handle drawing, input (i.e. you'd need to implement your own widgets using the low-level primitives that are available to you).
[+] [-] nurettin|9 years ago|reply
Overall it was an easier and more productive development experience for me.
[+] [-] RustyRussell|9 years ago|reply
[+] [-] c-smile|9 years ago|reply
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|9 years ago|reply
[+] [-] infogulch|9 years ago|reply
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|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] red_admiral|9 years ago|reply
[+] [-] cm3|9 years ago|reply
[+] [-] _pmf_|9 years ago|reply
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|9 years ago|reply
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
Edit: Found this: https://news.ycombinator.com/item?id=11498366
[+] [-] ygra|9 years ago|reply
If you only have a button and a text field and want to make stuff happen when the button is clicked, then I doubt there is any difference in whether it uses Win32 or WPF.
[+] [-] userbinator|9 years ago|reply
[+] [-] lossolo|9 years ago|reply
https://github.com/andlabs/ui
[+] [-] chris_wot|9 years ago|reply