12 ms·

Libui: GUI library in C

373 points by avitex 10y ago

ausjke 10y ago
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?
- maheart 10y ago
  > What's the difference between libui and libsdl? 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).
  - striking 10y ago
    SDL isn't quite "lower-level"; it used to stand for Simple Directmedia Layer. It's a layer over some common drawing operations and the instantiation of a window. So you get a box you can draw in, and that's it. Then you're allowed to poke pixels until you get what you want. It's not that you're poking a lower level (which would be akin to directly blitting to the screen buffer like an old-timey OS), it's that you're poking a different level (creating a new context and performing operations on it, via GDI+ or OpenGL or whatever). You trade one set of primitives for another.
    - admax88q 10y ago
      It's absolutely lower-level. How do you think those widgets get drawn in the end? Via primitive operations like GDI+/OpenGL or just bit blits. GUI Widgets are a higher level of abstraction on top of pixels. SDL gives you pixels or an OpenGL context which gives you a slightly abstracted way of rendering pixels.
      - ausjke 10y ago
        Then if libui supports libsdl as it does to gtk-3.0 it would be nice, as gtk-3.0 is still quite heavy for many embedded systems. libui is based on C, and it is not really suited to compete with the c++/java full GUIs on Desktops, so supporting libsdl will certainly expand its usage.
- douche 10y ago
  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 10y ago
    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.
striking 10y ago
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 10y ago
  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.
  - register 10y ago
    This is not the same approach. Wxwidget is C++ which makes binding to other languages cumbersome. The same applies also to TK which is binded trough an embedded TCL interpreter.
    - sdx23 10y ago
      Also TK doesn't offer native looks. Wx tries, though I'm not sure how good taking into account all platforms.
      - networked 10y ago
        Since version 8.5 Tk ships with themed widgets that by default try to look native on Windows and OS X by leveraging the respective platforms' native GUI toolkits for drawing. For the details see https://tcl.wiki/14796 https://tcl.wiki/14796.
      - creshal 10y ago
kensai 10y ago
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 10y ago
  Yes, IUP would have been the killer toolkit if it only supported OSX. I love the IUP API in both C and Lua.
  - catwell 10y ago
    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
  - biokoda 10y ago
    Would have been better if they added OSX support to IUP and not re implement an entire toolkit.
kodfodrasz 10y ago
Why would anyone write a GUI app in C? Almost every alternative is better for the job.
- gbugniot 10y ago
  Performance?
  - kodfodrasz 10y ago
    The FFI reasonings are OK, I understand them. I didn't think in those terms originally. (Thought I asked about writing a C app not a C library...) But speed and C are othogonal nowadays (at least if productivity is in the picture). It is so much simpler to write correct programs leveraging multicore environments an/or asynchronity in other environments, that it is not productive to chose C for speed. (In terms of development costs. Ofc. there are special cases when it might be worth, I'm talking about the general situation)
    - creshal 10y ago
      > Thought I asked about writing a C app not a C library... libui is mainly intended for FFI use with Go. Writing GUI apps in C is a pain in the ass, yes.
- accatyyc 10y ago
  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 10y ago
    Ok, but my question was not about FFI, but writing a GUI app...
hoodoof 10y ago
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...
- gbugniot 10y ago
  I guess what makes Libui interesting is its C language implementation.
  - hoodoof 10y ago
    juce is C++ https://www.juce.com/learn/coding-standards https://www.juce.com/learn/coding-standards
    - ori_b 10y ago
      And Swing is Java. So? C and C++ are not the same, by a long shot.
- aksx 10y ago
  Juce is a great library but it doesn't target the native feel (last time i checked) which libui does.
- douche 10y ago
  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.
  - hoodoof 10y ago
    I have to say I agree. The old site was plain and simple and straightforward. I think a site can look great but doesn't need to be overly fancy. (says me, now I'll get back to implementing that fancy UI feature).
