Hacker News Reader

Comment by marmaduke | Hacker News Reader

> And even less that don't have dependencies on something like GTK or that don't use HTML and a web view

Most GUI libs supporting all the typical stuff are gonna be fat like GTK or suffer from underwhelming API... or do you ha e a counterexample (Id like to know)?

It seems like it would be neat for all these non C/C++ languages to band together to produce a reusable GUI runtime which can be operated via RPC... or declarative YAML. If everyone didn’t need to rebind all of Qt we would surely have GUIs for even the most niche languages.

View on HN

"be fat like GTK or suffer from underwhelming API", not necessarily.

Sciter( https://sciter.com )/Go (https://github.com/sciter-sdk/go-sciter) has pretty compact API and is of 5mb of size. Yet full set of basic input widgets including WYSIWYG editor and print/print-preview. Yet H/W accelerated graphics with support of Acrylic and Vibrant theming: https://sciter.com/blog/page/2/

> via RPC... or declarative YAML.

or CORBA...

More seriously. I'm not too familiar with Qt, but when I had to do a project in it I really hated how anti-modular it was. While it gets high praise from many people, I don't think it's possible to write sane software in it. It's bloat. Even though MFC (which I have to fight currently) is probably worse.

Instead, what we need is a simple API with opaque handles and C function calls. No fancy OOP or macro preprocessors. Simple OpenGL style. At least regarding portability, OpenGL made sane choices I think.

Immediate Mode GUI (IMGUI) has been a trend in the last years, and there are a few popular libraries like DearImGUI, but my impression is they are optimized for quick-and-dirty work. It seems that control and clarity is traded away for small local reductions of keystrokes.

> Instead, what we need is a simple API with opaque handles and C function calls. No fancy OOP or macro preprocessors. Simple OpenGL style.

Something like the enlightenment foundation libraries might be what you want[1]. I haven't tried it out properly, but I liked the look of it from the docs, it's a C api and moderately minimalistic.

However, even with C APIs, all these things end up with something like "fancy OOP" (after all, even Gtk is a C Api). That's because GUI widgets seem to be one of the few places really well suited to OO ideas like inheritance and non-trivial getter-setters.

[1]: https://docs.enlightenment.org/efl/current/

> However, even with C APIs, all these things end up with something like "fancy OOP" (after all, even Gtk is a C Api). That's because GUI widgets seem to be one of the few places really well suited to OO ideas like inheritance and non-trivial getter-setters.

How much of the GObject system is there for the benefit of Gtk and C developers and how much is there for interop with other languages and gui builders though? Programming against the C API it seems to be very much not OOP, you're always casting to a base class to call methods on that level, it doesn't appear that the OO system is used much internally.

Xlib Athena Widgets, OpenLook, and CDE were also pretty much OOP in C.

Qt is the industry standard for software in the computer graphics industry. It's definitely easy to write big applications with it and imho its very easy to work with.

Of course YMMV, but i wouldn't discount it

> Instead, what we need is a simple API with opaque handles and C function calls. No fancy OOP or macro preprocessors. Simple OpenGL style. At least regarding portability, OpenGL made sane choices I think.

FLTK [0] might fit some of this, at the cost of being somewhat ugly.

[0] https://www.fltk.org/

You mean like html, css and wasm :)

Getting proper right click support (context specific and beyond copy/paste) in anything HTML is pretty hard, even in Electron.

Check out the Red programming language.

Red lost me when they started banging on about blockchain nonsense.

What the actual fuck!!! https://token.red-lang.org/

I thought Red was just a weird language for making UI.

From their main page:

> It has been a tough year 2018, filled with roller-coasters and instability. The constant dropping of the crypto markets has forced us to change our plans pretty much every three months, in order to cope with that market uncertainty and our diminishing means. Though we have taken measures to ensure the proper funding for Red project for the next few years, so no worries on that side. All that has slowed down work on Red's core and even our new C3 language.

Reply on news.ycombinator.com