#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.
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.
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.
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.
https://www.reddit.com/r/rust/comments/1tql7uf/microsofts_wi...
#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. from tkinter import \*
root = Tk()
a = Label(root, text ="Hello World")
a.pack()
root.mainloop()(Don't tell me here. Make your docs better, so everyone benefits!)
https://github.com/duanebester/gooey/blob/main/CLAUDE.md
But still, the project solves a legit pain point. And the author seems pretty hands-on with steering the technical implementation details.
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.
(Author of Gooey [1], a GUI framework for WebASM in Go)
And in early 2000, I was in a mailing list for designing a successor/replacement to X11, code-named "Gooey" that never went anywhere.
> 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
That said, it fills a legit hole in the ecosystem and the author seems to be hands-on with the technical direction.
What's so special about Zig dev that puts them aside from the giants they stand on?