QtWidgets works really hard to try and remain native (both by reusing the platform window pointers, and mimicking style and functionality). That for me is worth it. While the article constantly complains about dev tooling size, a reasonable complaint, my DLLs I ship w/ my Qt program are just 20MB (so I'd suspect a similar size increase to a single binary were I to statically link). If I didn't care about native look and feel I might have gone GTK3 (absent from the comparison here).
Having said that, the other issues concerning Qt may be valid, but for a code-only set of widgets, they work for me. For these kinds of comparisons to have value, you have to list the pros and cons of all things, not just the pros of what you like and cons of what you don't.
I think if you are going for native widgets with a more lightweight (and more liberally licensed) bent, then wx is a solid option too, though it requires a bit more manual UX work, even though it uses native widgets for real (even in some places Qt doesn't).
But other than Qt or wx, I really can't get behind these new GUI platforms which keep cropping up. They all have too many issues and don't end up presenting a native experience (or often even a good one).
If you take the time and care to build the Qt libraries yourself and configure out all the stuff you don’t need, you can get an order of magnitude smaller. I think Qt even supports a minimal configuration nowadays and markets it as “Qt Lite”
In any case I think I’ve gotten a stripped static executable down to 5 or 6 MB.
It's odd to see the "just 20MB" phrasing. I guess even native applications have expanded to the point where 20MB seems small, but in absolute terms I still consider that quite large --- to put things into perspective, a full installation of Windows 3.11, the OS with all of its included applications, is less than 20MB.
I wonder if, in another 20 years, we may see people speaking of "just 20GB"...
It's unfortunate that traditional desktop GUI frameworks are such an abysmal developer experience that everything from FOSS made by 1 person in their spare time to the cornerstone of multi-billion dollar companies choose to embed a web browser into their desktop app instead.
Qt is the best I've seen, but it has the normal c++ FUD plus the infamous licensing FUD.
And honestly, I'll have to admit that how react models GUIs is a really attractive.
> Qt is the best I've seen, but it has the normal c++ FUD
Not sure what you mean exactly; C++ is complex, but why the fear and doubt?
Also - Qt is based on veeery old C++ - a 22-year-old standard. The language has changed significantly since then, while Qt's fundamental design (in terms of programming) - not really, or not much. So, Qt is not "normal C++" these days.
The moc is not the issue. The biggest design problem with Qt is that it predates move semantics. That history affects the design of almost every class.
It feels like a beautiful old walking path that detours around a wall that's long since been torn out. It's still fine... but... it's not how you'd design it if you were to start from scratch.
I agree with you, although one thing worth pointing out is that with Qt (or similar) application frameworks on any decent operating system, you only have to download those libraries once, which means the individual overhead of an application remains extremely low.
For example, the LXQT default terminal, qterminal, comes in a package that is only 200 KB on Arch Linux, for the entire thing. (To be fair it directly depends on a library that provides a terminal widget, which is another 200 KB.)
IIRC, the single biggest component of that 20MB is the ICU Unicode library. It may be double the size of Windows 3.11, but it supports multiple languages.
> but in absolute terms I still consider that quite large --- to put things into perspective, a full installation of Windows 3.11, the OS with all of its included applications, is less than 20MB.
that really depends on the application though. say you want to make a media player, you likely want to embed FFMPEG and that alone will be heavier than windows 3.11 because there are so many codecs today. Likewise for an image editor, you're gonna have to pack a whole lot of image format encoders / decoders.
Also note that Qt can basically run as-is on top of a linux kernel, directly rendering to the framebuffer and doing everything itself so it'll mechanically be a bit heavier than something like wx which uses the OS widget APIs instead.... but won't be able to run in place where there are no "OS widget APIs" (that is, 99.9% of embedded platforms), while Qt has that as a main market.
you likely want to embed FFMPEG and that alone will be heavier than windows 3.11 because there are so many codecs today. Likewise for an image editor, you're gonna have to pack a whole lot of image format encoders / decoders.
As someone who has written some video and image decoders --- 20MB is still very large. Minimal-complexity H.261 through H.263 decoders are in the "dozens of KB" range, and optimisations in Asm are unlikely to make them that much bigger. ffdshow, an all-in-one codec that can decode and encode a few dozen formats, is 2MB and that not only includes code that does the real work, but also the COM-based bloat of the DirectShow API it uses. A GIF decoder is a few KB. JPEG is also roughly the same, maybe slightly bigger, and PNG is around that size too.
Also note that Qt can basically run as-is on top of a linux kernel, directly rendering to the framebuffer and doing everything itself
No mention of overdraw, pixel perfect rendering, layout performance, power consumption, view recycling/scrolling, or render caching (caching the composition result).
Does Godot handle this stuff well? I have no idea. I wish the post did a better deep dive. I know Unity doesn't compare well to the native APIs in these regards.
I did a lot of tutorials on my YouTube channel on how to start making GUI applications with Godot. The visual scripting is really bad for now, so I would stick with GDScript (a Python like language) or C#. It is really a great piece of software to make something quick for non-technical people. I really recommend anyone to explore and play with it a bit and I'm sure you'll find a use for this amazing engine.
Are there any visual scripting languages that aren't terrible? The system in unreal works but every time I use it I find myself wanting a text editor (I have spent years learning to program well, be that C++ or shaders, just let me do that!).
If it's general purpose, then I agree that visual languages always seem to be an annoyance. If it's domain-specific, that's another story, since many domains are all about connecting blocks together. The most common use case is audio/video signal processing, where it works well if you're working above a certain level of abstraction.
The 'Vop' (Vex OPerator) context in SideFX Houdini is the best 'node-based' graphical programming environment that I know of - however you're always working at something like a 'shader'-level. It's strength is in automatic use of SIMD and built-in parallelism (would not be a good choice to write an app in though!)
I think the main issue with most general purpose visual programming languages is, that they are still languages. So they are modeled in a way that resembles a text representation and can often be mapped to a sequence of symbols (a language). However, there are far less tools if you leave the explicit text representation (things like compatible editors, version control, etc.) so it comes down to being an over-the-top syntax highlighting at the expense of the before mentioned other tools. So, I think that visual programming would only become a viable alternative if it were to let go of the ideas of textual programming (language based) and become fully graph based.
Yes. The official node system can be used to script materials/shaders, image compositing, and there are a few excellent plugins to make it stretch to procedural modelling.
What were the motivations behind creating GDScript?
In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed.
The main reasons for creating a custom scripting language for Godot were:
Poor threading support in most script VMs, and Godot uses threads (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
Poor class-extending support in most script VMs, and adapting to the way Godot works is highly inefficient (Lua, Python, JavaScript).
Many existing languages have horrible interfaces for binding to C++, resulting in large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.) We wanted to focus on a great engine, not a great amount of integrations.
No native vector types (vector3, matrix4, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
Garbage collector results in stalls or unnecessarily large memory usage (Lua, Python, JavaScript, ActionScript, etc.).
Difficulty to integrate with the code editor for providing code completion, live editing, etc. (all of them). This is well-supported by GDScript.
GDScript was designed to curtail the issues above, and more.
An additional aspect is that--in terms of language design--in many cases "do what Python does" was the design principle followed, so that helps reduce the learning curve for those with Python experience and potentially helps avoid language design roadblocks during development of GDScript itself.
It's extremely common for people to be resistant to using GDScript initially but then be: "oh, actually, this is really good".
And there's now additional bindings for other languages (e.g. C++, C#, Rust, Python to various degrees of completeness) via the "GDNative" interface that essentially provides a C API for communicating with Godot & passing objects around.
> Why would any software not use an established scripting language like Python or JavaScript? Isn't it just makework and reinventing the wheel (badly)?
a lot of visual programming environments, like LabVIEW (1986) or Max/MSP (1985), predate Python and JS by at least a good few years :p
If you threw out everything about Python that was unnecessary it would turn out that's more than 90% of Python and therefore it's worth making a python inspired language from scratch. Using python directly would probably make Godot worse.
I personally dislike the python ecosystem and am not missing anything.
Unity just bought Bolt, so Bolt visual scripting is included in all Unity licenses for free, now. There's also the vfx graph and the shader graph node editors.
And using C# gives you the added benefit of the rest of the C# ecosystem. You can use Nuget right in the VS solution file Godot generates to import whatever you like.
This just reads like a godot advertisement...it only has good things to say about godot and only bad things to say about any other library. It's really hard to take the article seriously with so much blatant bias. It also seems to leave out any technical information that a developer using the engine would want to know, like how well it integrates with existing code, what paradigms it uses compared to other UI engines, or whether it uses lazy rendering or if it constantly runs at 60fps, etc.
It's not a Godot advertisement. The author is just excited about exploring the possibility of using a game engine for UI development. The point of this article isn't supposed to be a full dive into the nuts and bolts of using of Godot for UI development or anything, just a speculative piece about a novel use for this piece of technology. I doubt the author even knows the answers to a lot of the questions posed.
It's just bringing up an option that most developers wouldn't even consider. This article is asking a question, and just focuses on providing enough detail to frame that question.
The "excited about exploring the possibility of using a game engine for UI development" is fine, the "misrepresenting the alternatives" part, especially while ignoring all downsides of Godot, makes it look dodgy and detracts from the piece.
I made this comment when someone was talking about using GLFW and IMGUI to make an application with a openGL window and I think it applies here too, because it is easy to overlook the things that you will eventually need that are not trivial to add once you go down the road of using tools made for only very basic UIs.
"I would bet that the easiest thing would be FLTK. You can use system colors and make an openGL window while having everything else you would expect in a UI library. Executables with no dependencies start at a few hundred KB and it is very fast. There is even a single big pdf for documentation and dozens of examples that show off every widget. FLTK is very underrated these days because no one is out there marketing it.
GLFW and IMGUI are great libraries, but once you start wanting a program with various modal and non-modal windows, menus, widget layout, a native look, file dialogs, fonts, drag and drop, copy and paste, unicode, spreadsheet tables, physical printing, custom widgets, functions to hide OS specific system stuff (like stat, directory listing etc.) you might wish you had started with something made for what you are trying to do. "
Unfortunately, FLTK falls short in at least one important way: it doesn't implement accessibility, e.g. for blind users with screen readers. Godot and immediate-mode GUIs have the same problem.
If I'm not mistaken, the most lightweight cross-platform UI toolkit that draws its own widgets (unlike wx or SWT) and implements accessibility is sciter [1]. It's a good thing the antivirus vendors (who seem to be sciter's biggest customers) want to sell to governments.
That's a closed source for pay gui built on html and css.
It probably would not be too difficult to hook into FLTK's label drawing, but this is a general comment about typical small to medium sized guis, originally as a reply to someone needing an internal tool built around an openGL window. Maybe it would be better to make a top level comment and mention that the game engine isn't accessible to blind users.
IMGUI is still pretty impressive though. You can certainly create modal/non-modal windows, menus, custom widgets, file dialogs, fonts, drag and drop, unicode, tables without any other libraries. It's just that the approach is fundamentally different from what you see in retained-mode GUIs. (And if you need any OS-specific functionality like file dialogs, you can easily use other external libraries)
One of the few weaknesses of IMGUI is theming though. Don't expect to create one of those fancy Material-themed apps with animations, it's primarily intended for creating dry, technical tools of the likes of game engines and modelling/animation tools. It's more in the mindset of creating 'tools' rather than 'apps', and it really depends on your usecase.
IMGUI draws within a window, it does not create new windows. FLTK (like other GUI libraries) automatically uses native file dialogs. Drag and drop means you can drag files into the program, drag strings out of the program, etc. as well as copy and paste in and out of the program. IMGUI is great at what it does, but it does not have native file dialogs or drag and drop. I don't think it interfaces with the OS at all.
> once you go down the road of using tools made for only very basic UIs.
As noted elsewhere in the thread, the Godot editor (supporting UI, 2D & 3D) itself is built with Godot, so it's definitely not just "very basic" UIs.
FWIW, from your list, Godot doesn't currently support these AFAIK:
* physical printing, spreadsheet tables, a native look
And, does support:
* fonts, drag and drop, copy and paste, custom widgets, widget layout, functions to hide OS specific system stuff [for Windows, Mac, Linux, Android, iOS + others].
And, does support these with some privosos:
* various modal and non-modal windows (v3.2 is all in one window but shows modal/non-modal sub-windows within it, v4.0 in dev supports multiple system windows)
* menus (but not native system menus)
* unicode (Freetype is used for rendering but higher level multi-language support is currently less advanced)
Godot is also designed to be extensible, so it wouldn't be impossible to just write a plugin (either published or application specific) to integrate whatever app-dev specific features are needed.
To be fair the author is writing about his high-level view of the future in the perspective as a big fan of Godot. With that in mind, I think you'll be disappointed by the answers to you questions. On paper, Godot (or any other game engine) obviously makes no sense to most people for these kinds of UI, but having people like the author go against the grain to explore the possibility is great.
UIs in game engines are pretty different from the look-and-feel you get using native components or QT. Even with Electron apps, the text fields and buttons that you start with are at least native to the platform.
That's definitely true. OTOH it does seem that fewer and fewer applications are designed to match the native look-and-feel. A game engine would not be a good choice if that was a goal of your project, but I don't think most projects these days are too bothered about that.
JUCE is another option one could explore for cross platform non-web UI.
It's generally used to make audio apps and plugins, but these require UIs are after all. I'm fairly certain the first versions of Ableton Live were made with JUCE, I'm not so sure about the later ones. MaxMSP is also made with JUCE.
I looked into JUCE a while back when I was keen to find a good cross-platform UI solution but was put off by the licensing aspects that seemed more complex/onerous than even Qt's. YMMV.
Competition. When I was in high school some 15 years ago many of my classmates wanted to make games. It was seen as fun and because it was seen as you had to be smart to do it (parents had no clue) it was in my classmates eyes the perfect combination.
Fifteen years later and the competition is huge, and the demand in overtime and the stress followed.
As you start to make even more “programming is fun” classes, what they don’t see is the other end, and then queue in the FAANG salaries as if that is indicative of what programmers salaries are.
If I get kids, I’ll tell them to do some soul digging to find out what they find fun that the majority instead finds boring or something that has a clear path through a moat.
I’ve often wondered why more desktop software and data analysis stuff isn’t written in something like Unreal.
- optimized across platforms
- optimized net code libs
- modal collaboration tool: build in blueprints or code (basically web components before web components)
- advanced visualization
- source control integration
- the frontend can be backend language agnostic, swap C++ for Rust over time
- no web assembly needed - heavily polished ergonomics and UX
- custom input map support is robust, tools can have their own keymap (we aren’t secretaries!)
The tech world at large is really addicted to the toolkits of the wrong companies, IMO
Apples “pro” dev tool in Xcode feels like a boring business tool.
Once closed desktop tools are now free for development with a market for making money now. Godot is just as open as Visual Studio or Firefox, minus the DOM, JavaScript, etc.
Cloud infra and micro services can still be what they are, all the usual safety features.
Web/mobile development landscape just feels bloated and insane compared to building once in Unreal or Godot and outputting to multiple platforms like the game engines are doing.
Because the overhead and complexity is huge and useless. Unreal is not optimized to make GUI application, it's used to make games. Engines don't have anything useful to make modern app on the desktop.
The overhead and complexity of a dozen different IDEs, JS frameworks, 4 browsers, 2 mobile phone platforms, etc etc is less complex?
In a day to day engineering perspective it’s all a mess of abstraction and indirection anyway?
If we’re going to optimize ONE stack, I’d prefer the one with all the optimized rendering and input mapping, rather than hacking that all into a bloated document parser like we’re hacking into a browser?
For one applications need familiarity and uniformity. Games don't. For example games have exactly zero accessibility support, system actually knowing about what is being rendered is quite useful for it to provide tools like voice over. What about IME?
> If we’re going to optimize ONE stack
Why would we though? There are different classes of applications and there are multiple platforms with different conventions. Different use cases require different tools. Every time something "to rule them all" was tried, multiple niche tools grown around.
> For example games have exactly zero accessibility support, system actually knowing about what is being rendered is quite useful for it to provide tools like voice over.
Some engines do have accessibility support. Most games don't do accessibility because it costs money. Same as web apps, by the way. It is not a technical limitation.
> What about IME?
What about it? It works just fine in any proper engine. There are a lot of non-Latin-charset speakers in the world...
The section on "Electron, HTML5, CSS and JavaScript" is worth a read. We might have taken a few wrong turns when it comes to web technologies for applications.
There is so much bullshit and lies about Qt5, I won't bother finishing that piece of crap:
Erik Engheim: Qt5 is 5GB
Actual fact (on arch linux): qt5-base = 64.07 MiB, qt5-declarative = 24.72 MiB, qt5-quickcontrols2 = 8.56 MiB
> Try having somebody look at a Qt design you made. “Oops sorry you need a 5 GB download to do that. Oh and btw you need to register an account on a website, login and search really hard to find the free version.”
...blatant lie, etc. I won't bother, this guy is nuts. Thanks god for Qt, it has its quirks but on the desktop it's the best we can do to dev cross-platform
Erik Engheim: Consider Qt Creator IDE which is quite minimalist, without Qt which it requires to run, requires over 200 MB
Actual fact: 108.03 MiB
In the context of the situation imagined in the article, "blatant lie... guy is nuts" is over-doing it.
While "you need to download and compile the framework from source" is an option, "you need 5gb and to register an account for the download" is also a fairly plausible way to present it if that option offers time savings vs the former to the person you're hoping to review your project.
I'm reading your response as jumping to "lazy" and "cheap", which I find to be pretty uncharitable. The Qt Company is free to demand whatever they like, but nobody has to like the demands.
There might be some confusion about Qt the runtime (ie: compiled binaries) and the Qt SDK for development. Last I remember (admitedly, >8 years ago) the Qt SDK certainly was a multigigabyte download.
In this case, you need the SDK to develop a UI with Qt, so I think the author's comparison is fair.
> Consider Qt Creator IDE which is quite minimalist, without Qt which it requires to run, requires over 200 MB Actual fact: 108.03 MiB
Probably depends on the platform, I wouldn't be surprised if it was > 200 MB on OS X. But either way, 100 vs 200, same order of magnitude
Yeah well, but that's because of the env. you chose to use, that qt5-base etc. I mentioned? it includes header files. Add your compiler of choice and you're good to go. I've no idea what "SDK" are you talking about, but honestly, I'm pretty sure that includes tons of documentation, images, multimedia, etc.
> Probably depends on the platform, I wouldn't be surprised if it was > 200 MB on OS X. But either way, 100 vs 200, same order of magnitude
keep in mind that Qt Creator comes with a full clang for its C++ code model which is already 40-50 megabytes at least ; no decent C++ IDE can skip that.
Regarding the Qt SDK size, what can take gigabytes is installing it for all android & iOS ... ABIs / versions.
for a fast SDK installation experience, I recommend aqtinstall:
$ pip install aqtinstall
$ time python -m aqt install 5.15.0 linux desktop -O ~/Qt/
10,43s user 2,14s system 153% cpu 8,213 total
$ du -csh ~/Qt/5.15.0
592M 5.15.0
(but really, just install e.g. qtbase5-dev on Debian systems has 99.9% of what is needed for most GUI desktop apps and is ~13 megabytes: https://packages.debian.org/sid/qtbase5-dev what takes space is 3D engines, webviews, multimedia apis, etc... but an awful amount of apps don't need those)
Last time I downloaded it some years ago, it was only a multi gigabyte download if you selected all of the optional packages and their sources, which, if I remember correctly, included multiple versions of Qt itself. Most of this stuff is not needed.
I don't know enough about Qt to know if you're right or wrong, but I know enough about game engines to know that whatever Qt is or isn't, it doesn't negate the usefulness of game engines.
I have written a few 3D applications in both Unity and Unreal, and I can tell you that the cross-platform build process with those is impressive. I can package an app for three different platforms and get pixel perfect equivalent output and the exact same behavior on all three platforms without any trickery at all.
Qt probably also does this, and that's great! Qt existing doesn't take away from the utility of game engines, is all, nor the reverse.
There's additional packages for certain things like multimedia formats, SQL support, and other specialized components, but that gives you everything you need for Qt Gui.
I think you could add `--install-suggests` to that command if you wanted to get everything and the kitchen sink.
> Honestly I don’t remember much of the details of what QML was like working with. I just remember it was not as intuitive as I would have wished.
In my personal experience and opinions QML is the best domain specific language for GUI development I’ve ever used and was a dream to work with in comparison to others. Nowadays, my UIs are mainly react based web applications and I often wish I could use QML instead and dream of a warm future where I can use something like QML on web without any major tradeoffs.
I can only second this. My open source side project [1] UI is written in QML. The best feature of QML is that it forces you to separate your UI and your c++ core logic.
Godot is an incredibly good piece of technology, made by fantastic people.
But I'm not sure that I can echo the sentiment here exactly. I took the time to read the entire article.
This is what it boils down to for me:
IF you are going to build a native desktop app with a drag-and-drop WYSIWYG editor, I think it's arguably a solid choice over QT or whatever else you might do it with.
But the latter part of the article focuses on the argument against using web technologies:
> My discussion of Web technologies needs some disclaimers. I have little experience with web technologies, and I am not very fond of web technology. I am an old school GUI toolkit guy, who did his first GUI stuff using the Intuition toolkit on an old Amiga 1000.
There are a couple of really big problems I see however:
2. It was made for web pages not applications. When trying to make a GUI for an application I found that I so often hit on the limitations imposed by the assumption that we are in some scrollable webpage.
3. It is not made for reusable components, like real GUI toolkits.
From time to time, I hear this argument about how because web applications are run on the web, they're somehow fundamentally different from an application that might run on your phone or desktop natively in terms of appearance or UI capabilities.
It's all pixels on a screen. Any design asset you can whip up, with whatever animations and effects, can be rendered identically on a web, or native mobile/desktop app.
And modern web applications are entirely made of reusable components and the principles behind them.
I like to think I don't say without some perspective -- some of the first applications I ever wrote were VB.NET apps in Visual Studio 2007 using Windows Forms.
But today the idea of saying "An app made with web technologies cannot look or function quite like a native desktop app, and it lacks reusable components" is a bit wild.
Can you imagine trying to build <insert omnipresent application>'s desktop client with a WYSIWYG.
Finally, will conclude the rant here -- author talks about how Godot's 30MB compressed/70MB uncompressed size is fantastic, but with Tauri you can build native desktop apps using HTML/JS in 1-2MB.
> It's all pixels on a screen. Any design asset you can whip up, with whatever animations and effects, can be rendered identically on a web, or native mobile/desktop app.
The issue is that no one bothers to do all the OS integrations you get for free when you make a native app.
Also, every web app I've used that pretends to be a desktop app has issues that make it feel off. Using Discord as an example; I have to focus the title bar before I can use the minimize/maximize window buttons - unlike every native macOS app. I run into this almost every day.
I'm not denying that web applications are useful, but if you want something really high quality, native is the only solution in my opinion.
I was hopeful that web applications could offer a really great way to make cross-platform applications. After trying some frameworks out, and following the web standards more closely, I'm pretty pessimistic. The complexity of web browsers is out of control and I don't think they'll ever be comparable to native apps.
The funny thing is, I often prefer Web/Electron apps for the simple reason that zoom always works and it always works the same way. It's hit and miss with desktop/mobile apps.
I did an Ask HN [1] about this topic a little while ago.
Most relevant comment [2], from gunibert is here:
The problem in a framework like GoDot is, that it is meant for Games. A game renders screens in 30/60 fps. A Desktop application like a Gtk application does exactly nothing if you dont interact with the application. If you click a button only the button gets re-rendered. This is more efficient then using something like a game engine which has no concept about damaged regions and so on.
Also, people like to have something like "native" look and feel. This would be possible with Java-SWT as it abstracts away the toolkit. This is possible but in the case of SWT it is just broken (think about margins, text, scroll behaviour).
The other option is to use electron as it is just plain simple, works even in the web (you can basically make a webapp and repackage that as an electron app)
Or you package a toolkit with your application and avoid native libraries. This happens in the world of Qt for example. Gtk is cross-platform too but not statically linkable.
If it's built with the assumption it needs to throw it all away because every frame SOMETHING should change, why take the time to figure out dirty flags or the like.
I think mostly because having scads of clever conditionals all over the place greatly increases the risk of subtle and hard-to-reproduce bugs. From a 2007 Carmack email [1] :
> The way we have traditionally measured performance and optimized our games encouraged a lot of conditional operations -- recognizing that a particular operation doesn't need to be done in some subset of the operating states, and skipping it. This gives better demo timing numbers, but a huge amount of bugs are generated because skipping the expensive operation also usually skips some other state updating that turns out to be needed elsewhere.
> We definitely still have tasks that are performance intensive enough to need optimization, but the style gets applied as a matter of course in many cases where a performance benefit is negligible, but we still eat the bugs. Now that we are firmly decided on a 60hz game, worst case performance is more important than average case performance, so highly variable performance should be looked down on even more.
There was fascinating breakdown [2] of a single GTA V frame about five years back. It was a real eye-opener for me - whole full-screen rendering passes for things like water reflection and refraction when there isn't even any water visible in the scene.
Also, modern processors might run the code anyway and trow away the path not taken. Its better to optimize by generating a function that does not have branches.
I don't think that applies to conditional rendering, does it? You can't speculatively execute a graphics API command buffer submission and then dash after it shouting "wait, come back, I didn't mean it". Same with any kind of I/O, I'd think.
You are correct. But the same strategy can be used for optimization. Eg. get rid of the whole if block, and preferably dependencies to make it pure so that it can be further optimized by caching the output. Although cpu can be faster then cache so always measure.
In most games, things change every frame: Physics, particles, NPC moving around, environment animation (water, "fake" wind, ...). In this case, testing for change would be a huge overhead with minimal benefit.
Practically speaking you always need to rerender. If nothing is changing then either the game is paused or you're not playing the game (equivalent to paused).
I'd love to see a comparison of a simple application, e.g. a media player in Qt vs Godot using this mode, and see which one drains a laptop battery quicker.
If your test involves two different GUI systems running the same 'specialised libraries', you are running the specialised libraries, not the GUI systems.
A media player involves heavy crunching and streaming and memory I/o, and access to the GPU if possible - these things that game engines excel at.
Most GOOD game engines are in fact an entire operating system, abstracting away the host operating system, and attempting to depend on it very minimally - giving coders an environment which does not have to conform to "business user" semantics.
This doesn't mean game engines don't burn through energy. But on mobile, at least, most of the good game engines do allow you to fine-tune your frame-rate such that, indeed, you don't need to update anything - video or stream - at all unless some event happens..
It would be an interesting test - but beware that there are multiple approaches, and even plain ol' definitions, for how a 'game engine' differentiates from an 'operating system'.
The two systems of thought have been intertwined, commercially, for decades...
A simple A/B test of the sort I described is fairly common. Especially when we are considering alternatives and want to isolate one variable, eg the GUI. Eg if someone was interested in godot and qt was the usual then I'd encourage that team member to use the same media libraries is a given to keep it fair. This is basic science methodology: change one thing at a time to enable comparison.
You'd be amazed how much overhead a change can introduce even if the real work is done by a dedicated library. This is the whole point I was making.
eg A library like imgui that repeatedly redraws itself isn't actually that wasteful power wise if you tune it and make it fit for purpose. We've done exactly that for mobile. The simplicity of its approach enables all sorts of optimisations. Imgui is a straightforward animal that can be optimised in all sorts of directions, that is actually one of its drawcards. Reorientating it to output text has already been done - thats how flexible it can get.
Not sure if media player is the best choice, since playing a video is similar to a game and I guess that most of the battery power goes into decoding and displaying the video not the surrounding gui for play buttons and the like.
I would rather see how they fare with a classic GUI like a text or spreadsheet editor. Maybe for simplicity sake a calculator or an IRC client, then you just have to join an active channel and let it run for a while.
... you're 100% right, I meant to say music player. Basically the idea is to have something that does have to run in the background constantly, with some updating UI elements (e.g. position slider), but doesn't use too much battery on its own. The issue with a text editor is that unless you have some automated way of entering text it may be hard to compare the two. IRC is maybe not a bad idea.
Game engines very much do understand efficient rendering techniques, and if they don't, you can usually easily extend them to have that capability, sometimes without even writing any code to do it.
Not sure why I was downvoted for this, but it doesn't matter.
If you want your game engine to be useful, it needs to perform well. It doesn't matter if your engine is home grown and only for your application, or if it is something you license to other developers. If it is to be useful, it needs to perform well. So, they do. Game engine developers are not stupid.
> This is more efficient then using something like a game engine which has no concept about damaged regions and so on.
A game engine can avoid redraws trivially if no relevant input/event has occurred.
Further, AFAIK some graphic APIs do support dirty rectangles too, but to be honest, for desktop/laptop GUI apps I doubt it matters compared to anything else going on in the system.
And GUIs runs perfectly fine on integrated GPUs, further reducing the cost.
It's perfectly reasonable to build a game engine that's possible to build these GUI-specific systems on top of (if you want lazy UI rendering simply don't call the update. For godot I believe the biggest block is the editor cuz it's geared towards game creation (haven't used godot for a while don't know anything about its usage without editor)
When disabled, the features won't appear in the editor, which makes the editor less cluttered.
This is useful in education settings to reduce confusion or when working in a team.
For example, artists and level designers could use a feature profile that disables the script editor to avoid accidentally making changes to files[...]
We use "dear imgui" for fast prototyping, some of those prototypes got to be production software.
At first we were worried about the screen always updating and consuming so much energy, but reading the code it became obvious that it was extremely simple to fork the imgui with a very small update screen change, so it only updates when we do something.
Imguis and game engines are much simpler to code than conventional GUI because you don't need to handle so much state.
>game engine which has no concept about damaged regions
Sorry, just: no. Game engines which don't handle rectangle updates are poorly designed junk.
BTW, most game engines do keep track of regions needing update - its one of the most important aspects of performance tuning, for any app which presents objects on a screen to the user. Usually, the OS is doing this for an app in the apps own context - game engines also do this, and if they don't do it well, they get passed over for better-performing engines.
(Disclaimer: contributor to the MOAI game engine, which does this very, very well, and which is an amazing way to do a UI - for any app..)
I just figured that I'd share what appeared to be a useful comment from someone else the last time I participated in a discussion about this, I'm glad I did as I now have a number of further resources to do better research.
Also, just took a look at MOAI, it looks pretty cool, I'll have to add it to the list of things to play with when bored.
Last time I used Godot, the editor itself had a little indicator showing if the editor was redrawing or not (if it was redrawing, a little spinner appeared). And, indeed, if you leave the editor alone with only still elements, it doesn't redraw. I think that's an optional settings now. But if the editor can do that, why not the applications you make in it?
I tried Lazarus a few times and even though I spent a _long_ time writing Pascal, it's just not there yet. At least on the Mac, just getting it to install and run was a big pain.
How well does godot support dynamic/programmatic layout (w.r.t odd aspect ratios and resizing), localization, and accessibility?
I'd also take issue with the notion that 2D UI frameworks based on game engines are more performant than their alternatives, because game engines are optimized for 3D graphics and often struggle with performance once your UI state becomes reasonable large.
I'm not sure that "poorly" is an entirely accurate description of Godot's localization abilities.
The GSOC project you linked to is about enhancing the existing .po based feature: "In Godot, we [already] have two ways of importing translation - by using CSV or PO files."
> How well does godot support dynamic/programmatic layout
It supports this through use of its "Container" UI Controls--which have a bit of a steep learning curve but works pretty well.
> I'd also take issue with the notion that 2D UI frameworks based on game engines are more performant than their alternatives, because game engines are optimized for 3D graphics
One aspect of Godot that is a bit different in this regard is that pre-3.0 the focus was very much more on the 2D side of things, so the 2D support isn't just "a flat 2D plane in a 3D world" unlike some other engines.
How would this work on 2 or 3 monitors. Asking this, since any serious content creator tool end up using windows across monitors, and there you need good docking support.
Qt has some, but not all the way there, like Visual Studio has (but there are some good alternatives for Qt).
The other two pain points (for DCC):
- HDR support (again across monitors)
- Hi-DPI support (and again across monitors)
Once you start hitting issues above (among many small others), you realize how much there is to add (wacom tablet support? What next?)
I'm not too up to date with Godot news, but I remember that a recent update (maybe devlog?) added good multi monitor support to the editor, and therefore the gui toolkit of the engine, since the editor uses the engine.
> While you get a GUI inspector panel for your GUI components you are still forced to largely write the GUI in code.
Well yes. The time and experience (at least for me) has shown that designing UIs anywhere outside the code will eventually bite you. Not to mention that from the very moment a second person joins your team you can practically throw your version control system out of the window for UI files. Thanks but no thanks.
Interface Builder is all fun and games until you have a merge conflict in a storyboard. It's all XML files so you'd think it'd be solveable, but SwiftUI makes the code representation so much more readable.
And really, you can drag and drop elements into the live previews and it writes the code for you, including automatically wrapping existing components in horizontal/vertical stacks as needed to arrange the layout. So SwiftUI still has some of the visual UI editor benefits, just broken into smaller pieces with a much more useful text representation.
> you can practically throw your version control system out of the window for UI files.
While not "perfect" with VCS (there's a bit of automatic-generated file content churn at times), Godot stores its files (UI & other) as plain text (not even XML) with a very shallow hierarchy, e.g. here's a "scene" file from a project of mine: https://gitlab.com/RancidBacon/godot-foreigner-export-demo/-...
While I wouldn't really recommend two people working on one scene simultaneously, if it were necessary for some reason, Godot does provide the ability to separate a scene into "subscenes" which could be worked on independently.
I see what appears to be hard-coded widget positions (margin_left = 202.0). I find that hard-coding positions in desktop applications prevents layouts from adapting to different languages, font sizes and window dimensions. (Like how many Windows dialog boxes won't resize). Is this how Godot works, and is it a problem?
While it is possible to hard-code widget positions, with the Container-based layout
method the values in that file actually get completely ignored & recalculated on the fly.
The fact that the values end up in the file at all is something I consider a bug/implementation flaw.
In Godot a UI Control has an "anchor" setting for each of left/right/top/down margin which affects where the margin value is measured from in relation to the bounding box. So (hand-waving a bit here), e.g. for, say a margin value of 10px, for the left margin an anchor value of 0 means "inset 10px from the left margin of bounding box" and with anchor value of 0.5 means "move left 10px from center of bounding box" and with anchor value of 1 it calculates relative to the right-most margin. (But for right margin an anchor value of 0 means "calculate relative to right margin of bounding box, and, somewhat confusingly, I think requires the value to be negative to "inset".)
What this means in practice, is that if you use an anchor value of 0 for all margins, even when you resize an element you don't need to adjust any of the margin values.
Unfortunately Godot (and Containers--even though they re-calculate all the margins themselves) default to an anchor value of 0 for left margin and 1 for right margin which means the right margin is a non-zero value & gets re-calculated & updated/save every time you adjust the layout.
In general the layout system works pretty well & is flexible but it does have some slightly confusing aspects (and in the past at least some implementation bugs) and is somewhat difficult to explain in text. :) (And it would definitely benefit from even more detailed documentation--than what it currently has--in terms of the "sizing flags" that determine how multiple Controls occupy/share the space available.)
So, in short: Once set up correctly, Godot UI layouts generally adapt well to different text-widths, font sizes and window dimensions.
I think the future of interactive immersive VR work environments is looking very strong so using it for GUI apps seems like a good first step.
The author of this article said that he is not a web developer and he has a pro-application perspective. I think he misses the huge opportunity for web properties to also render into Virtual Reality.
Out of curiosity I looked at some of the examples in the Oculus Quest SDK. Basically Android+3D, effective but there is lots of room for improvement.
I know right! I watched a scene builder demo and was floored at how easy things were.
Java went with webapps thinking it'd be easier to manage distribution of the application if a browser did it for you. Or at least that's how the trends played out.
It kind of works, but the real missed opportunity was all the client side processing and storage that desktop apps bring to the table.
In general desktop ui is underrepresented. Then again, if you look at (most of) big tech, they're web first (or only), plus maybe a custom platform (iOS, Windows, Android). None of these companies really do cross platform desktop ui. That's the space of smaller businesses, and perhaps a smaller space in general.
[...] enables the "shadow to opacity" render mode where lighting modifies the alpha so shadowed areas are opaque and non-shadowed areas are transparent. Useful for overlaying shadows onto a camera feed in AR.
I like the concept, but you're starting your development by throwing out the native UI components, along with all the accessibility features, keyboard shortcuts, and other features that go with them.
There are some applications that mimic all those friendly native behaviors, but it tends to take a lot of work, and sometimes pushing updates when the OS behaviors change.
Regarding sizes for Xcode, etc.: While I think they’re bloated downloads, they include things like dozens of OS simulators, far more than the app/IDE itself.
This is such a bad idea. Try adding a line editor. Now try typing anything that is not ASCII or an emoji. Suddenly you'l see why you generally do not want to use a game engine for a tools.
Even the Godot editor itself is not non-English friendly. It's got a horrible experience for any language that uses an IME. If you try to insert an emoji on Mac the IME won't even appear.
it's too late for the engine to "take care of it" when the problem presents itself - because there are existing tooling and frameworks that already fixes this problem (such as native widgets, or electron).
so godot will only see usage as a GUI framework for the use cases that won't see emoji or non-english IME.
Text input and manipulation is so incredibly ugly and hard, that basically nobody cares it enough to to it really well.
Unicode to start is complicated. Then you have things like bidirectional text.
Line breaking is complicated.
There are no accepted practices for a lot of use cases.
Hyperlinks. Embedded content like images.
Copying/inserting html and other formats.
Styling content.
Rendering 100 000 lines of styled content without screwing up user input.
Line-heights. Tabs. Font definitions that are ambiguous an inconsistent (a lot of font tables today still don't provide enough space for accents on capital letters, think Swedish - so you have broken looking text or have to 'fake it'). Screwed up Kerning tables.
No established standard for real pixelation and rendering - zoom in and you'll see font's can be rendered a variety of ways.
Emojis, fat finger cursor navigation on mobile devcies, input managers.
It's hard to describe how messy it gets because none of it is academic, it's not some scary-hard algorithm - it's just an incredibly ugly pile of cross-cutting code with a zillion little bits and pieces of corner cases.
And a big one for gaming engines: they don't render text 'natively'. You basically have to create textures. Every big of text, it's own texture. How big is the texture for 100 000 lines of code? Big.
This is actually one are where Qt falls flat. In the 'new and improved' Qt, they do everything in the GPU, if you try to load 100 000 lines of something the app will use up 1G of memory and puke. So then you have to magically code your way around it.
All for what? Why would you want to render text in a gaming engine in the first place ...
Then you discover that 'apps' and 'games' are really different things, and they use different tech for good reason. It only gets ugly when they really have cross paths.
Nobody is saying Godot should implement their own text engine. There are several available ones they can use, or just pick whatever the platform offers.
> Why would you want to render text in a gaming engine in the first place ...
Just about every game needs text, including Unicode text. Every proper engine handles it.
"Just about every game needs text, including Unicode text. Every proper engine handles it"
No, what they do is paste a few characters on screen, handling a more common subset of Unicode. They don't come close to handling most of the things I described above.
Not even Qt handles text well - Qt allows you to do some fun 3D things with text, but not you can't open 100K lines of formatted code like VSCode.
Webkit is just as bad - MS had to invent 'Monaco' a huge layer on top to be able to manage text properly and it's kind of a hack.
"All major platforms offer advanced text rendering support."
No, they don't realy.
I think you're missing a few pieces in your understanding of what the platform does in these contexts
The platform does not support text rendering for Qt and such platforms. They are rendered 'from scratch'.
Some platforms offer some built in components, but even they are quite limited.
No platform offers the ability, out of the box, to do for example, a 'coded editor' with properly highlighted syntax. Not even close.
"Most games do actual text rendering properly."
They are 'rendering text properly' for the extremely limited subset of text that they put on the screen.
Have you ever used even a basic 'text editor' in a game? No? Because they don't even do that.
" you can't open 100K lines of formatted code"
"You definitely can, but not naively."
'Natively' means nothing on the context of 'browser'. If you mean to say 'the browser doesn't do it out of the box' - then ok, yes, we agree. And why not, because it's extremely hard?
There are 0 comprehensive text APIs that are built upon gaming or even 3D engines today. Most of the barely handle basic text formatting. They put a few lines of text on the screen in a limited number of languages, and that's it.
There are very, very few platforms that offer comprehensive text rendering, including Qt, GTK, and native platform components - they're basic.
Providing comprehensive text API is not only something that has to be layered on top of those things - they also have to 'hack' those platforms to work around inherent bugs and limitations.
That said, complete and robust i18n support may take a while, given the small size of the core development team (< 30 regular contributors) and the fact that text display is probably not the highest priority for a game development tool and engine.
258 comments
[ 4.2 ms ] story [ 265 ms ] threadHaving said that, the other issues concerning Qt may be valid, but for a code-only set of widgets, they work for me. For these kinds of comparisons to have value, you have to list the pros and cons of all things, not just the pros of what you like and cons of what you don't.
But other than Qt or wx, I really can't get behind these new GUI platforms which keep cropping up. They all have too many issues and don't end up presenting a native experience (or often even a good one).
In any case I think I’ve gotten a stripped static executable down to 5 or 6 MB.
I wonder if, in another 20 years, we may see people speaking of "just 20GB"...
Do you want to flash image to USB drive? There is Electron app (balenaEtcher) for that.
Do you want to control your mouse/keyboard? There is Electron app for that (Logitech GHub), which also includes many Qt libraries.
Do you want a terminal emulator? There is an Electron based app for that.
...
Qt is the best I've seen, but it has the normal c++ FUD plus the infamous licensing FUD.
And honestly, I'll have to admit that how react models GUIs is a really attractive.
Not sure what you mean exactly; C++ is complex, but why the fear and doubt?
Also - Qt is based on veeery old C++ - a 22-year-old standard. The language has changed significantly since then, while Qt's fundamental design (in terms of programming) - not really, or not much. So, Qt is not "normal C++" these days.
It feels like a beautiful old walking path that detours around a wall that's long since been torn out. It's still fine... but... it's not how you'd design it if you were to start from scratch.
I agree with you, although one thing worth pointing out is that with Qt (or similar) application frameworks on any decent operating system, you only have to download those libraries once, which means the individual overhead of an application remains extremely low.
For example, the LXQT default terminal, qterminal, comes in a package that is only 200 KB on Arch Linux, for the entire thing. (To be fair it directly depends on a library that provides a terminal widget, which is another 200 KB.)
that really depends on the application though. say you want to make a media player, you likely want to embed FFMPEG and that alone will be heavier than windows 3.11 because there are so many codecs today. Likewise for an image editor, you're gonna have to pack a whole lot of image format encoders / decoders.
Also note that Qt can basically run as-is on top of a linux kernel, directly rendering to the framebuffer and doing everything itself so it'll mechanically be a bit heavier than something like wx which uses the OS widget APIs instead.... but won't be able to run in place where there are no "OS widget APIs" (that is, 99.9% of embedded platforms), while Qt has that as a main market.
As someone who has written some video and image decoders --- 20MB is still very large. Minimal-complexity H.261 through H.263 decoders are in the "dozens of KB" range, and optimisations in Asm are unlikely to make them that much bigger. ffdshow, an all-in-one codec that can decode and encode a few dozen formats, is 2MB and that not only includes code that does the real work, but also the COM-based bloat of the DirectShow API it uses. A GIF decoder is a few KB. JPEG is also roughly the same, maybe slightly bigger, and PNG is around that size too.
Also note that Qt can basically run as-is on top of a linux kernel, directly rendering to the framebuffer and doing everything itself
So does Windows (on top of DOS.)
I have an (admittedly simple) application using QtWidgets that is under 10 MiB statically linked.
Particularly in Windows.
Does Godot handle this stuff well? I have no idea. I wish the post did a better deep dive. I know Unity doesn't compare well to the native APIs in these regards.
Are there any visual scripting languages that aren't terrible? The system in unreal works but every time I use it I find myself wanting a text editor (I have spent years learning to program well, be that C++ or shaders, just let me do that!).
https://youtu.be/ydd6l3iYOZE
It is still just connecting blocks though as pierrec says below so it can take a lot of connections to get something done
https://docs.blender.org/manual/en/latest/render/shader_node...
- Bloat... Both are extremely heavy dependencies if you want "the real deal" vs a stripped down version that looks like Python or JavaScript.
- Performance too. Python is slow. JavaScript too, unless you use the modern JITs.
- Licensing perhaps?
- Lack of support for that use case?
- Painful interop? No idea.
What were the motivations behind creating GDScript?
In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed.
The main reasons for creating a custom scripting language for Godot were:
Poor threading support in most script VMs, and Godot uses threads (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
Poor class-extending support in most script VMs, and adapting to the way Godot works is highly inefficient (Lua, Python, JavaScript).
Many existing languages have horrible interfaces for binding to C++, resulting in large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.) We wanted to focus on a great engine, not a great amount of integrations.
No native vector types (vector3, matrix4, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
Garbage collector results in stalls or unnecessarily large memory usage (Lua, Python, JavaScript, ActionScript, etc.).
Difficulty to integrate with the code editor for providing code completion, live editing, etc. (all of them). This is well-supported by GDScript.
GDScript was designed to curtail the issues above, and more.
An additional aspect is that--in terms of language design--in many cases "do what Python does" was the design principle followed, so that helps reduce the learning curve for those with Python experience and potentially helps avoid language design roadblocks during development of GDScript itself.
It's extremely common for people to be resistant to using GDScript initially but then be: "oh, actually, this is really good".
And there's now additional bindings for other languages (e.g. C++, C#, Rust, Python to various degrees of completeness) via the "GDNative" interface that essentially provides a C API for communicating with Godot & passing objects around.
a lot of visual programming environments, like LabVIEW (1986) or Max/MSP (1985), predate Python and JS by at least a good few years :p
I personally dislike the python ecosystem and am not missing anything.
It's simple and straight forward.
It's just bringing up an option that most developers wouldn't even consider. This article is asking a question, and just focuses on providing enough detail to frame that question.
I don't think the negativity is justified.
"I would bet that the easiest thing would be FLTK. You can use system colors and make an openGL window while having everything else you would expect in a UI library. Executables with no dependencies start at a few hundred KB and it is very fast. There is even a single big pdf for documentation and dozens of examples that show off every widget. FLTK is very underrated these days because no one is out there marketing it.
GLFW and IMGUI are great libraries, but once you start wanting a program with various modal and non-modal windows, menus, widget layout, a native look, file dialogs, fonts, drag and drop, copy and paste, unicode, spreadsheet tables, physical printing, custom widgets, functions to hide OS specific system stuff (like stat, directory listing etc.) you might wish you had started with something made for what you are trying to do. "
If I'm not mistaken, the most lightweight cross-platform UI toolkit that draws its own widgets (unlike wx or SWT) and implements accessibility is sciter [1]. It's a good thing the antivirus vendors (who seem to be sciter's biggest customers) want to sell to governments.
[1]: https://sciter.com/
It probably would not be too difficult to hook into FLTK's label drawing, but this is a general comment about typical small to medium sized guis, originally as a reply to someone needing an internal tool built around an openGL window. Maybe it would be better to make a top level comment and mention that the game engine isn't accessible to blind users.
Yeah, this is currently a valid criticism--it's an aspect I'm hoping will see more development attention in the future.
I did recently discover this project which is working on improving the situation: https://github.com/lightsoutgames/godot-accessibility/
One of the few weaknesses of IMGUI is theming though. Don't expect to create one of those fancy Material-themed apps with animations, it's primarily intended for creating dry, technical tools of the likes of game engines and modelling/animation tools. It's more in the mindset of creating 'tools' rather than 'apps', and it really depends on your usecase.
As noted elsewhere in the thread, the Godot editor (supporting UI, 2D & 3D) itself is built with Godot, so it's definitely not just "very basic" UIs.
FWIW, from your list, Godot doesn't currently support these AFAIK:
* physical printing, spreadsheet tables, a native look
And, does support:
* fonts, drag and drop, copy and paste, custom widgets, widget layout, functions to hide OS specific system stuff [for Windows, Mac, Linux, Android, iOS + others].
And, does support these with some privosos:
* various modal and non-modal windows (v3.2 is all in one window but shows modal/non-modal sub-windows within it, v4.0 in dev supports multiple system windows)
* menus (but not native system menus)
* unicode (Freetype is used for rendering but higher level multi-language support is currently less advanced)
This point was mentioned in the article. Seems like you made up your mind without reading too closely.
It's generally used to make audio apps and plugins, but these require UIs are after all. I'm fairly certain the first versions of Ableton Live were made with JUCE, I'm not so sure about the later ones. MaxMSP is also made with JUCE.
https://juce.com/
Which begs the question how do other areas of development get such easy conditions?
Fifteen years later and the competition is huge, and the demand in overtime and the stress followed.
As you start to make even more “programming is fun” classes, what they don’t see is the other end, and then queue in the FAANG salaries as if that is indicative of what programmers salaries are.
If I get kids, I’ll tell them to do some soul digging to find out what they find fun that the majority instead finds boring or something that has a clear path through a moat.
- optimized across platforms - optimized net code libs - modal collaboration tool: build in blueprints or code (basically web components before web components) - advanced visualization - source control integration - the frontend can be backend language agnostic, swap C++ for Rust over time - no web assembly needed - heavily polished ergonomics and UX - custom input map support is robust, tools can have their own keymap (we aren’t secretaries!)
The tech world at large is really addicted to the toolkits of the wrong companies, IMO
Apples “pro” dev tool in Xcode feels like a boring business tool.
Once closed desktop tools are now free for development with a market for making money now. Godot is just as open as Visual Studio or Firefox, minus the DOM, JavaScript, etc.
Cloud infra and micro services can still be what they are, all the usual safety features.
Web/mobile development landscape just feels bloated and insane compared to building once in Unreal or Godot and outputting to multiple platforms like the game engines are doing.
In a day to day engineering perspective it’s all a mess of abstraction and indirection anyway?
If we’re going to optimize ONE stack, I’d prefer the one with all the optimized rendering and input mapping, rather than hacking that all into a bloated document parser like we’re hacking into a browser?
IMO that is textbook functional fixedness.
> If we’re going to optimize ONE stack
Why would we though? There are different classes of applications and there are multiple platforms with different conventions. Different use cases require different tools. Every time something "to rule them all" was tried, multiple niche tools grown around.
Some engines do have accessibility support. Most games don't do accessibility because it costs money. Same as web apps, by the way. It is not a technical limitation.
> What about IME?
What about it? It works just fine in any proper engine. There are a lot of non-Latin-charset speakers in the world...
Erik Engheim: Qt5 is 5GB Actual fact (on arch linux): qt5-base = 64.07 MiB, qt5-declarative = 24.72 MiB, qt5-quickcontrols2 = 8.56 MiB
> Try having somebody look at a Qt design you made. “Oops sorry you need a 5 GB download to do that. Oh and btw you need to register an account on a website, login and search really hard to find the free version.”
...blatant lie, etc. I won't bother, this guy is nuts. Thanks god for Qt, it has its quirks but on the desktop it's the best we can do to dev cross-platform
Erik Engheim: Consider Qt Creator IDE which is quite minimalist, without Qt which it requires to run, requires over 200 MB Actual fact: 108.03 MiB
"From February onward, everyone, including open-source Qt users, will require valid Qt accounts to download Qt binary packages."
- https://www.qt.io/blog/qt-offering-changes-2020
While "you need to download and compile the framework from source" is an option, "you need 5gb and to register an account for the download" is also a fairly plausible way to present it if that option offers time savings vs the former to the person you're hoping to review your project.
I'm reading your response as jumping to "lazy" and "cheap", which I find to be pretty uncharitable. The Qt Company is free to demand whatever they like, but nobody has to like the demands.
In this case, you need the SDK to develop a UI with Qt, so I think the author's comparison is fair.
> Consider Qt Creator IDE which is quite minimalist, without Qt which it requires to run, requires over 200 MB Actual fact: 108.03 MiB
Probably depends on the platform, I wouldn't be surprised if it was > 200 MB on OS X. But either way, 100 vs 200, same order of magnitude
keep in mind that Qt Creator comes with a full clang for its C++ code model which is already 40-50 megabytes at least ; no decent C++ IDE can skip that.
Regarding the Qt SDK size, what can take gigabytes is installing it for all android & iOS ... ABIs / versions.
for a fast SDK installation experience, I recommend aqtinstall:
(but really, just install e.g. qtbase5-dev on Debian systems has 99.9% of what is needed for most GUI desktop apps and is ~13 megabytes: https://packages.debian.org/sid/qtbase5-dev what takes space is 3D engines, webviews, multimedia apis, etc... but an awful amount of apps don't need those)I have written a few 3D applications in both Unity and Unreal, and I can tell you that the cross-platform build process with those is impressive. I can package an app for three different platforms and get pixel perfect equivalent output and the exact same behavior on all three platforms without any trickery at all.
Qt probably also does this, and that's great! Qt existing doesn't take away from the utility of game engines, is all, nor the reverse.
Why are they shooting themselves in the foot there?
I think you could add `--install-suggests` to that command if you wanted to get everything and the kitchen sink.
In my personal experience and opinions QML is the best domain specific language for GUI development I’ve ever used and was a dream to work with in comparison to others. Nowadays, my UIs are mainly react based web applications and I often wish I could use QML instead and dream of a warm future where I can use something like QML on web without any major tradeoffs.
So I strongly disagree with him on this point.
[1]https://screen-play.app/ (Live wallpaper)
But I'm not sure that I can echo the sentiment here exactly. I took the time to read the entire article.
This is what it boils down to for me:
IF you are going to build a native desktop app with a drag-and-drop WYSIWYG editor, I think it's arguably a solid choice over QT or whatever else you might do it with.
But the latter part of the article focuses on the argument against using web technologies:
From time to time, I hear this argument about how because web applications are run on the web, they're somehow fundamentally different from an application that might run on your phone or desktop natively in terms of appearance or UI capabilities.It's all pixels on a screen. Any design asset you can whip up, with whatever animations and effects, can be rendered identically on a web, or native mobile/desktop app.
And modern web applications are entirely made of reusable components and the principles behind them.
I like to think I don't say without some perspective -- some of the first applications I ever wrote were VB.NET apps in Visual Studio 2007 using Windows Forms.
But today the idea of saying "An app made with web technologies cannot look or function quite like a native desktop app, and it lacks reusable components" is a bit wild.
Can you imagine trying to build <insert omnipresent application>'s desktop client with a WYSIWYG.
Finally, will conclude the rant here -- author talks about how Godot's 30MB compressed/70MB uncompressed size is fantastic, but with Tauri you can build native desktop apps using HTML/JS in 1-2MB.
https://tauri.studio
The issue is that no one bothers to do all the OS integrations you get for free when you make a native app.
Also, every web app I've used that pretends to be a desktop app has issues that make it feel off. Using Discord as an example; I have to focus the title bar before I can use the minimize/maximize window buttons - unlike every native macOS app. I run into this almost every day.
I'm not denying that web applications are useful, but if you want something really high quality, native is the only solution in my opinion.
I was hopeful that web applications could offer a really great way to make cross-platform applications. After trying some frameworks out, and following the web standards more closely, I'm pretty pessimistic. The complexity of web browsers is out of control and I don't think they'll ever be comparable to native apps.
Most relevant comment [2], from gunibert is here:
The problem in a framework like GoDot is, that it is meant for Games. A game renders screens in 30/60 fps. A Desktop application like a Gtk application does exactly nothing if you dont interact with the application. If you click a button only the button gets re-rendered. This is more efficient then using something like a game engine which has no concept about damaged regions and so on.
Also, people like to have something like "native" look and feel. This would be possible with Java-SWT as it abstracts away the toolkit. This is possible but in the case of SWT it is just broken (think about margins, text, scroll behaviour).
The other option is to use electron as it is just plain simple, works even in the web (you can basically make a webapp and repackage that as an electron app)
Or you package a toolkit with your application and avoid native libraries. This happens in the world of Qt for example. Gtk is cross-platform too but not statically linkable.
[1] https://news.ycombinator.com/item?id=23580213 [2] https://news.ycombinator.com/item?id=23584258
> If true, the engine optimizes for low processor usage by only refreshing the screen if needed
https://docs.godotengine.org/en/stable/classes/class_os.html...
> The way we have traditionally measured performance and optimized our games encouraged a lot of conditional operations -- recognizing that a particular operation doesn't need to be done in some subset of the operating states, and skipping it. This gives better demo timing numbers, but a huge amount of bugs are generated because skipping the expensive operation also usually skips some other state updating that turns out to be needed elsewhere.
> We definitely still have tasks that are performance intensive enough to need optimization, but the style gets applied as a matter of course in many cases where a performance benefit is negligible, but we still eat the bugs. Now that we are firmly decided on a 60hz game, worst case performance is more important than average case performance, so highly variable performance should be looked down on even more.
There was fascinating breakdown [2] of a single GTA V frame about five years back. It was a real eye-opener for me - whole full-screen rendering passes for things like water reflection and refraction when there isn't even any water visible in the scene.
[1] http://number-none.com/blow/john_carmack_on_inlined_code.htm...
[2] http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphic...
Have both use the same specialised libraries.
If anyone wants inspiration, Winamp is the gold standard for media players with excellent GUI bling and skinning.
If your test involves two different GUI systems running the same 'specialised libraries', you are running the specialised libraries, not the GUI systems.
A media player involves heavy crunching and streaming and memory I/o, and access to the GPU if possible - these things that game engines excel at.
Most GOOD game engines are in fact an entire operating system, abstracting away the host operating system, and attempting to depend on it very minimally - giving coders an environment which does not have to conform to "business user" semantics.
This doesn't mean game engines don't burn through energy. But on mobile, at least, most of the good game engines do allow you to fine-tune your frame-rate such that, indeed, you don't need to update anything - video or stream - at all unless some event happens..
It would be an interesting test - but beware that there are multiple approaches, and even plain ol' definitions, for how a 'game engine' differentiates from an 'operating system'.
The two systems of thought have been intertwined, commercially, for decades...
You'd be amazed how much overhead a change can introduce even if the real work is done by a dedicated library. This is the whole point I was making.
eg A library like imgui that repeatedly redraws itself isn't actually that wasteful power wise if you tune it and make it fit for purpose. We've done exactly that for mobile. The simplicity of its approach enables all sorts of optimisations. Imgui is a straightforward animal that can be optimised in all sorts of directions, that is actually one of its drawcards. Reorientating it to output text has already been done - thats how flexible it can get.
I would rather see how they fare with a classic GUI like a text or spreadsheet editor. Maybe for simplicity sake a calculator or an IRC client, then you just have to join an active channel and let it run for a while.
If you want your game engine to be useful, it needs to perform well. It doesn't matter if your engine is home grown and only for your application, or if it is something you license to other developers. If it is to be useful, it needs to perform well. So, they do. Game engine developers are not stupid.
A game engine can avoid redraws trivially if no relevant input/event has occurred.
Further, AFAIK some graphic APIs do support dirty rectangles too, but to be honest, for desktop/laptop GUI apps I doubt it matters compared to anything else going on in the system.
And GUIs runs perfectly fine on integrated GPUs, further reducing the cost.
Blender does this perfectly fine, for instance.
There's lots of superfluous stuff if you're making tools instead of games, but it doesn't really get in the way.
Edit: It was in the editor, just realized I didn't explicitly mention that.
Recently Godot gained the ability to selectively remove features from the editor:
* https://godotengine.org/article/godot-32-will-allow-disablin...
* https://docs.godotengine.org/en/stable/classes/class_editorf...
The documentation describes it like this:
"""
When disabled, the features won't appear in the editor, which makes the editor less cluttered.
This is useful in education settings to reduce confusion or when working in a team.
For example, artists and level designers could use a feature profile that disables the script editor to avoid accidentally making changes to files[...]
"""
At first we were worried about the screen always updating and consuming so much energy, but reading the code it became obvious that it was extremely simple to fork the imgui with a very small update screen change, so it only updates when we do something.
Imguis and game engines are much simpler to code than conventional GUI because you don't need to handle so much state.
Sorry, just: no. Game engines which don't handle rectangle updates are poorly designed junk.
BTW, most game engines do keep track of regions needing update - its one of the most important aspects of performance tuning, for any app which presents objects on a screen to the user. Usually, the OS is doing this for an app in the apps own context - game engines also do this, and if they don't do it well, they get passed over for better-performing engines.
(Disclaimer: contributor to the MOAI game engine, which does this very, very well, and which is an amazing way to do a UI - for any app..)
I just figured that I'd share what appeared to be a useful comment from someone else the last time I participated in a discussion about this, I'm glad I did as I now have a number of further resources to do better research.
Also, just took a look at MOAI, it looks pretty cool, I'll have to add it to the list of things to play with when bored.
https://www.lazarus-ide.org/
I'd also take issue with the notion that 2D UI frameworks based on game engines are more performant than their alternatives, because game engines are optimized for 3D graphics and often struggle with performance once your UI state becomes reasonable large.
Very well (it's a game engine)
> localization, and accessibility?
Poorly and not at all. Godot has a student adding PO files:
https://godotengine.org/article/gsoc-2020-progress-report-1#...
The GSOC project you linked to is about enhancing the existing .po based feature: "In Godot, we [already] have two ways of importing translation - by using CSV or PO files."
Here's a blog post about someone's experience doing a translation for a Godot game: https://sites.miis.edu/vprolow/2019/12/15/godot-game-localiz...
And here's an official tutorial: https://docs.godotengine.org/en/stable/tutorials/i18n/intern...
It supports this through use of its "Container" UI Controls--which have a bit of a steep learning curve but works pretty well.
> I'd also take issue with the notion that 2D UI frameworks based on game engines are more performant than their alternatives, because game engines are optimized for 3D graphics
One aspect of Godot that is a bit different in this regard is that pre-3.0 the focus was very much more on the 2D side of things, so the 2D support isn't just "a flat 2D plane in a 3D world" unlike some other engines.
Qt has some, but not all the way there, like Visual Studio has (but there are some good alternatives for Qt).
The other two pain points (for DCC): - HDR support (again across monitors) - Hi-DPI support (and again across monitors)
Once you start hitting issues above (among many small others), you realize how much there is to add (wacom tablet support? What next?)
> While you get a GUI inspector panel for your GUI components you are still forced to largely write the GUI in code.
Well yes. The time and experience (at least for me) has shown that designing UIs anywhere outside the code will eventually bite you. Not to mention that from the very moment a second person joins your team you can practically throw your version control system out of the window for UI files. Thanks but no thanks.
And really, you can drag and drop elements into the live previews and it writes the code for you, including automatically wrapping existing components in horizontal/vertical stacks as needed to arrange the layout. So SwiftUI still has some of the visual UI editor benefits, just broken into smaller pieces with a much more useful text representation.
With Godot it is possible to design the UI in code--the editor itself uses that approach, e.g.: https://github.com/godotengine/godot/blob/27d12092821df77a61...
> you can practically throw your version control system out of the window for UI files.
While not "perfect" with VCS (there's a bit of automatic-generated file content churn at times), Godot stores its files (UI & other) as plain text (not even XML) with a very shallow hierarchy, e.g. here's a "scene" file from a project of mine: https://gitlab.com/RancidBacon/godot-foreigner-export-demo/-...
While I wouldn't really recommend two people working on one scene simultaneously, if it were necessary for some reason, Godot does provide the ability to separate a scene into "subscenes" which could be worked on independently.
While it is possible to hard-code widget positions, with the Container-based layout method the values in that file actually get completely ignored & recalculated on the fly.
The fact that the values end up in the file at all is something I consider a bug/implementation flaw.
In Godot a UI Control has an "anchor" setting for each of left/right/top/down margin which affects where the margin value is measured from in relation to the bounding box. So (hand-waving a bit here), e.g. for, say a margin value of 10px, for the left margin an anchor value of 0 means "inset 10px from the left margin of bounding box" and with anchor value of 0.5 means "move left 10px from center of bounding box" and with anchor value of 1 it calculates relative to the right-most margin. (But for right margin an anchor value of 0 means "calculate relative to right margin of bounding box, and, somewhat confusingly, I think requires the value to be negative to "inset".)
What this means in practice, is that if you use an anchor value of 0 for all margins, even when you resize an element you don't need to adjust any of the margin values.
Unfortunately Godot (and Containers--even though they re-calculate all the margins themselves) default to an anchor value of 0 for left margin and 1 for right margin which means the right margin is a non-zero value & gets re-calculated & updated/save every time you adjust the layout.
In general the layout system works pretty well & is flexible but it does have some slightly confusing aspects (and in the past at least some implementation bugs) and is somewhat difficult to explain in text. :) (And it would definitely benefit from even more detailed documentation--than what it currently has--in terms of the "sizing flags" that determine how multiple Controls occupy/share the space available.)
So, in short: Once set up correctly, Godot UI layouts generally adapt well to different text-widths, font sizes and window dimensions.
I think the future of interactive immersive VR work environments is looking very strong so using it for GUI apps seems like a good first step.
The author of this article said that he is not a web developer and he has a pro-application perspective. I think he misses the huge opportunity for web properties to also render into Virtual Reality.
Out of curiosity I looked at some of the examples in the Oculus Quest SDK. Basically Android+3D, effective but there is lots of room for improvement.
Also I saw this Kanban board posted on Reddit earlier: https://github.com/alfredbaudisch/Godello
Heavypaint, mentioned elsewhere here: https://news.ycombinator.com/item?id=24046431
Java went with webapps thinking it'd be easier to manage distribution of the application if a browser did it for you. Or at least that's how the trends played out. It kind of works, but the real missed opportunity was all the client side processing and storage that desktop apps bring to the table.
From a quick search there's this: https://docs.godotengine.org/en/stable/classes/class_videopl...
(But that may not be a live stream, necessarily, I guess.)
Also there's this that may be relevant: https://docs.godotengine.org/en/stable/classes/class_spatial...
The latter is documented as:
"""
[...] enables the "shadow to opacity" render mode where lighting modifies the alpha so shadowed areas are opaque and non-shadowed areas are transparent. Useful for overlaying shadows onto a camera feed in AR.
"""
A search about accessibility immediately popped up github issues acknowledging the difficulty making screen readers work: https://github.com/godotengine/godot/issues/29736
There are some applications that mimic all those friendly native behaviors, but it tends to take a lot of work, and sometimes pushing updates when the OS behaviors change.
Even the Godot editor itself is not non-English friendly. It's got a horrible experience for any language that uses an IME. If you try to insert an emoji on Mac the IME won't even appear.
I am confident if Godot sees usage as a GUI/app framework, they will take care of that.
so godot will only see usage as a GUI framework for the use cases that won't see emoji or non-english IME.
Mentioning Electron to solve Unicode is like thinking about a bulldozer when you need to unclog your toilet.
Text input and manipulation is so incredibly ugly and hard, that basically nobody cares it enough to to it really well.
Unicode to start is complicated. Then you have things like bidirectional text.
Line breaking is complicated.
There are no accepted practices for a lot of use cases.
Hyperlinks. Embedded content like images.
Copying/inserting html and other formats.
Styling content.
Rendering 100 000 lines of styled content without screwing up user input.
Line-heights. Tabs. Font definitions that are ambiguous an inconsistent (a lot of font tables today still don't provide enough space for accents on capital letters, think Swedish - so you have broken looking text or have to 'fake it'). Screwed up Kerning tables.
No established standard for real pixelation and rendering - zoom in and you'll see font's can be rendered a variety of ways.
Emojis, fat finger cursor navigation on mobile devcies, input managers.
It's hard to describe how messy it gets because none of it is academic, it's not some scary-hard algorithm - it's just an incredibly ugly pile of cross-cutting code with a zillion little bits and pieces of corner cases.
And a big one for gaming engines: they don't render text 'natively'. You basically have to create textures. Every big of text, it's own texture. How big is the texture for 100 000 lines of code? Big.
This is actually one are where Qt falls flat. In the 'new and improved' Qt, they do everything in the GPU, if you try to load 100 000 lines of something the app will use up 1G of memory and puke. So then you have to magically code your way around it.
All for what? Why would you want to render text in a gaming engine in the first place ...
Then you discover that 'apps' and 'games' are really different things, and they use different tech for good reason. It only gets ugly when they really have cross paths.
> Why would you want to render text in a gaming engine in the first place ...
Just about every game needs text, including Unicode text. Every proper engine handles it.
The platform does not offer anything.
"Just about every game needs text, including Unicode text. Every proper engine handles it"
No, what they do is paste a few characters on screen, handling a more common subset of Unicode. They don't come close to handling most of the things I described above.
Not even Qt handles text well - Qt allows you to do some fun 3D things with text, but not you can't open 100K lines of formatted code like VSCode.
Webkit is just as bad - MS had to invent 'Monaco' a huge layer on top to be able to manage text properly and it's kind of a hack.
Simply put nobody does it well out of the box.
All major platforms offer advanced text rendering support.
How do you think Windows or macOS render their UI?
> what they do is paste a few characters on screen, handling a more common subset of Unicode.
Some games do that, in particular old ones or indies. Most games do actual text rendering properly.
> you can't open 100K lines of formatted code
You definitely can, but not naively. VS Code doesn't render all the text at once either and neither does any serious text editor.
No, they don't realy.
I think you're missing a few pieces in your understanding of what the platform does in these contexts
The platform does not support text rendering for Qt and such platforms. They are rendered 'from scratch'.
Some platforms offer some built in components, but even they are quite limited.
No platform offers the ability, out of the box, to do for example, a 'coded editor' with properly highlighted syntax. Not even close.
"Most games do actual text rendering properly."
They are 'rendering text properly' for the extremely limited subset of text that they put on the screen.
Have you ever used even a basic 'text editor' in a game? No? Because they don't even do that.
" you can't open 100K lines of formatted code"
"You definitely can, but not naively."
'Natively' means nothing on the context of 'browser'. If you mean to say 'the browser doesn't do it out of the box' - then ok, yes, we agree. And why not, because it's extremely hard?
There are 0 comprehensive text APIs that are built upon gaming or even 3D engines today. Most of the barely handle basic text formatting. They put a few lines of text on the screen in a limited number of languages, and that's it.
There are very, very few platforms that offer comprehensive text rendering, including Qt, GTK, and native platform components - they're basic.
Providing comprehensive text API is not only something that has to be layered on top of those things - they also have to 'hack' those platforms to work around inherent bugs and limitations.
That said, complete and robust i18n support may take a while, given the small size of the core development team (< 30 regular contributors) and the fact that text display is probably not the highest priority for a game development tool and engine.