Ask HN: Where are the GUI libraries that aren't bloated?
It takes fifty lines to create a dialogue with a button.
Why?
Is there some kind of theorem in computational complexity that this is a strict lower bound?
Why?
Is there some kind of theorem in computational complexity that this is a strict lower bound?
Try learning the unreasonable class hierarchies of Gnome or Qt, if you want to write a graphical application in most languages; there are several tomes covering X11 and Motif and, if you bother to learn those now, just remember that Wayland's been right around the corner for over a decade now.
Every other option is either unsuitable, unmaintained, or something else. The terminal is also poorly used in UNIX: you can't get key modifiers for everything, since it's all sent as plain characters; there are several competing conventions for reporting mouse codes, all broken in different ways; instead of using the FUNCTION KEY control sequence, which scales to however many you need, Xterm and cohort send baroque sequences with no pattern, instead; and, lastly, extended color codes are broken, because Xterm implemented its own standard before someone read the real one and then it implemented the real standard incorrectly, with the other terminals following its lead as if lemmings, because they probably never saw the standard at all, and now it's too ingrained to implement properly, so just send the wrong codes, right?
It's all utterly broken and it's disgusting. I want you to take notice of how much visual garbage is in Unicode. Now, part of that is to encompass other character sets, but consider that, since the GUI and everything else is so utterly broken, why not make the character set the GUI toolkit? That seems to be what's been done, and who needs a real GUI system when you can send cute Unicode glyphs back and forth?
If you're working with a higher-level programming language, you can make cross-platform GUIs very easily (see tkinter + python as others have recommended) without having to write 50 LOC.
If you're working with C / C++ specifically, then your bottleneck really is figuring out how to build and link with your cross platform library across all platforms. In my experience that has been much more painful than the lines of code required to set up a GUI in C++.
Once you've got the build/deployment system working in C++, most GUI libraries don't need as much as 50 lines of code. For example, even with Qt this is the code to get a dialogue with a button:
#include <QApplication>
#include <QPushButton>
int main(int argc, char **argv)
{
QApplication app (argc, argv);
QPushButton button ("Hello world !");
button.show();
return app.exec();
}
window.alert("Hello world");
It's not everything so broken...
> * The "core" (the "hello" program compiled & linked with a static FLTK library using gcc on a 486 and then stripped) is 114K.
> * The FLUID program (which includes every widget) is 538k.
While that is pretty neat, I do feel like there would be place for the true graphical equivalent of ncurses; something both equally fast/lightweight, and as simple to code.
HTML+css is the easiest GUI toolkit to learn to date. It's so easy that young children in middle school are taught it in their web elective classes. And one reason it is so easy is because there is something like css.
(load "./demostuff")
(defun gtkapp ()
(sb-int:set-floating-point-modes :traps '(:overflow :invalid))
(gapp testgtk
(window win testgtk "Test" 400 200)
(box v outerbox1 win)
(box v mainbox1 outerbox1)
(box h buttons1 mainbox1)
(box h numbox1 mainbox1)
(box h leftbuttons1 buttons1)
(text num1 "Press the OK button." numbox1)
(button b1nw "OK" leftbuttons1 (xtext num1 "Button pressed."))
(gtk_widget_show_all win))
(g_application_run testgtk 0 nil)
(g_object_unref testgtk))
The "demostuff" part contains a few function and macros that are used in the author's demo. The zip archive distributed in his GitHub page[0] also contains a dumped SBCL image at around 40 MB and a script to build it for people who want to try it without installing SBCL. Not small in absolute terms but, even without function tree-shaking, its size can be reduced with core compression to a little more than 10 MB (12MB on my Debian installation, your SBCL needs to be built with "--with-sb-core-compression"), anyway still an order of magnitude smaller than Electron... ^__^;
[0] https://github.com/ocornut/imgui
Here's the code to draw a slider whose value is stored in a float:
float f = 0.5f;
ImGui::SliderFloat("my float", &f, 0.0f, 1.0f);
https://github.com/ocornut/imgui/blob/master/examples/exampl...
It seems like there is a lot of setup / configuration code necessary to wire up Imgui with the graphics rendering back-end.
Note that I haven't used Imgui in a real-world project yet. Does anyone know of a better way to set-up Imgui that does't need all this configuration code?
There's literally about ~10 lines of specific imgui code in there other than the 35 lines of example code in the middle of the main function.
Your problem is perhaps that you don't want to engage in actually reading that code.
In Tk/Tcl it takes one line if you want a simple dialog with a button:
tk_dialog .d1 "Dialog Title" "Dialog Text" "" "" "Button Text"
Because it isn't just a dialog with a button. You need to specify the element positions, resize behaviours, tool tips, separators, element selection, animations etc. The deeper you dig into UI design the more you see the "bloat" being justified.
#lang racket/gui
(require racket/gui/base)
(let* ((frame (new frame% (label "Hello, world!")))
(msg (new message% (parent frame)
(label "Hello, world!")))
(btn (new button% (parent frame)
(label "Exit")
(callback (lambda (b evt)
(exit))))))
(send frame show #t))
[1]: http://manpages.ubuntu.com/manpages/bionic/man1/zenity.1.htm...
They both also have bindings for many languages, and it certainly doesn't take fifty lines to create a dialog with a button using any of them.
[0]: https://www.qt.io
Also, for brevety look at https://www.red-lang.org/2016/03/060-red-gui-system.html
http://webserver2.tecgraf.puc-rio.br/iup/
Of course there always was and ever will be the incomparable Tk from before the world went bonkers. Some commenters here seem stuck with the idea that Tk is 'ugly'. And true, it used to be. Sometime last century.
That the phone platforms chose to break entirely with all established practice from the desktop world, that is a tragedy still fully blown with us.
https://www.quora.com/Why-is-using-a-GUI-in-most-of-all-prog...
In that answer I link to the 7 GUIs project from Eugen Kiss: https://github.com/eugenkiss/7guis which I think tried to answer your question from an evaluative, example-based approach. What I like about it was that it kept the requirements simple, but moved beyond Hello World, so it's a bit more fair to systems that have a higher lower bound for minimal GUIs.
For the last part of your question, think in terms of generality vs a DSL-based approach. A GUI system that is completely general, and can't make any assumptions, is naturally going to require more information for a given output. Once you narrow down the possibilities, and include defaults and the ability to configure things for re-use (e.g. widget styles and themes), you can dramatically reduce the effort needed. Constraint based systems (e.g. Cassowary) are another way to go.
view layout [u: field "user@rebol.com" h: field "http://" btn "Send" [send to-email u/text read to-url h/text alert "Sent"]]It's not true for both Qt and GTK+.
http://inferno-os.org/inferno/papers/sh.html
See how simple it is to draw a button:
load tk wid := ${tk window 'My window'}
fn x { args := $* or {tk $wid $args} { echo error on tk cmd $"args':' $status } }
x button .b -text {A button} x pack .b -side top x update
https://github.com/mherrmann/fbs-tutorial/blob/master/README...
Simple dialogs are very simple with tcl/tk. No matter what you do, however, it is going to look awful and people will give you grief about it. Dealing with window resizing, scrollbars, and the like may also make you cry.
It looks almost nice, and generally nice enough that people didn't realize immediately it was tk (that says a lot, considering how ugly tk is).
Next best in terms of complexity: WxWidgets
Next best: Qt
The most productive way to produce a complex GUI is always through an editor + resource compiler.
You always have the option of going part HTML+part native callback.
I have to admit, I've not been much of a fan of GUI programming.
This in reply to the question: Where are the GUI libraries that aren't bloated?
I'm gasping for breath.
I basically ended up concluding that any time I need a GUI on desktop, I'll just use browser/electron + React/Material Design which is pretty much the ultimate in customisability. I found this not only simplified my life as a programmer, it also resulted in more intuitive to use and better looking programs. There are very few use cases where sticking with traditional Desktop visual semantics and maintaining a uniform look with system apps is actually a usability advantage.