Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Libui: GUI library in C

github.com

Post reply on HN
Print view View original

111–120 of 186 posts

Re: Libui: GUI library in C

#111

Post by twotavol »

fit2rule wrote: post #108
apayan wrote: 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 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 (t…

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

Re: Libui: GUI library in C

#112

Post by Langdal »

pritambaral wrote: post #77
creshal wrote: post #71

Earlier quoted context omitted.

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.

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.

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

Re: Libui: GUI library in C

#113

Post by Mikhail_Edoshin »

jventura wrote: post #85
icebraining wrote: post #69

Earlier quoted context omitted.

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.

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

The library has a C interface, but the underlying implementation varies: Objective-C for Mac OS X, C++ for Windows, and C for Linux.

Re: Libui: GUI library in C

#114

Post by pjmlp »

apayan wrote: 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.

Call me old fashion, but it never went away.

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.

Re: Libui: GUI library in C

#115

Post by MrBra »

Excuse me for the following dumb question.

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

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

Re: Libui: GUI library in C

#116

Post by userbinator »

_pmf_ wrote: post #37

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

WPF and WinForms are not really "native"; they're .NET, which I believe eventually goes to Win32. Win32 is the real native UI of Windows.

Re: Libui: GUI library in C

#118

Post by audidude »

twotavol wrote: post #109
audidude wrote: post #103

Earlier quoted context omitted.

> It's also getting slower at each release, it keeps breaking visual consistency and basic features get removed or heavily deprecated in favor of a "dumbed down" approach. This is simply not true. We are closer to hitting 60 fps (or whatever your EDID actually presents) than ever before, and staying locked to that. The more complex of an interface you create, the harder that is, but that is no different today than ev…

> The "big buttons" are that size because people have all sorts of accessibility needs different from your own What accessibility needs are you targeting when you make the buttons and titlebars bigger? Why did this change drop suddenly? Was there a cry from the majority of your users that the widgets are too small to use with desktop inputs? Usually when there are accessibility issues you add options to deal with tha…

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

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

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

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

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

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

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

Re: Libui: GUI library in C

#119

Post by Koromix »

audidude wrote: post #106
blub wrote: post #82

Earlier quoted context omitted.

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.

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.

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

Re: Libui: GUI library in C

#120

Post by riq_ »

jventura wrote: post #59

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

Post reply on HN