Hacker News Reader

Comment by ecshafer | Hacker News Reader

This looks good. But the thing that always lets me down on UI frameworks is how much freaking work it is to get something on the screen. My first language was Borland Turbo C++. It was so comparatively simple to do stuff. If I want to write a circle on the screen its just this:

#include <graphics.h> #include <conio.h>

int main() { int gd = DETECT, gm;

    initgraph(&gd, &gm, "C:\\TURBOC3\\BGI");

    circle(320, 240, 100);

    getch();
    closegraph();

    return 0;

}

Making some shapes and forms wasn't that much work either.

If I think back to VB and Windows (whatever it was then) making a basic window, form and some buttons was so simple and easy, they even made GUI builders because they were so good.

Somewhere along the lines GUIs became overly complex to implement.

View on HN

OK, but what about actually using a GUI toolkit to make an actual application?

You can optimize a library to make it comparatively simple to draw a circle on a screen. But that tells me nothing about binding state, signals, styling, widget hierarchy, etc. Maybe these frameworks look complicated to you because doing something more than drawing a circle is actually more complicated.

Agreed. I want a coherent, deliberate architecture for building an application and managing state.

That's the hard part. I'll take on incidental boilerplate (e.g. Elm) if the architecture helps me build and understand applications. Whatever gets me to that latter part.

VB was used to create a great many data-munging applications in its time, and while they were never pretty, they were lightning fast, largely consistent, and generally far more reliable than what we currently have.

A relative's business has been and is still completely driven by a VB app. It's goddamn ugly but most businesses of their size in that industry have been paid subscribers for 30? years at this point. Most notably its the only piece of software they've never had to ask me for help with at all.

The only updates it gets anymore are little data packs when laws/regulations change and it seems like they automated that because it's always ready before it's needed. The last "big" update was a guide to running it in parallels on new macs.

And that is the perfect piece of software - it does exactly what is asked, and no more. It has simple enough "architecture" to let anyone maintain it (by adding new stuff that regulations demand, easily), and continues to function without modification otherwise.

So VB6 or earlier is what you are probably remembering, and VB has a fascinating history as it started life as a wysiwyg design tool before it was attached to any language.

However, you need to remember that these simpler tools were a product of a much simpler set of requirements. Fixed themes, fixed screen size, fixed aspect ratios. I imagine a wysiwyg editor that gives you all the power of, say, CSS, and yet remains simple for simple things, sounds like a much more difficult task. I haven’t worked on UI in 20 years, so maybe such tools do exist.

> a wysiwyg editor that gives you all the power of, say, CSS, and yet remains simple for simple things, sounds like a much more difficult task.

so the problem is CSS isnt it?

The constraints and flexibility of CSS makes it difficult to make a simple outcome easy to specify in similarly easy CSS.

I remember Android Studio's WYSIWYG ConstraintLayout UI builder being pretty good for responsive layouts.

Latest way to do native Windows GUI in Rust is pretty cool:

https://www.reddit.com/r/rust/comments/1tql7uf/microsofts_wi...

This is what you can with Qt:

    #include <QApplication>
    #include <QWidget>
    #include <QPainter>

    class widget : public QWidget {
    void paintEvent(QPaintEvent*) override {
        QPainter(this).drawEllipse(QPoint(320, 240), 100, 100);
    }
    };

    int main(int argc, char *argv[]) {
        QApplication app(argc, argv);
        widget w;
        w.resize(640, 480);
        w.show();
        return app.exec();
    }

It doesn't seem too complicated to me.

That doesn't seem too bad, I agree. Maybe that's why QT is used. I haven't really used QT, but the more modern Windows apis, vulkan, etc all are pretty complicated.

Thats why I've always like pytk

    from tkinter import \*

    root = Tk()
    a = Label(root, text ="Hello World")
    a.pack()

    root.mainloop()

FWIW, vulkan is not a GUI library; if you're reaching for it without a clear understanding of why you're doing so, yeah, it'll seem like a very complicated way of doing things.

It’s Qt and pronounced ‘cute’.

https://en.wikipedia.org/wiki/Qt_(software)

Vulkan is a graphics API, not a UI library or framework. It's way lower level and if your goal is to make a user interface, you're not really supposed to do it with Vulkan (but you could i guess)

Yeah, it doesn't look too bad on the surface. However, Qt is bad and I'd advice moving away from it if you can. This is based on ~20 years of experience using it in various projects.

The licensing is trying to paint a picture of LGPL being somehow uncertain/evil, the way Qt advocates non-idiomatic C++ practices - I could go on for days, but shall digress.

100% Agreed. My first language was LibertyBASIC. It had everything a kid could want to make a paint program that had (at the time) more features than MSPaint, or whatever little game. Menu bars, undo/redo, dialogue windows, panes, sprites, sound, etc.

Compared to the effort:quality of something like tkinter, LibertyBASIC put it to shame! Not to throw shade, tkinter is perfectly fine but I don't think I would have cared for it at that age.

It also taught me how to pirate software, when I found out the borland compiler required to make .exe's I could give my friends was $200 :)

Ahhh a fellow Borland Turbo C++ Dev (we weren't called Devs back then!)

I agree. GUI these days are largely driven by how HTML works and we now have a whole generation of UI Devs (frontend devs) who've never known any other way.

I missed the good old ways of GUI.

I know I must be underthinking this, but I really don't know why native toolkits can't just implement some codegen thing that takes XML and produces the above.

Like, all of that should be expressable with just

  <graph>
    <circle />
  </graph>

You might like raylib :) https://www.raylib.com/

Reply on news.ycombinator.com