Live data from Hacker News

Libui: GUI library in C

github.com

91–100 of 186 posts

Re: Libui: GUI library in C

#91
post #16

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.

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

I can think of 3 web-based creation tools that are quite powerful: * SoundTrap for audio editing: https://soundtrap.com * Clara.io for 3d modeling: https://clara.io * OnShape for CAD modeling: https://onshape.com

They shine especially on collaboration and sharing functionalities.

Re: Libui: GUI library in C

#92
post #33

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

Re: Libui: GUI library in C

#93

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 themsel…

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

Qt simply works better. I saw GTK showing many artifact and/or working at glacial speed when buggy drivers or SVGA driver (not 2D acceleration) are in. However Qt works flawless on the same situation, even with some nice FX working.

Re: Libui: GUI library in C

#94
post #56
post #6

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/

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

Would have been better if they added OSX support to IUP and not re implement an entire toolkit.

Re: Libui: GUI library in C

#95

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 themsel…

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

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

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

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

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

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

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

Re: Libui: GUI library in C

#96
post #65

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:/…

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

Re: Libui: GUI library in C

#97

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 themsel…

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

Re: Libui: GUI library in C

#98

Earlier quoted context omitted.

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 matt…

1) The rules for hardening 'C' based applications aren't exactly obscure nor are they new. 2) Some things very much need to never be on a wider network with untrusted nodes. This is easier than it sounds...

They are not new, I agree, I have been writing such programs for a few years. Looking back to those times make me say that C should be avoided for such tasks.

Re: Libui: GUI library in C

#99
post #70
post #38

Earlier quoted context omitted.

Also TK doesn't offer native looks. Wx tries, though I'm not sure how good taking into account all platforms.

Wx tries, but IMO fails to varying degrees to feel "right". WxGTK in Linux is okay-ish (everyone expects shitty UX from GTK programs anyway); WxMSW is an eye-sore. I haven't dared using Wx under OSX yet.

Can you elaborate on your points? including this one:

>WxMSW is an eye-sore

Re: Libui: GUI library in C

#100

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 themsel…

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'.
Post reply on HN