hoodoof 10y ago
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.
- khedoros 10y ago
  > I was recently thinking that operating systems should ditch their custom desktops in favor of a browser based UI. Why? > 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. How so? My needs haven't changed. I still need a UI that provides a searchable launch menu, some quick-launch buttons, window management, etc. Rendering a bunch of things through a browser doesn't do that for me any better than rendering those things through some C libraries.
  - stevenhuang 10y ago
    because we're on the topic of cross-platform UI frameworks.
    - khedoros 10y ago
      Fine, fine. But why specifically a browser-based UI? I'd think you'd make a jump like that to solve a particular problem. From hoodoof's reply, they think that current Linux desktop design is "shit", and that the solution could be to replace the desktop with a different piece of technology. Not a sentiment that I agree with, but it's a reasonable answer to my question. Still, taken as a given: Linux desktop design could use some work. Or at least the themes and icon sets.
  - hoodoof 10y ago
    >>Why? Because somehow websites end up (can end up) looking great, but all those Linux desktops look shit. Things don't line up, the margins and spacing are wrong. It looks like it's made from a set of ill fitting phony knockoff lego bits that don't fit together. If web browsers make it possible to design slick interfaces then the Linux desktop folks should get onto that quick smart. Having said that, I guess that's what ChromeOS is eh?
register 10y ago
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.
laurentoget 10y ago
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 10y ago
  Umm, Gtk?
  - geon 10y ago
    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 10y ago
      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 10y ago
        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 10y ago
        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
  - tehrei 10y ago
    Gtk (at least from 3 onwards) doesn't even aim to be cross-desktop on Linux, let alone cross-platform. Meaning, your gtk apps will always look and behave according to the Gnome conventions on all platforms, which could be what you want, depending on what cool-aid you're drinking ;) .
blub 10y ago
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.
- kodfodrasz 10y ago
  My feelings exactly. (thus my question above)
- accatyyc 10y ago
  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 10y ago
    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 10y ago
      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.
nurettin 10y ago
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.
apayan 10y ago
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.
- fithisux 10y ago
  Me too
- Chris2048 10y ago
  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.
- fit2rule 10y ago
  >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 10y ago
    A simple write up with screenshots or something would be nice.
_pmf_ 10y ago
> 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.
- ygra 10y ago
  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.
- zuck9 10y ago
  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 10y ago
    You mentioned third-party OSS implementations of DirectUI. Can you provide links?
    - zuck9 10y ago
      https://github.com/duilib/duilib https://github.com/duilib/duilib
- 10y ago
chris_wot 10y ago
See https://news.ycombinator.com/item?id=11736127 https://news.ycombinator.com/item?id=11736127
jventura 10y ago
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.. ;)
- icebraining 10y ago
  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.
  - register 10y ago
    The main difference is the License which is much more liberal in this case. Also binding C++ code requires wrapping the code trough a C interface which is really a pain; especially when considering the the underlying OS APIs have a C root.
  - jventura 10y ago
    In my opinion, things such as Qt, WxWidgets, etc., which are implemented in C++ are from the time that C++ was supposed to be the breakthrough language. So these toolkits only targeted C++ in the same way that SWT was mostly thought for Java (although it may have been written in C or C++, I don't know). This library seems to be implemented in C so that higher level languages can make use of it. C is much simpler to interface than C++. For instance, you mention WxWidgets, but that thing is so god-damn complex that there's still no stable WxPython for pyhton 3.. I really hope that this libui stays as just a simple simple thin wrapper so that we can build complex things no top of it in each language. For instance, python guys may create a declarative framework on top of this while lisp/haskell guys may create a Functional Reactive "thing" on top of it. As long as libui stays simple enough, everyone can extended it in ways that make sense for their own languages..
red_admiral 10y ago
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 10y ago
  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.
etwigg 10y ago
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=extension%3A.c&type=Code&utf8=%E2%9C%93 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 10y ago
  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 10y ago
    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.
Rexxar 10y ago
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 10y ago
  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.
deleted 10y ago
[deleted]
MrBra 10y ago
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)?
RustyRussell 10y ago
I couldn't see how to do other things in the event loop. Like, waiting for socket input. Did I miss it?
- andlabs 10y ago
  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.
lossolo 10y ago
Btw cross platform Go GUI by the same author is based on that: https://github.com/andlabs/ui https://github.com/andlabs/ui
swah 10y ago
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).
mzs 10y ago
Can it handle printing too? That's a cross platform PITA too.
- andlabs 10y ago
  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 10y ago
