Gooey: A GPU-accelerated UI framework for Zig

 (github.com)

103 points | by ksec 4 hours ago

9 comments

  • ecshafer 1 hour ago
    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.

    [-]
    • bschoepke 1 minute ago
      Latest way to do native Windows GUI in Rust is pretty cool:

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

    • lll-o-lll 25 minutes ago
      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.

    • WD-42 40 minutes ago
      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.

    • coffeeaddict1 1 hour ago
      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.
      [-]
      • ecshafer 54 minutes ago
        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.
        [-]
        • jetbalsa 18 minutes ago
          Thats why I've always like pytk

              from tkinter import \*

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

    root.mainloop()
  • noelwelsh 3 hours ago
    Interesting project, but needs documentation. In particular, what's the model it uses? I.e. how are events, state, etc. handled? Normally I'd just work it out from the code examples, but the example in the README is over 200 lines which is too long for me.

    (Don't tell me here. Make your docs better, so everyone benefits!)

  • Erenay09 59 minutes ago
    It is great to see the Zig ecosystem growing, even though it was achieved by AI. I wish humans had done it, but I do not wanna start a debate between those who arent fans of AI and those who are.
    [-]
    • john_alan 32 minutes ago
      yep, dripping in AI.

      It's a real problem, so many projects are adding features at breakneck speed, but with so many bugs and so little understanding.

      Maybe that's just how it all works now, but I don't like it.

  • WD-42 2 hours ago
    This is great, we need more of this. It's high time we began to escape the dark ages of rule-by-Electron. See Bitwarden's recent fumble of a redesign.
  • vova_hn2 3 hours ago
    > Inspiration

    > GPUI - Zed's GPU UI framework

    Cool, but a comparison would also be very helpful.

    If I decide to make a GUI app with Zig, how do I choose between Gooey and GPUI?

    So far, all I know that GPUI is more mature and has at least one successful project built with it, so...

    Also:

    > Gooey: Turn (almost) any Python 3 Console Program into a GUI application with one line

    > https://github.com/chriskiehl/Gooey

    [-]
    • shorsher 2 hours ago
      GPUI is written in Rust, so in this specific case the decision is already somewhat made for you.
    • torginus 2 hours ago
      If I remember correctly, Zed's framework didn't set the goal of being able to draw arbitrary graphics/UI and by constraining that, it basically managed to represent everything with quads and distance fields in shaders, which reduced draw calls and GPU state management to a minimum.
    • ssernikk 2 hours ago
      > how do I choose between Gooey and GPUI?

      GPUI is for rust, not zig

    • mgrandl 2 hours ago
      I mean GPUI is rust and Gooey is Zig so if you wanna do a project in Zig you probably wouldn’t choose GPUI.
      [-]
  • cookiengineer 1 hour ago
    Sadface :-(

    (Author of Gooey [1], a GUI framework for WebASM in Go)

    [1] https://github.com/cookiengineer/gooey

    [-]
  • kristoff_it 1 hour ago
    Another Zig GUI project that people might be interested in is DVUI:

    https://github.com/david-vanderson/dvui

  • amelius 1 hour ago
    Nice work but honestly I haven't seen convincing arguments for writing medium to large GUI applications in a language that has no automatic GC.