Libui: GUI library in C(github.com)
github.com
Libui: GUI library in C
https://github.com/andlabs/libui
185 comments
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.
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.
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.
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.
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.
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.
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..
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..
The library has a C interface, but the underlying implementation varies: Objective-C for Mac OS X, C++ for Windows, and C for Linux.
> [...] 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?
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?
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.
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.
> 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 ever before. Work is underway doing something similar to the webrender concepts which will improve render times even further.
I'm not sure what you mean by visual consistency, other than we create new widgets as designers ask for them. Just because applications choose to use something other than say a GtkComboBox for everything is hardly our fault. I welcome a future where application developers can decide what UI concepts work for them.
That doesn't mean you can't use deprecated widgets. This is no different than any other platform. We experiment with new ideas, keep what works well, and deprecate what doesn't based on feedback and user testing. GTK+ is one of the few libraries that generally stays ABI stable for a decade, so deprecated is more of an indicator than "this will be removed next month" like developers are used to with web APIs.
> 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.
Where do you get your information? Because they seem to be fairly miss-informed.
GTK+ is most definitely not trying to be a web application toolkit. The "big buttons" are that size because people have all sorts of accessibility needs different from your own. Or you're on HiDPI and we don't have 1.5x scaling (yet) as it requires more plumbing in the compositor to do 3x scaling in the toolkit and 2x downscaling (and input transformations) in the compositor. I hope to see this before long.
Personally, I'd like to see a "condensed" theme variant of sorts. Finally, thanks to all the CSS node work in 3.20, you can pretty much get that with a couple CSS lines.
> 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.
It's no secret to GTK+ developers that the theming API was always sort of a gray area. As of 3.20 the theming API, for the first time in nearly 18 years, is considered stable.
GTK+ does not render with GL today. (There is integration to embed GL into the scene, though). That might land for 3.22, but it's a lot of work and I would not be surprised if it doesn't make it until 3.24 as it's part of the drain-the-swap redesign of the drawing model. Presumably vulkan will be supported too.
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 ever before. Work is underway doing something similar to the webrender concepts which will improve render times even further.
I'm not sure what you mean by visual consistency, other than we create new widgets as designers ask for them. Just because applications choose to use something other than say a GtkComboBox for everything is hardly our fault. I welcome a future where application developers can decide what UI concepts work for them.
That doesn't mean you can't use deprecated widgets. This is no different than any other platform. We experiment with new ideas, keep what works well, and deprecate what doesn't based on feedback and user testing. GTK+ is one of the few libraries that generally stays ABI stable for a decade, so deprecated is more of an indicator than "this will be removed next month" like developers are used to with web APIs.
> 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.
Where do you get your information? Because they seem to be fairly miss-informed.
GTK+ is most definitely not trying to be a web application toolkit. The "big buttons" are that size because people have all sorts of accessibility needs different from your own. Or you're on HiDPI and we don't have 1.5x scaling (yet) as it requires more plumbing in the compositor to do 3x scaling in the toolkit and 2x downscaling (and input transformations) in the compositor. I hope to see this before long.
Personally, I'd like to see a "condensed" theme variant of sorts. Finally, thanks to all the CSS node work in 3.20, you can pretty much get that with a couple CSS lines.
> 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.
It's no secret to GTK+ developers that the theming API was always sort of a gray area. As of 3.20 the theming API, for the first time in nearly 18 years, is considered stable.
GTK+ does not render with GL today. (There is integration to embed GL into the scene, though). That might land for 3.22, but it's a lot of work and I would not be surprised if it doesn't make it until 3.24 as it's part of the drain-the-swap redesign of the drawing model. Presumably vulkan will be supported too.
There is some great info in this post. The draining of the swamp is really good work, and seems to be starting to pay off.
I hope for the CSS theme changes there is some sort of migration, or warning - was trying gnome-staging on Ubuntu and lots of things broke with the change.
Fingers crossed that GL will bring GL Enabled cairo at the same time.
I hope for the CSS theme changes there is some sort of migration, or warning - was trying gnome-staging on Ubuntu and lots of things broke with the change.
Fingers crossed that GL will bring GL Enabled cairo at the same time.
Drawing with cairo-gl/glitz/etc was never really faster than drawing on the CPU. I think it's more likely that we'd use the image surface (backed by pixman) and texture uploads.
If we are hitting a path where we expose the immediate mode style drawing (a'la cairo) then we've probably already lost the performance race.
If we are hitting a path where we expose the immediate mode style drawing (a'la cairo) then we've probably already lost the performance race.
> The "big buttons" are that size because people have all sorts of accessibility needs different from your own.
That's great, but GTK apps still don't work with screen readers, at all[1]. Big buttons don't cut it for making an application truly accessible.
[1]on platforms other than Linux, probably.
That's great, but GTK apps still don't work with screen readers, at all[1]. Big buttons don't cut it for making an application truly accessible.
[1]on platforms other than Linux, probably.
> 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 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?
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 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?
> 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.
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.
Why are you lecturing me on visual impairment and disabilities? At no point did I claim you ignore that user base.
>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.
Okay so after all that we get to the root of the issue. Instead of a good traditional desktop experience, you want to provide a mediocre desktop/touch hybrid experience. Instead of doing one thing well, the aim is to do multiple things poorly.
>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.
Okay so after all that we get to the root of the issue. Instead of a good traditional desktop experience, you want to provide a mediocre desktop/touch hybrid experience. Instead of doing one thing well, the aim is to do multiple things poorly.
> Why are you lecturing me on visual impairment and disabilities? At no point did I claim you ignore that user base.
Even though they do.
Even though they do.
I am trying to not come off as lecturing. My apologies if it was interpreted as such. You were making claims and I'm simply trying to provide examples of how other peoples computing experience might not match your own.
> Okay so after all that we get to the root of the issue. Instead of a good traditional desktop experience, you want to provide a mediocre desktop/touch hybrid experience. Instead of doing one thing well, the aim is to do multiple things poorly.
No need to get disparaging here. Clearly we don't want to provide a "mediocre" experience, nor do I think we do.
I also don't agree that supporting touch is some sort of hybrid experience these days. We aren't trying to be a mobile platform. We aren't trying to be a phone platform. Peoples traditional desktops (including many home workstations) have touch. These are real desktops bought by real people who get real work done.
> Okay so after all that we get to the root of the issue. Instead of a good traditional desktop experience, you want to provide a mediocre desktop/touch hybrid experience. Instead of doing one thing well, the aim is to do multiple things poorly.
No need to get disparaging here. Clearly we don't want to provide a "mediocre" experience, nor do I think we do.
I also don't agree that supporting touch is some sort of hybrid experience these days. We aren't trying to be a mobile platform. We aren't trying to be a phone platform. Peoples traditional desktops (including many home workstations) have touch. These are real desktops bought by real people who get real work done.
I work with a lot of people who have desktops. I have two. I haven't seen anyone use a traditional desktop with touch. No one. Not once. My girlfriend is a 2d artist and she uses a wacom tablet for digital painting in photoshop. That's it.
I always disliked the huge buttons that come by default with some desktop environments, and I'm amazed the argument is "people use touch". As far as I and everyone around me is concerned, no they don't.
If it's an accessibility issue, it should be an optional solution for those who need it, not the default.
I always disliked the huge buttons that come by default with some desktop environments, and I'm amazed the argument is "people use touch". As far as I and everyone around me is concerned, no they don't.
If it's an accessibility issue, it should be an optional solution for those who need it, not the default.
Don't normally comment online as I find it a lot of work (it's taken me about 5 hours to put together this pretty badly written response), but while there's a GTK dev here on topic I don't want to miss the opportunity.
> There are way more types of impairments than visually impaired.
Thankfully I have perfect eyesight, however I am very dyslexic. I have problems with spelling, but Google's search spell checker and voice recognition have made huge differences to me in that respect over the last year or two.
But relevant to GTK - I have a terrible short term memory. A goldfish like short term memory. I can barely remember a sentence when switching between windows, 5 numbers is a challenge (no distractions please) and remembering how another programmer abbreviated a variable's name is a huge distraction.
I can't organise IRL or digitally. When I'm programming terminal windows just keep piling up, because I can't remember what terminals are doing what (is that sitting at a prompt or is it watching a folder with inotify?). I could click through the open terminals and disrupt my chain of thought and forget what I'm doing or I could just open another terminal, keep working and do a closing session every so often.
So onto how GTK is making my life harder: by making widgets more accessible to people with impaired vision/touch screens they've made them bigger. I can now fit less on screen and I have to remember more. I have to move between windows more and I have to scroll more. This really is making my life much harder, I'm honestly getting lost on my desktop because I can't remember shit and I'm constantly having to switch windows - because there just isn't room any more for two side by side windows on 720p.
And it really never used to be this way. Compare Gnome Terminal with xterm. Yes gnome terminal is better, for instance you can turn off bold fonts (Myself and many other dyslexics have problems with bold and especially italics) and have a nice GUI for changing the settings. But it's visually huge. I'm pretty sure (unfortunately not checked at all, I use XFCE - because it's smaller on screen) with the default font settings you've got just about enough space to tile 120 columns of Gedit and a 80 columns of Gnome Terminal - but not something you'd actually write code with, by the time you've got Sublime's side bar open you're going to have to shrink the fonts. And find a window manager theme with smaller borders. And find a reduced size widget theme (these often don't shrink out much whitespace). And after that somehow you'll still feel cramped, maybe it's because everything has been unnaturally shrunk.
And, really ranting now, the web is the same, I'm starting to quite regularly zoom out on websites to make them more navigable, I'm getting lost scrolling between the massive headings and huge white spaces. I can't find the damn menu buttons and by the time I've found them I've forgotten why I wanted them and have to mentally backtrack (What am I doing? Why? So why was I reading this? What was the bit that sparked something? Oh yeah! Right, back to the menu! Where did that menu go again?...).
Going to the terminal example again if I want to tile my XFCE Terminal and a Digital Ocean tutorial I've to zoom Digital Ocean to 90%. And Digital Ocean are efficient with screen space.
I'm currently using a 720p 13" laptop display and I think my next laptop is going to have to have a 1080p screen, just so I can fit whatever I'm working on. I'll then have to override the DPI settings of course and generally have a broken display setup. I'm looking to buy hardware and run a nonstandard setup to solve the accessibility problems that GTK has introduced for me when solving accessibility problems.
As an analogy to the situation (on bad days) I feel it's like GTK/Gnome is running around shouting "EVERYTHING MUST HAVE WHEEL CHAIR RAMPS! NO STAIRS! ACCESSIBILITY HAS SPOKEN!" ignoring that sloped surfaces can be difficult/painful for those with hypermobility syndrome. And when it's brought up "I'm able bodied but my knees are getting sore" (AKA "your widgets are too big I'm clicking around too much") the response is that it's accessibility and wanting something different is denying wheel chair users. But this response is missing that an able bodied person is having problems (they're being annoyed by it because it's causing them difficulty) and if an able bodied person is having problems then there is almost certainly someone less able who is having even greater problems.
As in able bodied people are complaining your widgets are too big because they're finding they have a higher cognitive load because they're having to switch windows more often. The reduction in general accessibility (higher cognitive load) is traded to enable specific use cases and it's considered ok. In testing you able bodied people say "this is barely harder" and your specific use case say "this is great". But what's missing that there are other people with other disabilities you never tested - we don't speak out because there's not many of us and frankly it's not very easy, both to speak out and to make a meaningful contribution to something as complex as UI ergonomics.
Basically what I'm saying is, yes it is good to have options for disabled users. But forcing the default is not a good idea and you might find you're causing problems. The default route into buildings with access ramps is still normally a set of stairs.
For example I could request that bold and italic fonts not be used anywhere in a UI, for me this would be great, but for able bodied users this would be a step backwards and reduce accessibility (the UI can't highlight important text for instance). Able users would complain, and it would be a mild "oh I liked it when the top command put the total memory in bold, it made it pop out a bit" to which GTK would correctly say "but dyslexics find this approach much easier" but this conversation misses that there is another category of people with poor eyesight who find the bold emphasis really helps them find the important details in the UI. But because GTK has made removing bold and italic default (in the name of accessibility) the user with poor eyesight has no options to turn that back on, and the community is already galvanised against allowing bold, because they did a UI study and it helped dyslexics.
> Count yourself lucky that you don't have an impairment (right now).
Worst of all is if the "but dyslexics find this much easier" statement has accusatory undertones of ableism (Despite my quote I don't feel audidude has done this). That might lead to the poor eyesight user to agonizingly craft a response over 5 hours that tries not to offend anyone in the galvanised community, because they don't have dyslexia and don't understand the difficulties faced, maybe they really are being ableist. Alternatively, and much more likely, they'll just keep quiet and GTK will carry on oblivious, making life worse for them.
Now I have got to thank GTK for being really good with having highlightable text in dialog boxes so I can copy and paste into Google. Also after spending a lot of my childhood in Learning Support classes I have to thank GTK for all the hard work they're putting into accessibility, it isn't sexy, it annoys people but it's damn important (even when I think it's going wrong and sometimes makes me wish I worked in construction).
> There are way more types of impairments than visually impaired.
Thankfully I have perfect eyesight, however I am very dyslexic. I have problems with spelling, but Google's search spell checker and voice recognition have made huge differences to me in that respect over the last year or two.
But relevant to GTK - I have a terrible short term memory. A goldfish like short term memory. I can barely remember a sentence when switching between windows, 5 numbers is a challenge (no distractions please) and remembering how another programmer abbreviated a variable's name is a huge distraction.
I can't organise IRL or digitally. When I'm programming terminal windows just keep piling up, because I can't remember what terminals are doing what (is that sitting at a prompt or is it watching a folder with inotify?). I could click through the open terminals and disrupt my chain of thought and forget what I'm doing or I could just open another terminal, keep working and do a closing session every so often.
So onto how GTK is making my life harder: by making widgets more accessible to people with impaired vision/touch screens they've made them bigger. I can now fit less on screen and I have to remember more. I have to move between windows more and I have to scroll more. This really is making my life much harder, I'm honestly getting lost on my desktop because I can't remember shit and I'm constantly having to switch windows - because there just isn't room any more for two side by side windows on 720p.
And it really never used to be this way. Compare Gnome Terminal with xterm. Yes gnome terminal is better, for instance you can turn off bold fonts (Myself and many other dyslexics have problems with bold and especially italics) and have a nice GUI for changing the settings. But it's visually huge. I'm pretty sure (unfortunately not checked at all, I use XFCE - because it's smaller on screen) with the default font settings you've got just about enough space to tile 120 columns of Gedit and a 80 columns of Gnome Terminal - but not something you'd actually write code with, by the time you've got Sublime's side bar open you're going to have to shrink the fonts. And find a window manager theme with smaller borders. And find a reduced size widget theme (these often don't shrink out much whitespace). And after that somehow you'll still feel cramped, maybe it's because everything has been unnaturally shrunk.
And, really ranting now, the web is the same, I'm starting to quite regularly zoom out on websites to make them more navigable, I'm getting lost scrolling between the massive headings and huge white spaces. I can't find the damn menu buttons and by the time I've found them I've forgotten why I wanted them and have to mentally backtrack (What am I doing? Why? So why was I reading this? What was the bit that sparked something? Oh yeah! Right, back to the menu! Where did that menu go again?...).
Going to the terminal example again if I want to tile my XFCE Terminal and a Digital Ocean tutorial I've to zoom Digital Ocean to 90%. And Digital Ocean are efficient with screen space.
I'm currently using a 720p 13" laptop display and I think my next laptop is going to have to have a 1080p screen, just so I can fit whatever I'm working on. I'll then have to override the DPI settings of course and generally have a broken display setup. I'm looking to buy hardware and run a nonstandard setup to solve the accessibility problems that GTK has introduced for me when solving accessibility problems.
As an analogy to the situation (on bad days) I feel it's like GTK/Gnome is running around shouting "EVERYTHING MUST HAVE WHEEL CHAIR RAMPS! NO STAIRS! ACCESSIBILITY HAS SPOKEN!" ignoring that sloped surfaces can be difficult/painful for those with hypermobility syndrome. And when it's brought up "I'm able bodied but my knees are getting sore" (AKA "your widgets are too big I'm clicking around too much") the response is that it's accessibility and wanting something different is denying wheel chair users. But this response is missing that an able bodied person is having problems (they're being annoyed by it because it's causing them difficulty) and if an able bodied person is having problems then there is almost certainly someone less able who is having even greater problems.
As in able bodied people are complaining your widgets are too big because they're finding they have a higher cognitive load because they're having to switch windows more often. The reduction in general accessibility (higher cognitive load) is traded to enable specific use cases and it's considered ok. In testing you able bodied people say "this is barely harder" and your specific use case say "this is great". But what's missing that there are other people with other disabilities you never tested - we don't speak out because there's not many of us and frankly it's not very easy, both to speak out and to make a meaningful contribution to something as complex as UI ergonomics.
Basically what I'm saying is, yes it is good to have options for disabled users. But forcing the default is not a good idea and you might find you're causing problems. The default route into buildings with access ramps is still normally a set of stairs.
For example I could request that bold and italic fonts not be used anywhere in a UI, for me this would be great, but for able bodied users this would be a step backwards and reduce accessibility (the UI can't highlight important text for instance). Able users would complain, and it would be a mild "oh I liked it when the top command put the total memory in bold, it made it pop out a bit" to which GTK would correctly say "but dyslexics find this approach much easier" but this conversation misses that there is another category of people with poor eyesight who find the bold emphasis really helps them find the important details in the UI. But because GTK has made removing bold and italic default (in the name of accessibility) the user with poor eyesight has no options to turn that back on, and the community is already galvanised against allowing bold, because they did a UI study and it helped dyslexics.
> Count yourself lucky that you don't have an impairment (right now).
Worst of all is if the "but dyslexics find this much easier" statement has accusatory undertones of ableism (Despite my quote I don't feel audidude has done this). That might lead to the poor eyesight user to agonizingly craft a response over 5 hours that tries not to offend anyone in the galvanised community, because they don't have dyslexia and don't understand the difficulties faced, maybe they really are being ableist. Alternatively, and much more likely, they'll just keep quiet and GTK will carry on oblivious, making life worse for them.
Now I have got to thank GTK for being really good with having highlightable text in dialog boxes so I can copy and paste into Google. Also after spending a lot of my childhood in Learning Support classes I have to thank GTK for all the hard work they're putting into accessibility, it isn't sexy, it annoys people but it's damn important (even when I think it's going wrong and sometimes makes me wish I worked in construction).
Thank you so much for writing this post. I know it must have taken quite a bit of time to put together. I don't think all the reasons about the choices we've made were necessarily accurate, but the post is so valuable on it's own it's not worth nitpicking.
I'm sorry that things have been getting harder for you. I'll share this information when we have our summer meet-up face to face to discuss the next years work.
I can't know for sure without studying (maybe you'd be interesting in doing a study with us?) but I'd think if we can get the additional scaling factors into libmutter (the compositor layer for GNOME) that you'd have more precise control over the sizing that would work for you.
I'm sorry that things have been getting harder for you. I'll share this information when we have our summer meet-up face to face to discuss the next years work.
I can't know for sure without studying (maybe you'd be interesting in doing a study with us?) but I'd think if we can get the additional scaling factors into libmutter (the compositor layer for GNOME) that you'd have more precise control over the sizing that would work for you.
That was a pleasure to read, and sheds a different shade of light on the matter of accessibility. Definitely is going to make me think twice when designing a webpage or application.
Thanks for the writeup :)
I'd like you to substantiate the claim that it "gets slower at each release" before I'll accept it, it conflicts with my experience. I've seen every single GNOME application get consistently faster for the last five releases; today (with GNOME 3.20) they render at ludicrous speed on even my oldest intel boxes.
>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.
QML is not targeting the same space as web applications. Its a more flexible and dynamic way of creating user interfaces. Its designed so you can create UIs for kiosks, infotainment systems, mobile applications, games, and desktops all with one toolkit. QML has components specifically for desktop development that have the same look as your traditional forms based widgets.
QML is not targeting the same space as web applications. Its a more flexible and dynamic way of creating user interfaces. Its designed so you can create UIs for kiosks, infotainment systems, mobile applications, games, and desktops all with one toolkit. QML has components specifically for desktop development that have the same look as your traditional forms based widgets.
Personally, I prefer programming in Qt versus GTK. Also, I think GTK is losing developer's mind-share and Qt is moving forward faster, is targeting mobile platforms, is quite active, backed by a company, etc., etc. This kind of things are very important because some of us would like to make a living out of these things!
As someone who would like to create a commercial application for desktop, I really appreciate that at least the UI frameworks for Windows and OSX are quite stable.
As someone who would like to create a commercial application for desktop, I really appreciate that at least the UI frameworks for Windows and OSX are quite stable.
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.
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".
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".
If your platform is X11, Wayland, or Mir :)
And then you go to the Features page, with a box on the right clearly listing "GNU/Linux and Unix / Windows / Mac OS X" as supported plartforms :) With "Native look and feel" in the box just below.
I disagree with the current GTK direction, but it's not my project and I accept that. If the focus of the project has changed, update the website(s) and documentation.
Also the HTTPS stuff pointed out by distances.
I disagree with the current GTK direction, but it's not my project and I accept that. If the focus of the project has changed, update the website(s) and documentation.
Also the HTTPS stuff pointed out by distances.
Agreed. It seems wildly out of date. I'll track down who has access to the site and see if we can update it during the hackfest in a couple weeks.
Benjamin Otte recently added uxtheme.dll support to the CSS engine and I've already seen a few screenshots of the win32 theme using it to okay effect. I wrote a patch to add OS X cursor support to GDK last year and it was taken, not to mention work by Christian Hergert and others to improve the relatively new GDK/Quartz backend. So I'm pretty sure Windows and OS X are supported platforms :)
[deleted]
Linus didn't port Subsurface to Qt, other people who were already experienced with Qt did. If you have a look at their talk at linux.conf.au it's pretty obvious that they had no idea what they were doing when they wrote the GTK+ interface. I mean they weren't able to do a proper star rating widget in GTK+ and blame GTK+ for that. But doing that with Qt is just the same amount of work and they didn't even write that themselves, but the one responsible for the Qt port did. So what they are actually complaining about is: There was no one with a basic understanding of GTK+ who wrote the interface for us.
Yes, GTK+ has lots of quirks and I curse it on a regular basis, but so do Qt and all other toolkits I know of. And yes using Qt for Subsurface instead of GTK+ was a good idea, since Windows and OS X ports benefit a lot from that, but if Dirk and Linus were responsible for the Qt interface, it probably would have been just as bad as the GTK+ one.
Yes, GTK+ has lots of quirks and I curse it on a regular basis, but so do Qt and all other toolkits I know of. And yes using Qt for Subsurface instead of GTK+ was a good idea, since Windows and OS X ports benefit a lot from that, but if Dirk and Linus were responsible for the Qt interface, it probably would have been just as bad as the GTK+ one.
I'm pretty sure the QT migration occurred after Linus stopped maintaining the project and handed the reins to Dirk Hohndel.
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.
Have a bug number? Link to the driver issues? I've worked on a lot of systems, including popular virtual machines display implementations (the most likely system to hit the SVGA mode) and have not seen this.
I have, however, seen compositors that hit buggy mesa llvmpipe paths corrupt the visual output on the way to the GPU. But that would have happened to Qt as well unless you ran the Qt app on a non-composited desktop (which wouldn't really be an apples-to-apples comparison).
I have, however, seen compositors that hit buggy mesa llvmpipe paths corrupt the visual output on the way to the GPU. But that would have happened to Qt as well unless you ran the Qt app on a non-composited desktop (which wouldn't really be an apples-to-apples comparison).
GTK has the advantage of being a C library with not that many dependencies (so, simple to wrap.) QT (at least in my very limited experience) has way more dependencies, some weird build steps (MOC anyone?) and writing stubs for it would require much more code.
That said, I haven't programmed a UI in about 5 years, so this might be completely outdated.
That said, I haven't programmed a UI in about 5 years, so this might be completely outdated.
Had some troubles compiling on OSX Mavericks, but now that I've just tested it, it sure looks 100% native to me and perfectly integrates with the platform (file dialogs, osx font dialog, etc.) and much much better and lighter than Qt and other cross-platform tools I've been using so far.
I'm definitely going to try to implement a python wrapper around this as it seems usable enough as it is now.. :)
I'm definitely going to try to implement a python wrapper around this as it seems usable enough as it is now.. :)
Started pylibui at https://github.com/joaoventura/pylibui. Pretty barebones for now, but hey, it shows a window!
I have to partially disagree. With stuff like webapps or Electron, we still have the same GUI on all platforms rather than using the native widgets. Also JavaFX is drawing it's widgets themselves, and I wouldn't call JavaFX 'old days'.
I'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.
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.
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.
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.
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]
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.
I'm hoping that a native UI toolkit that can be used via FFI from nearly any language might take a chunk out of the Web-as-application-delivery-platform mindset.
I don't blame anyone for making non-native apps with Electron and HTML5, because it's so difficult to make them work on every platform. But here's to hoping someone finally got it right, and that native applications can take back some ground.
Death to the battery-eaters and memory-fillers. Let the OS do the heavy lifting.
Well, plenty of people tried this approach (off the top of my head, wxWidgets, Tk (the TCL framework, still powering Python, Perl and Ruby GUIs), FLTK). Unfortunately, all those frameworks fail for the same reason: they're all 90% there but fall short on the small details.
Still, let's hope that libui does great --- it's already quite a feat to have the basic window controls working the same on three different platforms.
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.
I've used Tk many, many times as a foundation of a temporary strawman interface while the real UI experts ... do whatever it is they do. I've also used it for custom instrumentation GUIs.
That 90% constitutes a lingua franca.
Not knocking the nice UI/UX folks - they work their corner, I work mine, and it's nice to have a technology to bridge schedules. My observation is that that 10% consumes as much as 1000% of the schedule at times :)
That 90% constitutes a lingua franca.
Not knocking the nice UI/UX folks - they work their corner, I work mine, and it's nice to have a technology to bridge schedules. My observation is that that 10% consumes as much as 1000% of the schedule at times :)
The first 90% are easy, the next 90% wear you out, and the final 90% are what makes a good product...
In my experience, the story of using a layered UI like this is that for a short while you use it, then customers start asking for features it cannot deliver and you start writing platform-specific code, then after a while the portable code is a minority. At some point there's a meeting in which someone points out that a particular platform is 90% of the value and wouldn't it be better to make do with just that 90%? Are these other platforms really worth the effort?
In my experience, the story of using a layered UI like this is that for a short while you use it, then customers start asking for features it cannot deliver and you start writing platform-specific code, then after a while the portable code is a minority. At some point there's a meeting in which someone points out that a particular platform is 90% of the value and wouldn't it be better to make do with just that 90%? Are these other platforms really worth the effort?
ObDisclosure: I'm in the embedded/middleware space.
I dunno. My peers don't write UI much at all; I do these things as force multipliers for my own nefarious purposes.
None of it gets "published" in a formally supported way, so I don't have any accountability for 'em. They're intentionally ugly but not dissonantly so. The design is "look, but don't touch." I mainly use them to anticipate integration errors and do something useful to aid in diagnosis of those. The theme here is "it ain't me, babe" or "holy cow, thanks for finding that" - determination on that axis.
But I also put adequate instrumentation in to exploit in the first place. Seems to be a lost art.
To me, the perfect user interface is no user interface at all - maybe a "push to start" button - a physical button. Second best is command line/scripting, third is the sort of thing I write.
In the embedded space, you might get a perception that this is cheating. I just smile.
I dunno. My peers don't write UI much at all; I do these things as force multipliers for my own nefarious purposes.
None of it gets "published" in a formally supported way, so I don't have any accountability for 'em. They're intentionally ugly but not dissonantly so. The design is "look, but don't touch." I mainly use them to anticipate integration errors and do something useful to aid in diagnosis of those. The theme here is "it ain't me, babe" or "holy cow, thanks for finding that" - determination on that axis.
But I also put adequate instrumentation in to exploit in the first place. Seems to be a lost art.
To me, the perfect user interface is no user interface at all - maybe a "push to start" button - a physical button. Second best is command line/scripting, third is the sort of thing I write.
In the embedded space, you might get a perception that this is cheating. I just smile.
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.
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.
What makes wxMSW an eyesore? Is it anymore of an eyesore than plain Win32?
Can you elaborate on your points? including this one:
>WxMSW is an eye-sore
>WxMSW is an eye-sore
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.
For the details see https://tcl.wiki/14796.
The OS probably won't do the heavy lifting for a text editor. Native text controls/widgets are sufficient for simple tasks (like this textarea I'm using right now), but for anything more complicated, editor authors usually have to implement their own stuff. And that quickly gets really complicated... (still not as bad as a full-blown HTML renderer/layout engine/scripting system -- usually).
Having a C API for easy FFI doesn't imply a C implementation
FWIW when Trolltech started there were about a dozen ads in each issue of Dr. Dobbs Journal for libraries like this one.
What's old is eventually new again.
What's old is eventually new again.
I actually think that CSS is better for drawing with modern GPUs than native UI frameworks are. CSS is declarative, which enables global optimizations--very important on GPUs, where state changes are expensive and overdraw hurts. By contrast, native UI frameworks were designed for slow CPU rendering in the '90s via legacy APIs like GDI.
I believe you, but still my layman's observation is that the average cocoa/win32 ui feels much snappier than the average web app. I have no proof but I'm pretty sure most people here would back me up.
If it should be faster with CSS, why isn't it? In fact, I develop a web app. What am I doing wrong?
If it should be faster with CSS, why isn't it? In fact, I develop a web app. What am I doing wrong?
Because browsers are not currently architected to make good use of modern hardware.
Maybe because the GPUs aren't used efficiently with the current technology. E.g. Webrenderer for Servo was designed to make great use of GPUs right from the beginning and the first results are really impressive.
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/
- From Jython: https://github.com/danathughes/jythonSWT
- From JRuby: https://github.com/neelance/swt4ruby
- From C++ (defunct): http://www.pure-native.com/
It's built out of small chunks of C code: https://github.com/eclipse/eclipse.platform.swt/search?p=1&q... that are wrapped in a Java API with a straightforward coding style that seems amenable to automatic source translation. And it doesn't need GC - it actually requires the Java programmer to manually dispose resources, which is easy because it always requires objects to have a parent, so everything goes away when the pane / window / whatever gets disposed.
In addition to all the standard controls, it's also got OpenGL and browser embedding since before Electron was cool.
Using it on the JVM is very easy, but there was a short-lived attempt to maintain a C++ API.
- How it looks: https://www.eclipse.org/swt/
- From Jython: https://github.com/danathughes/jythonSWT
- From JRuby: https://github.com/neelance/swt4ruby
- From C++ (defunct): http://www.pure-native.com/
It's built out of small chunks of C code: https://github.com/eclipse/eclipse.platform.swt/search?p=1&q... that are wrapped in a Java API with a straightforward coding style that seems amenable to automatic source translation. And it doesn't need GC - it actually requires the Java programmer to manually dispose resources, which is easy because it always requires objects to have a parent, so everything goes away when the pane / window / whatever gets disposed.
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."
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."
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.
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.
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.
Me too
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.
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.
>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/makotok/Hanappe http://github.com/makotok/Flower
(Flower is another branch, similar concept: build your entire UI as a mini-lib, bring it with you everywhere you need it...)
Along similar lines, I have been using the MOAI environment, with the Hanappe GUI framework, to deliver apps across every platform you can port MOAI too, sort of .. fulfilling .. the once-jaunted "write once, run anywhere" dream, while also giving me a usable UI environment for the modern world.. ship bytecode/Lua files, run the same code everywhere (the MOAI client lives).
Seriously, worth an hour or so of lab-bench time, if one is considering the prospect of having an app/run-time equilibrium, albeit with a modicum of effort:
http://github.com/moai/ http://github.com/makotok/Hanappe http://github.com/makotok/Flower
(Flower is another branch, similar concept: build your entire UI as a mini-lib, bring it with you everywhere you need it...)
A simple write up with screenshots or something would be nice.
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.
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.
Juce is another interesting UI lib 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...
Works with Windows, Mac OS, Linux, iOS and Android.
Strangely, juce seems to have a revamped website that has no pictures or screenshots of the juce user interface and its widgets. Weird. Not sure how effective that marketing is...
I guess what makes Libui interesting is its C language implementation.
juce is C++
https://www.juce.com/learn/coding-standards
https://www.juce.com/learn/coding-standards
And Swing is Java. So?
C and C++ are not the same, by a long shot.
C and C++ are not the same, by a long shot.
Juce is a great library but it doesn't target the native feel (last time i checked) which libui does.
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.
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.
Agreed 110%.
Gimme a screenshot of something built with it, a snippet of a Hello World, tell me where it runs, point me to the docs, and point me to a download.
I can't use scrolling pictures of people looking at code(!), I'm not about to watch a keynote, I don't want a "developer story", I don't want links to "companies using"! I shouldn't need to click twice to get to "features," that ought to be the first thing I see!
The remainder might well be useful for some audiences, and as jumping-off point to get a sense of the ecosystem and community around the software, but put it at least a little bit below the fold.
Gimme a screenshot of something built with it, a snippet of a Hello World, tell me where it runs, point me to the docs, and point me to a download.
I can't use scrolling pictures of people looking at code(!), I'm not about to watch a keynote, I don't want a "developer story", I don't want links to "companies using"! I shouldn't need to click twice to get to "features," that ought to be the first thing I see!
The remainder might well be useful for some audiences, and as jumping-off point to get a sense of the ecosystem and community around the software, but put it at least a little bit below the fold.
Judging from all the jobs listed on the Juce careers page it looks like they got a bunch of investment money and spent it on "going corporate".
Here's what Sensei Jeff has to say about that: https://blog.codinghorror.com/if-it-looks-corporate-change-i...
Here's what Sensei Jeff has to say about that: https://blog.codinghorror.com/if-it-looks-corporate-change-i...
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).
Juce UI apps looked pretty bad with stock UIs. But it's used a lot in the music plugin community, where custom skins are king.
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.
That said I do not know of any cross platform library in C, so this does seem to fill a niche.
> releasing at such an early stage will make it hard to change anything when building up on this.
Why? Release early and get feedback. Backward compatibility isn't holy. And it's just an alpha. No one expects the api to be stable.
Why? Release early and get feedback. Backward compatibility isn't holy. And it's just an alpha. No one expects the api to be stable.
Umm, Gtk?
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.
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
Gtk doesn't use native controls. While grandparent didn't mention that detail, I think it's the deciding factor here.
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 ;) .
there's iup [http://webserver2.tecgraf.puc-rio.br/iup/] if you only want linux and windows. pleasant-to-use chicken scheme bindings too.
Plus it's MIT licensed. You can fork this easily and maintain its behavior the way it suits whatever you're building even if the upstream changes in breaking ways.
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/
Yes, IUP would have been the killer toolkit if it only supported OSX. I love the IUP API in both C and Lua.
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
The best hope so far is probably what's described in this email: http://lua-users.org/lists/lua-l/2016-03/msg00019.html
Would have been better if they added OSX support to IUP and not re implement an entire toolkit.
I was looking for this for quite a long time. Choosing C allows one to bind easily to a moltitude of "managed" languages. I Always found IUP (http://webserver2.tecgraf.puc-rio.br/iup/) approach very interesting but it lacks an OS X binding. I will see how the two libraries compare one to each other.
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)?
In past I've used Java/SWT and C#/WinForms. Both of those come with a concept of the UI thread, which is the thread which you should use to read from and write to the UI.
What I don't understand about these multiplatform libraries is: do they also provide this mechanism, or are they actually only responsible for drawing the widgets and forms, leaving to the developer (and the guest language they are using to leverage the library) to implement that part through threads or some different pattern (i.e. reactor pattern)?
Very interesting. Just built it on ubuntu 16.04 smoothly, the only dependency is gtk-3.0.
What's the difference between libui and libsdl? The latter is also in C and supports many platforms. For large applications I may just use QT and for some embedded GUI I can use libsdl, what's the goal for libui?
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?
> 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).
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Overall it was an easier and more productive development experience for me.
I couldn't see how to do other things in the event loop. Like, waiting for socket input. Did I miss it?
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.
I was considering that approach (using native OS widgets) on initial stages of my Sciter (http://sciter.com) development.
It didn't went through for the simple reason: set of common widgets in GUI OSes is quite small: buttons, editboxes, selects and that is it. What about menus, toolbars, treeviews/virtual lists, etc. etc. ?
So yes, you can do with that common set something extremely simple like alert() or prompt() in browsers. But nothing close to full scale applications.
Yet graphic primitives... GDI on Windows does not know anything about alpha channel or anti-aliasing... But CoreGraphics does. What would be the common set in this case?
Again, idea of reusing OS widgets and native platform's look and feel in multiplatform GUI toolkits is a perpetual dream of programmers since initial version of Bible was written. wxWidgets or SWT are such examples.
But event they failed to achieve one of their primary goal - native platform's look and feel. Does anyone know any wxWidget or SWT application that look native on, say, OSX ?
So if you are designing application of "one red button 'Start'" then this approach will work of course. But even in that case ... how to create really red button in OSX? Or on Windows? You will want something custom drawn... but you haven't common graphic primitives and so on.
It didn't went through for the simple reason: set of common widgets in GUI OSes is quite small: buttons, editboxes, selects and that is it. What about menus, toolbars, treeviews/virtual lists, etc. etc. ?
So yes, you can do with that common set something extremely simple like alert() or prompt() in browsers. But nothing close to full scale applications.
Yet graphic primitives... GDI on Windows does not know anything about alpha channel or anti-aliasing... But CoreGraphics does. What would be the common set in this case?
Again, idea of reusing OS widgets and native platform's look and feel in multiplatform GUI toolkits is a perpetual dream of programmers since initial version of Bible was written. wxWidgets or SWT are such examples.
But event they failed to achieve one of their primary goal - native platform's look and feel. Does anyone know any wxWidget or SWT application that look native on, say, OSX ?
So if you are designing application of "one red button 'Start'" then this approach will work of course. But even in that case ... how to create really red button in OSX? Or on Windows? You will want something custom drawn... but you haven't common graphic primitives and so on.
I guess Sublime Text uses something like this (custom made of course) and everyone loves Sublime (at least regarding speed and cross platform good looks).
Working with Atom has opened my eyes to the idea that the web technologies are the ultimate UI platform. HTML+CSS can build any user interface and allow extreme customization.
Atom is slow and chromium a resource hog, but these are limitations of the current implementations, not inherent to the technologies themselves. A Servo-based UI toolkit with well thought out DOM bindings could solve both of these problems spectacularly.
But I'm glad this exists and I'm excited to see a light cross platform UI library that works across multiple OSes and languages. I'll probably use this for my future native UI needs.
Atom is slow and chromium a resource hog, but these are limitations of the current implementations, not inherent to the technologies themselves. A Servo-based UI toolkit with well thought out DOM bindings could solve both of these problems spectacularly.
But I'm glad this exists and I'm excited to see a light cross platform UI library that works across multiple OSes and languages. I'll probably use this for my future native UI needs.
"Atom is slow and chromium a resource hog..."
Check Sciter (http://sciter.com) then. It is single dll/so/dylib of 4-8mb without any external dependencies.
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.
> We have no intention to cover full CSS1/CSS2 attibute map.
Yeah that's not gonna work out for many projects.
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.
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
"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
1. Render performance.
On Windows Sciter uses Direct2D that is native H/W accelerated graphics rendering layer. Yet it allows to render UI directly into DirectX surface : http://sciter.com/sciter-and-directx/
2. Why TIScript ?
Check "10 years road to Sciter" article: https://sciter.com/2014/07/
On Windows Sciter uses Direct2D that is native H/W accelerated graphics rendering layer. Yet it allows to render UI directly into DirectX surface : http://sciter.com/sciter-and-directx/
2. Why TIScript ?
Check "10 years road to Sciter" article: https://sciter.com/2014/07/
[deleted]
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.
I can understand why the author interfaced with the Gtk API and also why they thought Gtk3 is the right version, but Gtk3 - even at 3.20 - is full of regressions, slow-downs and major themeing obstacles and breakage. Therefore, I wish Qt would be chosen as the X (Linux, BSD) UI API instead by new projects. Many big projects moved to Qt because of the aforementioned issues.
> that uses the native GUI technologies of each platform it supports.
WPF is native on Windows, Win32/WinForms is also native on Windows. I'm assuming it uses Win32, although a third party FFI to WPF would be very, very nice.
WPF is native on Windows, Win32/WinForms is also native on Windows. I'm assuming it uses Win32, although a third party FFI to WPF would be very, very nice.
Windows also has DirectUI, very alike WPF which it uses internally (and also has some 3rd-party OSS implementations).
WinForms/Win32 is the first UI platform that Windows supported. It's getting less used because of the new UI platforms.
I don't really understand how do they define WPF, UWP, XAML and DirectUI now or how do they compare. XAML was the language used behind WPF but it seems they have changed the terms.
The start menu in Windows 10 was created in XAML: https://news.ycombinator.com/item?id=9968679
Edit: Found this: https://news.ycombinator.com/item?id=11498366
WinForms/Win32 is the first UI platform that Windows supported. It's getting less used because of the new UI platforms.
I don't really understand how do they define WPF, UWP, XAML and DirectUI now or how do they compare. XAML was the language used behind WPF but it seems they have changed the terms.
The start menu in Windows 10 was created in XAML: https://news.ycombinator.com/item?id=9968679
Edit: Found this: https://news.ycombinator.com/item?id=11498366
You mentioned third-party OSS implementations of DirectUI. Can you provide links?
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.
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.
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.
Btw cross platform Go GUI by the same author is based on that:
https://github.com/andlabs/ui
https://github.com/andlabs/ui
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.
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.
Documentation
Needs to be written. Consult ui.h and the examples for details for now.
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.
Just a quick note: I will now be putting announcements and updates on the README.
Rust needs this
Why would anyone write a GUI app in C? Almost every alternative is better for the job.
Performance?
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)
> 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.
libui is mainly intended for FFI use with Go.
Writing GUI apps in C is a pain in the ass, yes.
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.
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.
Ok, but my question was not about FFI, but writing a GUI app...
C is easy to package and distribute. I once built a Python + GTK application for a school project. On Ubuntu that was no problem at all, but on Windows it was a complete mess because I had to bundle Python + GTK for Windows + all their dependencies. I think the result was around 200 MB of dependencies and ~100 kB of actual Python code. C + libui would have been much better in this regard.
The point here is libui can be accessed by other languages—in which one may want to write their desktop application—via FFI.
It's for FFI reasons.
It's easy to writing bindings for C: Python, Ruby, Lua, Lisp -- all have easy ways to interface with C.
I'd consider it for a hobby project, or for adding a GUI to a C program without introducing many extra dependencies. Judging from the comments though, most of the people interested in this library aren't interested in writing a C GUI app at all, and I suspect that's your real answer.
Me, because I don't want any of:
- huge binaries (or dependencies)
- slow compiles
- slow runtime
- garbage collection
- non-portability
- C++ (I just don't like it)
...pretty much every popular language other than C falls into one or more of the above.
Yeah, I know I'm fussy.
- huge binaries (or dependencies)
- slow compiles
- slow runtime
- garbage collection
- non-portability
- C++ (I just don't like it)
...pretty much every popular language other than C falls into one or more of the above.
Yeah, I know I'm fussy.
It's odd to see you saying this, given your security focus. But I suppose implicitly you're referring to UI apps that don't expose remote attack surface.
Anyhow, I used to be the same way (perhaps surprisingly given what I work on now), but I stopped once I realized that it just takes so long to do basic things in C compared to other languages. The downside of slow compilation, for example, pales in comparison to the downside of it taking a lot more code to do basic things like string manipulation.
I'd also mention that, on Windows, C has big dependencies as well (msvcrt), unless you cheat like MinGW does and use the unsupported system msvcrt.
Anyhow, I used to be the same way (perhaps surprisingly given what I work on now), but I stopped once I realized that it just takes so long to do basic things in C compared to other languages. The downside of slow compilation, for example, pales in comparison to the downside of it taking a lot more code to do basic things like string manipulation.
I'd also mention that, on Windows, C has big dependencies as well (msvcrt), unless you cheat like MinGW does and use the unsupported system msvcrt.
> It's odd to see you saying this, given your security focus. But I suppose implicitly you're referring to UI apps that don't expose remote attack surface.
I'm really quite conflicted here. I've written in the past that it can even be seen as irresponsible to write new security-sensitive programs in C/C++ when there are reasonable alternatives available, which is most of the time - and "security-sensitive" can include almost anything, given the right scenario. On the other hand, while I'm a big fan of Rust and use it for some personal projects, some things about it drive me crazy, while C's low-level nature appeals to me, so I also like to use C. I can justify this contradiction to myself easily enough, because I don't write all that much code that other people actually use, but that's something I'd like to change... :( In any case, I'm looking forward to quality-of-life improvements in Rust such as incremental compilation, which should tilt the balance more onto its side.
I'm really quite conflicted here. I've written in the past that it can even be seen as irresponsible to write new security-sensitive programs in C/C++ when there are reasonable alternatives available, which is most of the time - and "security-sensitive" can include almost anything, given the right scenario. On the other hand, while I'm a big fan of Rust and use it for some personal projects, some things about it drive me crazy, while C's low-level nature appeals to me, so I also like to use C. I can justify this contradiction to myself easily enough, because I don't write all that much code that other people actually use, but that's something I'd like to change... :( In any case, I'm looking forward to quality-of-life improvements in Rust such as incremental compilation, which should tilt the balance more onto its side.
You wouldn't write the app in C at all, most likely. You would write the library in C, because every one of those alternatives can call a C library.
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.
And they actually consider using this library.
My feelings exactly. (thus my question above)
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.
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.
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.
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.
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.
I stand by my point. Simply "not using C" isn't magically going to make your application so much more secure.
Ok, so that example maybe was not perfect. So what? Many apps nowadays talk with remote APIs. Imagine a twitter client, a SCADA app, pretty much anything nowadays, instead of nitpicking.
Btw when you use libraries written in C that very much the same as communicating over the network from your app. Same process, same address space.
Also note: local files may also be rigged... Other languages protect for whole classes of vulnerabilities with negligible costs.
About the reasonable security: http://www.tripwire.com/state-of-security/latest-security-ne...
https://curl.haxx.se/docs/vulnerabilities.html (Kudos to the curl authors for this nice overview!)
Also note: local files may also be rigged... Other languages protect for whole classes of vulnerabilities with negligible costs.
About the reasonable security: http://www.tripwire.com/state-of-security/latest-security-ne...
https://curl.haxx.se/docs/vulnerabilities.html (Kudos to the curl authors for this nice overview!)
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...
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.
Security should be evaluated based on requirements and usage. It makes no sense to say that UI (or any kind of) apps don't need to be secure, since a lot of them have high security requirements and ALL of them should at least have basic safety in place.
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.
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.
> I was recently thinking that operating systems should ditch their custom desktops in favor of a browser based UI.
Here's the really funny thing though, if you just think about it for a second:
Whether browsers become as powerful as operating systems, or operating systems become as convenient (for users and developers) as browsers,
The end result will be exactly the same.
Yep. Consider how we use browsers vs. native apps right now:
- I can open a browser and say type twitter.com and get the exact same experience on ANY device, right away, along with all my data. This is good.
or
- IF a native app is available, I have to download it first, and then, I just have to launch that app directly every time I want to use it. I get a far more responsive UI, better integration into the rest of the operating system, and the native app can support more offline capability than it could if it was running in a browser. This is good too.
Now obviously what browsers are missing is the UI responsiveness, efficient hardware performance, and OS integration.
What native apps are missing is the convenience of typing in a web address, and they're more difficult for developers to provide the same experience on every OS.
Where we stand right now, it will take WAY more work to get web apps on the same level as native apps. Lots of wheels to reinvent.
It will take far less work to make the discoverability and acquisition of native apps as convenient as typing in a web address. So why not work towards that instead?
Here's the really funny thing though, if you just think about it for a second:
Whether browsers become as powerful as operating systems, or operating systems become as convenient (for users and developers) as browsers,
The end result will be exactly the same.
Yep. Consider how we use browsers vs. native apps right now:
- I can open a browser and say type twitter.com and get the exact same experience on ANY device, right away, along with all my data. This is good.
or
- IF a native app is available, I have to download it first, and then, I just have to launch that app directly every time I want to use it. I get a far more responsive UI, better integration into the rest of the operating system, and the native app can support more offline capability than it could if it was running in a browser. This is good too.
Now obviously what browsers are missing is the UI responsiveness, efficient hardware performance, and OS integration.
What native apps are missing is the convenience of typing in a web address, and they're more difficult for developers to provide the same experience on every OS.
Where we stand right now, it will take WAY more work to get web apps on the same level as native apps. Lots of wheels to reinvent.
It will take far less work to make the discoverability and acquisition of native apps as convenient as typing in a web address. So why not work towards that instead?
> Now obviously what browsers are missing is the UI responsiveness, efficient hardware performance, and OS integration.
> It will take far less work to make the discoverability and acquisition of native apps as convenient as typing in a web address.
I don't see that as the case at all. The UI libraries are just the tip of the iceberg.
In fact, I think CSS is better suited to hardware acceleration with modern GPUs than these native libraries, which date back to the '90s, are. That's because they're declarative instead of based on imperative systems like GDI that were designed for rendering on old CPUs.
> It will take far less work to make the discoverability and acquisition of native apps as convenient as typing in a web address.
I don't see that as the case at all. The UI libraries are just the tip of the iceberg.
In fact, I think CSS is better suited to hardware acceleration with modern GPUs than these native libraries, which date back to the '90s, are. That's because they're declarative instead of based on imperative systems like GDI that were designed for rendering on old CPUs.
Just compare using Facebook/Twitter/Reddit in a browser vs. their respective native apps on any device.
Other than the initial discovery/download delay for native apps, the web apps currently have no advantage over the native versions.
If people could instantly start using a native app just by typing say "Facebook" what reason would they have to go into their browser? Does anyone currently even do that? Go back to the website after they've installed the app?
Other than the initial discovery/download delay for native apps, the web apps currently have no advantage over the native versions.
If people could instantly start using a native app just by typing say "Facebook" what reason would they have to go into their browser? Does anyone currently even do that? Go back to the website after they've installed the app?
My contention isn't that the browsers of today are superior to native apps. My contention is that a properly architected browser can make better use of modern hardware than native apps coded to legacy frameworks can.
As a counterpoint these "imperative systems" don't need hardware acceleration to be responsive. (why the hell does responsive mean "looks good on my phone" nowadays?)
Drawing everything on CPU and overdrawing/changing state like crazy (in kernel mode, even, for GDI!) is very much not responsive and not efficient. It only seems that way because (1) graphically, those apps are so simple, as the systems were designed for '90s hardware; (2) desktop CPUs are so fast that you can be really slow and still remain responsive.
Imagine I want to display a menu in a browser. The right behavior for a menu is to open in such a way that it's visible. Normally menus expand down and to the right, but if there's not enough space in these directions, they will expand in up and/or left. Try to move a Windows app so that its menu is very close to the bottom of the screen -- it will start opening its menus up. (Not to mention that they open outside of the app's window.)
In a browser menus are not like that. Normally they're imitated with CSS: a JavaScript or even a CSS selector swaps CSS classes from visible to invisible. There's no support for real menu behavior; you either have to do this all by yourself (probably pre-build the menu offscreen to measure it and then decide where to place it) or give up and use sub-par menus-like imitations And this is the only glitch here; there's lots of them (submenu behavior, shortcuts, behavior of text fields, etc.) In the standard GUI these things are implemented for you and polished long time ago; in browsers they simply do not exist.
And CSS is not that good even as a high-level layout engine.
In a browser menus are not like that. Normally they're imitated with CSS: a JavaScript or even a CSS selector swaps CSS classes from visible to invisible. There's no support for real menu behavior; you either have to do this all by yourself (probably pre-build the menu offscreen to measure it and then decide where to place it) or give up and use sub-par menus-like imitations And this is the only glitch here; there's lots of them (submenu behavior, shortcuts, behavior of text fields, etc.) In the standard GUI these things are implemented for you and polished long time ago; in browsers they simply do not exist.
And CSS is not that good even as a high-level layout engine.
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 designed for mobile with their big buttons and touch optimization.
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.
They shine especially on collaboration and sharing functionalities.
> 3D editing applications
You can do 3D editing on the web, at least in a fairly basic way.
http://threejs.org/editor/
You can do 3D editing on the web, at least in a fairly basic way.
http://threejs.org/editor/
> 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.
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.
because we're on the topic of cross-platform UI frameworks.
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.
Still, taken as a given: Linux desktop design could use some work. Or at least the themes and icon sets.
>>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?
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?
The linux folks are the least likely to switch. We love our comman line, text editors, launchers and window managers, thank you very much [1].
[1] http://reddit.com/r/unixporn
[1] http://reddit.com/r/unixporn
There isn't anything inherent to web design that makes it better-suited to creating "slick" interfaces. There's a lot of the culture of web design that I want to stay the hell away from my desktop, though.
To me, the web is for goofing off. It's where I'll read an article, post some comments somewhere, and leave. The desktop's where I get things done. I like Mate's interface (ditched Gnome at 3.x because I didn't like the new direction). KDE isn't terrible, but I feel like it gets in my way a little bit more.
> It looks like it's made from a set of ill fitting phony knockoff lego bits that don't fit together.
I remember when I would've described Linux desktops like that (about 15 years ago). You can still replicate that if you get too creative with your choice of themes and such, but I haven't found it distracting to what I use my computers for in....well, close to the last decade. Then again, I'm not a designer, so I tend not to notice or be bothered by some things that'd throw others into fits.
> Having said that, I guess that's what ChromeOS is eh?
It's neutered Linux. It's pretty enough, I suppose.
To me, the web is for goofing off. It's where I'll read an article, post some comments somewhere, and leave. The desktop's where I get things done. I like Mate's interface (ditched Gnome at 3.x because I didn't like the new direction). KDE isn't terrible, but I feel like it gets in my way a little bit more.
> It looks like it's made from a set of ill fitting phony knockoff lego bits that don't fit together.
I remember when I would've described Linux desktops like that (about 15 years ago). You can still replicate that if you get too creative with your choice of themes and such, but I haven't found it distracting to what I use my computers for in....well, close to the last decade. Then again, I'm not a designer, so I tend not to notice or be bothered by some things that'd throw others into fits.
> Having said that, I guess that's what ChromeOS is eh?
It's neutered Linux. It's pretty enough, I suppose.
The web is hacky and getting anything to look and feel just right is a pita more often than not. So people use band aids like bootstrap, sass, react, angular, jade, custom build systems requiring lots of set up... frankly speaking I'm baffled people put up with piling up layers and layers of abstraction and somehow consider it easier and, god forbid, the future of the desktop. Seems like a great example of 'easy vs simple'.
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.. ;)