Rust needs this
infogulch 10y ago
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 10y ago
  "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 10y ago
    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 10y ago
      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 10y ago
        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
jandrese 10y ago
Documentation Needs to be written. Consult ui.h and the examples for details for now. :(
- andlabs 10y ago
  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.
c-smile 10y ago
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.
andlabs 10y ago
Just a quick note: I will now be putting announcements and updates on the README.

373 points by avitex 10y ago

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?

maheart 10y ago
> What's the difference between libui and libsdl? 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).
- striking 10y ago
  SDL isn't quite "lower-level"; it used to stand for Simple Directmedia Layer. It's a layer over some common drawing operations and the instantiation of a window. So you get a box you can draw in, and that's it. Then you're allowed to poke pixels until you get what you want. It's not that you're poking a lower level (which would be akin to directly blitting to the screen buffer like an old-timey OS), it's that you're poking a different level (creating a new context and performing operations on it, via GDI+ or OpenGL or whatever). You trade one set of primitives for another.
  - admax88q 10y ago
    It's absolutely lower-level. How do you think those widgets get drawn in the end? Via primitive operations like GDI+/OpenGL or just bit blits. GUI Widgets are a higher level of abstraction on top of pixels. SDL gives you pixels or an OpenGL context which gives you a slightly abstracted way of rendering pixels.
    - ausjke 10y ago
      Then if libui supports libsdl as it does to gtk-3.0 it would be nice, as gtk-3.0 is still quite heavy for many embedded systems. libui is based on C, and it is not really suited to compete with the c++/java full GUIs on Desktops, so supporting libsdl will certainly expand its usage.
douche 10y ago
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 10y ago
  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.

striking 10y ago

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 10y ago
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.
- register 10y ago
  This is not the same approach. Wxwidget is C++ which makes binding to other languages cumbersome. The same applies also to TK which is binded trough an embedded TCL interpreter.
  - sdx23 10y ago
    Also TK doesn't offer native looks. Wx tries, though I'm not sure how good taking into account all platforms.
    - networked 10y ago
      Since version 8.5 Tk ships with themed widgets that by default try to look native on Windows and OS X by leveraging the respective platforms' native GUI toolkits for drawing. For the details see https://tcl.wiki/14796 https://tcl.wiki/14796.
    - creshal 10y ago

kensai 10y ago

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 10y ago
Yes, IUP would have been the killer toolkit if it only supported OSX. I love the IUP API in both C and Lua.
- catwell 10y ago
  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
- biokoda 10y ago
  Would have been better if they added OSX support to IUP and not re implement an entire toolkit.

kodfodrasz 10y ago

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

gbugniot 10y ago
Performance?
- kodfodrasz 10y ago
  The FFI reasonings are OK, I understand them. I didn't think in those terms originally. (Thought I asked about writing a C app not a C library...) But speed and C are othogonal nowadays (at least if productivity is in the picture). It is so much simpler to write correct programs leveraging multicore environments an/or asynchronity in other environments, that it is not productive to chose C for speed. (In terms of development costs. Ofc. there are special cases when it might be worth, I'm talking about the general situation)
  - creshal 10y ago
    > Thought I asked about writing a C app not a C library... libui is mainly intended for FFI use with Go. Writing GUI apps in C is a pain in the ass, yes.
accatyyc 10y ago
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 10y ago
  Ok, but my question was not about FFI, but writing a GUI app...

hoodoof 10y ago

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

gbugniot 10y ago
I guess what makes Libui interesting is its C language implementation.
- hoodoof 10y ago
  juce is C++ https://www.juce.com/learn/coding-standards https://www.juce.com/learn/coding-standards
  - ori_b 10y ago
    And Swing is Java. So? C and C++ are not the same, by a long shot.
aksx 10y ago
Juce is a great library but it doesn't target the native feel (last time i checked) which libui does.
douche 10y ago
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.
- hoodoof 10y ago
  I have to say I agree. The old site was plain and simple and straightforward. I think a site can look great but doesn't need to be overly fancy. (says me, now I'll get back to implementing that fancy UI feature).

hoodoof 10y ago

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.

