8 ms·

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 na

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..
  - Mikhail_Edoshin 10y ago
    The library has a C interface, but the underlying implementation varies: Objective-C for Mac OS X, C++ for Windows, and C for Linux.
- warmwaffles 10y ago
  I guess it's the proverbial "Simpsons did it" in which case, I don't care and I like to see people tinkering with ideas rather than just settling.
- radarsat1 10y ago
  Actually SWT was one of the most pleasant experiences I've had coding GUI stuff. I always found it such a shame that it's only possible to use within the Java ecosystem. I really wanted an interface to the SWT binary libraries from other languages, I looked into it but it seemed intractable to port. If this library takes a similar approach it's probably doing something right.
  - mwcampbell 10y ago
    SWT itself is written in Java. The native libraries are super-thin JNI wrappers for the underlying OS APIs. I did a project last year where I wanted to use SWT, but I wanted to write the program in Python, and use CPython rather than Jython so I could have access to C extension modules like lxml. So I hacked up a solution using the Avian lightweight JVM and the pyjnius JNI-based Python/JVM bridge from the Kivy project. I should release that sometime.
distances 10y ago
> [...] 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?
- blub 10y ago
  Qt is better supported and easier to use compared to GTK. It's also probably the best cross-platform toolkit one can get right now. Was surprised to hear that even Linus got sick of dealing with GTK and ported Subsurface to Qt, but that's how it is.
  - audidude 10y ago
    Contrary to what people seem to think, just because GTK+ compiles on Windows and OSX, doesn't mean we are trying to be a cross-platform toolkit. Many GTK+ developers consider GTK+ to be a platform in it's own right, not a portability layer.
    - Koromix 10y ago
      I understand this, even though the constant breaking of GTK apps after each update annoys me to no end. But you might want to discuss updating https://www.gtk.org/ https://www.gtk.org/ and other sites for that matter. Quoting the first lines of the home page: "GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces".
      - audidude 10y ago
        If your platform is X11, Wayland, or Mir :)
        Koromix 10y ago
jventura 10y ago
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.. :)
- andlabs 10y ago
  What trouble?
  - jventura 10y ago
    https://github.com/andlabs/libui/issues/24 https://github.com/andlabs/libui/issues/24
- jventura 10y ago
  Started pylibui at https://github.com/joaoventura/pylibui https://github.com/joaoventura/pylibui. Pretty barebones for now, but hey, it shows a window!
skoczymroczny 10y ago
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'.
- jventura 10y ago
  I've been professionally developing full stack web products for some years now, and as much as I like the web, it is indeed too cumbersome to implement complex things on it. For instance, my previous company just laid off some 4/5 developers mainly because the web app they were (re)building sucks big time.. Electron is seen as a great thing because it allows web developers to finally come back to desktop. But what about we guys that learned how to build products directly for the desktop? We do not need Electron. We may need a web view to render something on it, but not Electron specifically. Finally, as someone trying to build something to sell, I do not want the same GUI on all platforms, I just want something that looks native in each platform (not giant web buttons, for instance) and that allows me to share many components of a codebase.
riq_ 10y ago
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.
- jventura 10y ago
  I don't know how far one can go with this approach, but if this project works, I believe one could built on top of it to create more powerful UI toolkits. The advantage would be that, unlike things such as Qt and GTK which draw their own widgets on top of (I think) a OpenGL "canvas", this one uses the platform native UI widgets.. Tl-dr: this approach is lighter and sanner because it leaves the "drawing" burden to the OS itself..
deleted 10y ago
[deleted]

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..
- Mikhail_Edoshin 10y ago
  The library has a C interface, but the underlying implementation varies: Objective-C for Mac OS X, C++ for Windows, and C for Linux.
warmwaffles 10y ago
I guess it's the proverbial "Simpsons did it" in which case, I don't care and I like to see people tinkering with ideas rather than just settling.
radarsat1 10y ago
Actually SWT was one of the most pleasant experiences I've had coding GUI stuff. I always found it such a shame that it's only possible to use within the Java ecosystem. I really wanted an interface to the SWT binary libraries from other languages, I looked into it but it seemed intractable to port. If this library takes a similar approach it's probably doing something right.
- mwcampbell 10y ago
  SWT itself is written in Java. The native libraries are super-thin JNI wrappers for the underlying OS APIs. I did a project last year where I wanted to use SWT, but I wanted to write the program in Python, and use CPython rather than Jython so I could have access to C extension modules like lxml. So I hacked up a solution using the Avian lightweight JVM and the pyjnius JNI-based Python/JVM bridge from the Kivy project. I should release that sometime.

distances 10y ago

> [...] 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?

blub 10y ago
Qt is better supported and easier to use compared to GTK. It's also probably the best cross-platform toolkit one can get right now. Was surprised to hear that even Linus got sick of dealing with GTK and ported Subsurface to Qt, but that's how it is.
- audidude 10y ago
  Contrary to what people seem to think, just because GTK+ compiles on Windows and OSX, doesn't mean we are trying to be a cross-platform toolkit. Many GTK+ developers consider GTK+ to be a platform in it's own right, not a portability layer.
  - Koromix 10y ago
    I understand this, even though the constant breaking of GTK apps after each update annoys me to no end. But you might want to discuss updating https://www.gtk.org/ https://www.gtk.org/ and other sites for that matter. Quoting the first lines of the home page: "GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces".
    - audidude 10y ago
      If your platform is X11, Wayland, or Mir :)
      - Koromix 10y ago

jventura 10y ago

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

andlabs 10y ago
What trouble?
- jventura 10y ago
  https://github.com/andlabs/libui/issues/24 https://github.com/andlabs/libui/issues/24
jventura 10y ago
Started pylibui at https://github.com/joaoventura/pylibui https://github.com/joaoventura/pylibui. Pretty barebones for now, but hey, it shows a window!

skoczymroczny 10y ago

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

jventura 10y ago
I've been professionally developing full stack web products for some years now, and as much as I like the web, it is indeed too cumbersome to implement complex things on it. For instance, my previous company just laid off some 4/5 developers mainly because the web app they were (re)building sucks big time.. Electron is seen as a great thing because it allows web developers to finally come back to desktop. But what about we guys that learned how to build products directly for the desktop? We do not need Electron. We may need a web view to render something on it, but not Electron specifically. Finally, as someone trying to build something to sell, I do not want the same GUI on all platforms, I just want something that looks native in each platform (not giant web buttons, for instance) and that allows me to share many components of a codebase.

riq_ 10y ago

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.

jventura 10y ago
I don't know how far one can go with this approach, but if this project works, I believe one could built on top of it to create more powerful UI toolkits. The advantage would be that, unlike things such as Qt and GTK which draw their own widgets on top of (I think) a OpenGL "canvas", this one uses the platform native UI widgets.. Tl-dr: this approach is lighter and sanner because it leaves the "drawing" burden to the OS itself..

deleted 10y ago

[deleted]