khedoros 10y ago
> I was recently thinking that operating systems should ditch their custom desktops in favor of a browser based UI. Why? > 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. How so? My needs haven't changed. I still need a UI that provides a searchable launch menu, some quick-launch buttons, window management, etc. Rendering a bunch of things through a browser doesn't do that for me any better than rendering those things through some C libraries.
- stevenhuang 10y ago
  because we're on the topic of cross-platform UI frameworks.
  - khedoros 10y ago
    Fine, fine. But why specifically a browser-based UI? I'd think you'd make a jump like that to solve a particular problem. From hoodoof's reply, they think that current Linux desktop design is "shit", and that the solution could be to replace the desktop with a different piece of technology. Not a sentiment that I agree with, but it's a reasonable answer to my question. Still, taken as a given: Linux desktop design could use some work. Or at least the themes and icon sets.
- hoodoof 10y ago
  >>Why? Because somehow websites end up (can end up) looking great, but all those Linux desktops look shit. Things don't line up, the margins and spacing are wrong. It looks like it's made from a set of ill fitting phony knockoff lego bits that don't fit together. If web browsers make it possible to design slick interfaces then the Linux desktop folks should get onto that quick smart. Having said that, I guess that's what ChromeOS is eh?

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.

laurentoget 10y ago

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 10y ago
Umm, Gtk?
- geon 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        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
- tehrei 10y ago
  Gtk (at least from 3 onwards) doesn't even aim to be cross-desktop on Linux, let alone cross-platform. Meaning, your gtk apps will always look and behave according to the Gnome conventions on all platforms, which could be what you want, depending on what cool-aid you're drinking ;) .

blub 10y ago

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.

kodfodrasz 10y ago
My feelings exactly. (thus my question above)
accatyyc 10y ago
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 10y ago
  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 10y ago
    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.

nurettin 10y ago

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.

apayan 10y ago

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.

fithisux 10y ago
Me too
Chris2048 10y ago
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.
fit2rule 10y ago
>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 10y ago
  A simple write up with screenshots or something would be nice.

_pmf_ 10y ago

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

ygra 10y ago
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.
zuck9 10y ago
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 10y ago
  You mentioned third-party OSS implementations of DirectUI. Can you provide links?
  - zuck9 10y ago
    https://github.com/duilib/duilib https://github.com/duilib/duilib
10y ago

chris_wot 10y ago

See https://news.ycombinator.com/item?id=11736127 https://news.ycombinator.com/item?id=11736127

jventura 10y ago

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.. ;)

icebraining 10y ago
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.
- register 10y ago
  The main difference is the License which is much more liberal in this case. Also binding C++ code requires wrapping the code trough a C interface which is really a pain; especially when considering the the underlying OS APIs have a C root.
- jventura 10y ago
  In my opinion, things such as Qt, WxWidgets, etc., which are implemented in C++ are from the time that C++ was supposed to be the breakthrough language. So these toolkits only targeted C++ in the same way that SWT was mostly thought for Java (although it may have been written in C or C++, I don't know). This library seems to be implemented in C so that higher level languages can make use of it. C is much simpler to interface than C++. For instance, you mention WxWidgets, but that thing is so god-damn complex that there's still no stable WxPython for pyhton 3.. I really hope that this libui stays as just a simple simple thin wrapper so that we can build complex things no top of it in each language. For instance, python guys may create a declarative framework on top of this while lisp/haskell guys may create a Functional Reactive "thing" on top of it. As long as libui stays simple enough, everyone can extended it in ways that make sense for their own languages..

red_admiral 10y ago

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

etwigg 10y ago

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=extension%3A.c&type=Code&utf8=%E2%9C%93 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 10y ago
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 10y ago
  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.

Rexxar 10y ago

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

deleted 10y ago

[deleted]

MrBra 10y ago

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)?

RustyRussell 10y ago

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

andlabs 10y ago
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.

lossolo 10y ago

Btw cross platform Go GUI by the same author is based on that: https://github.com/andlabs/ui https://github.com/andlabs/ui

swah 10y ago

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

mzs 10y ago

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

andlabs 10y ago
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 10y ago

Rust needs this

infogulch 10y ago

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 10y ago
"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 10y ago
  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 10y ago
    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 10y ago
      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

jandrese 10y ago

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

andlabs 10y ago
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.

c-smile 10y ago

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.

andlabs 10y ago

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