Is Making Advanced GUI Applications with Godot the Future? (2020)(medium.com)
medium.com
Is Making Advanced GUI Applications with Godot the Future? (2020)
https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b
62 comments
The problem with Qt and Electron is that there is no GUI editor worth its salt right now.
C#+WPF/UWP had Expression Blend since the mid 2000s and it's only been getting worse ever since (and MS said they have no interest in bringing MAUI support to Blend which is probably their biggest foot-gun yet).
Godot has the same sweet features that Blend had but in a modern platform and with cross-platform export, yes it has many many rough edges, but it's been getting visibly better year after year and it shows no sign of stopping.
Anyone who thinks building UIs in Electron today is peak developer UX should just check out what it was like to build on WPF in 2009. They had all the shiny of today plus sane ways to do things eg. keyframe animations with custom easing etc without having to resort to insane workaround like importing them from After Effect with custom libraries.
And yes I know about Qt Design Studio, but my experience with it was AWFUL, from being an absolute minefield in the installation experience due to how Qt tries to upsell you on their commercial offering, to having a UI flow that looks like Blend if you took out most of its features out, to having to deal with QML (which honestly feels like a downgrade coming from XAML) and then you have to tie everything with C++? It wasn't appealing back then and honestly it still feels like an alpha today.
C#+WPF/UWP had Expression Blend since the mid 2000s and it's only been getting worse ever since (and MS said they have no interest in bringing MAUI support to Blend which is probably their biggest foot-gun yet).
Godot has the same sweet features that Blend had but in a modern platform and with cross-platform export, yes it has many many rough edges, but it's been getting visibly better year after year and it shows no sign of stopping.
Anyone who thinks building UIs in Electron today is peak developer UX should just check out what it was like to build on WPF in 2009. They had all the shiny of today plus sane ways to do things eg. keyframe animations with custom easing etc without having to resort to insane workaround like importing them from After Effect with custom libraries.
And yes I know about Qt Design Studio, but my experience with it was AWFUL, from being an absolute minefield in the installation experience due to how Qt tries to upsell you on their commercial offering, to having a UI flow that looks like Blend if you took out most of its features out, to having to deal with QML (which honestly feels like a downgrade coming from XAML) and then you have to tie everything with C++? It wasn't appealing back then and honestly it still feels like an alpha today.
You can't make the argument that people only use Godot for application development because it's what they're familiar with, and then bring up Electron as a countercase. Electron literally only exists because of existing familiarity with web tech.
Web tech has massive momentum and developer base fed from outside Electron where as Godot is nowhere close.
Web applications are still applications, and web applications and desktop applications are closer than applications and games.
> … "and web applications and desktop applications are closer than applications and games."
I'm not really sure how that logic follows, as games are also just applications, and although the web was not designed as an application platform, but rather as a hypertext document browsing / delivery platform, yet people managed to wrangle it into performing fairly decently as an application platform, so why not game engines for application development? (I've actually seen more than a few really interesting and useful applications built in Godot and other game engines already, and I'm quite sure more are coming.)
I'm not really sure how that logic follows, as games are also just applications, and although the web was not designed as an application platform, but rather as a hypertext document browsing / delivery platform, yet people managed to wrangle it into performing fairly decently as an application platform, so why not game engines for application development? (I've actually seen more than a few really interesting and useful applications built in Godot and other game engines already, and I'm quite sure more are coming.)
> The expectation that godot will cover two major disciplines is possible... but unlikely.
I disagree. I think it's just a matter of time. I think Godot isn't ready yet, but will be soon. Just got to wait a little longer.
I disagree. I think it's just a matter of time. I think Godot isn't ready yet, but will be soon. Just got to wait a little longer.
I've seen a lot of applications posted to Godot subreddits, so it's clearly a thing. Godot has some clear shortcomings when it comes to application development, particularly with layout and text rendering, but it's not at all infeasible. I wouldn't do anything important with Godot at this point, though, at least not without C#. GDScript ... is better than GML and Dark Basic but worse than any language you would actually want to use.
I think the important takeaway from reading the article is how crucial editor design is.
I think the important takeaway from reading the article is how crucial editor design is.
I really appreciate how Godot is the only one of the 3D engines that not only offers good 2D support as well (like say Unity) but really treats 2D as a first class citizen. I also REALLY appreciate how it's the only one that has decent built-in support for vector drawing.
That said, so does Canvas, and HTML & CSS are a tried and true portable powerhouse UI combo, and JS/TS are infinitely more relevant than GDScript, so I am camp Electron. Especially now that web 3D is also better than it's ever been. I would rather see more work to make Electron gamedev-friendly than work to make Godot appdev-friendly
That said, so does Canvas, and HTML & CSS are a tried and true portable powerhouse UI combo, and JS/TS are infinitely more relevant than GDScript, so I am camp Electron. Especially now that web 3D is also better than it's ever been. I would rather see more work to make Electron gamedev-friendly than work to make Godot appdev-friendly
I very much wish so.
I tried using Godot at work and got turned down. They wouldn't even allow a demo or the "IDE" to be installed. Must use our licensed contract junk from leaches on government dole, because those are what's approved by cybersecurity.
I now have a few more interview questions to ask of future employers and things to look out for during interview tours.
I tried using Godot at work and got turned down. They wouldn't even allow a demo or the "IDE" to be installed. Must use our licensed contract junk from leaches on government dole, because those are what's approved by cybersecurity.
I now have a few more interview questions to ask of future employers and things to look out for during interview tours.
The whole Godot Editor is also available in the browser under https://editor.godotengine.org/
You might want to give that a look :)
You might want to give that a look :)
Am I weird that I enjoy HTML/CSS for GUI and Layout? With CSS grid of course. Hell I love Godot, but the fact that you can't do something as simple as give a component a max width is so annoying.
Browsers are fantastic cross-platform UI frameworks. Writing a local page is a great way to start prototyping. The problem is that they are very slow and resource-hungry. All those dynamic styling and DOM niceties come with a significant cost.
WASM can help, but the webdev ecosystem encourages developers to use fat JS libraries for most tasks.
Your browser prototype will probably start to chug once it grows to the point that it needs to juggle >1000s of objects. Native apps have the potential to be much more efficient and responsive.
They also tend to work better and more consistently on older/cheaper hardware. I think that every website developer should use a $200 Chromebook for development at least a few weeks out of the year. Most of the world is not using a new M2 macbook, and it's easy to lose sight of that when you spend your time working on new features.
WASM can help, but the webdev ecosystem encourages developers to use fat JS libraries for most tasks.
Your browser prototype will probably start to chug once it grows to the point that it needs to juggle >1000s of objects. Native apps have the potential to be much more efficient and responsive.
They also tend to work better and more consistently on older/cheaper hardware. I think that every website developer should use a $200 Chromebook for development at least a few weeks out of the year. Most of the world is not using a new M2 macbook, and it's easy to lose sight of that when you spend your time working on new features.
My usual solution for that problem is parent the control to a HboxContainer with a set width, buts it by no means ideal. Is there a working proposal to add max width? 4.0 would be a good time to add it.
Yeah, Godot has no concept of a flow layout because for games it doesn't matter, all layouts are fixed anyway. That's definitely something the box model of HTML and CSS do better.
A lot games nowadays use some form of HTML/CSS, have a look at Coherent Labs and their products [1]
[1] https://coherent-labs.com/products/coherent-gameface/
[1] https://coherent-labs.com/products/coherent-gameface/
Obviously games written with HTML and CSS do, but I was specifically referring to non-browser platforms.
Making GUIs with game engines is the future not because they are easy to develop with, but because the moment AR and VR become common we already have tools to make 3D interfaces
I don't think 3D interfaces really offer anything of value beyond 2D interfaces. I've never once in my life been using software and thought the GUI would be much better rendered onto the inside of a cube or something.
You might want to read my post again, I specifically talked about AR and VR applications
I'm looking at moving my desktop application(s) from Microsoft WinForms to Godot, but its worrying that no one else is doing it yet. It certainly seems appealing, especially compared to the other options, but its not at all clear what the limitations and risks are without investing a lot of time/money into it.
>It is not made for reusable components, like real GUI toolkits.
The latter needs some explanation. The web way of creating reusable components is through some kind of templating. You are basically just copy pasting a chunk of HTML several times representing your new custom component.
That's not true since HTML allows custom elements.
That's not true since HTML allows custom elements.
I agree one would have a similar experience as the author when learning Flutter, but it is because on mobile you need to have all these shiny things so it's no wonder that documentation covers it in detail. However, you can perfectly write Flutter apps without animations, transitions and the like.
Yeah… in Dart, which nobody knows.
In my experience Darti s not a problem at all. It's a simple boring javaesque language you can learn relatively quickly if are already proficient in other languages, plus you don't really need to use all features of Dart to create multiplatform apps.
What if more difficult is Flutter itself: you basically need to learn everything from scratch: the architecture, they way to write apps, plus all the library functions you may need. My experience is that this particular aspect took me much longer than learning Dart itself.
What if more difficult is Flutter itself: you basically need to learn everything from scratch: the architecture, they way to write apps, plus all the library functions you may need. My experience is that this particular aspect took me much longer than learning Dart itself.
Or GDScript, Godot’s language, which nobody knows. This is my major barrier to even considering Godot right now. Perhaps once their Kotlin bindings are ready for production…
Isn't it an extended Python? I thought I read that somewhere.
can we not use any other language for it, like C, Cpp, etc
There are plenty of bindings for Godot, of various quality[0].
Godot is changing their plugin system in a future version, which hopefully will make language support much easier.
[0].https://github.com/Vivraan/godot-lang-support
Godot is changing their plugin system in a future version, which hopefully will make language support much easier.
[0].https://github.com/Vivraan/godot-lang-support
Game engines have a lot of nice tech and maybe one will get popular for apps one day. The major issue I see is that they're simply tuned for a different UX. They're usually very power hungry (both amps and CPU cycles) and designed to push as many pixels as possible.
It's the exact opposite of the modern view layouts that try to cache view images to reduce the draw work.
It's the exact opposite of the modern view layouts that try to cache view images to reduce the draw work.
But you guys, this software isn't practicing good Design. None of those UI elements provide me with any _satisfaction_. I don't care how efficient it is if it doesn't follow solid Design principles (like massive checkboxes that take seconds to activate).
/s
/s
I’d consider Godot but it’s unusable for deploying on mobile platforms.
We need desktop and mobile, making Qt/QML our only apparent practical choice.
BTW, we built a desktop app in QML and the GUI performs great. The resizing is smooth and elegant.
We need desktop and mobile, making Qt/QML our only apparent practical choice.
BTW, we built a desktop app in QML and the GUI performs great. The resizing is smooth and elegant.
> We need desktop and mobile
Why not Flutter?
Why not Flutter?
Because none of us knows Dart, nor are any contractors likely to know it. Also, based on research I did before starting a cross-platform project, you still end up writing a lot of native code on each platform when using Dart. At that point, you might as well just write native apps.
You already know Dart, it's very familiar if you have done some C# / Java etc previously.
Well I'd argue that making GUI applications is not the future, so that doesn't bode well for making GUI applications with Godot.
I'll bite. Why are graphical user interfaces not the future? They're certainly the past and the present.
The sad future is, the browser is the new desktop gui.
I think that’s the present (electron apps have been all the rage for the last few years), but maybe not the future. There’s much effort being put into native-ish GUI programming in recent years such as Godot and Druid.
Why do you think Chrome OS isn’t more successful then? (Outside of specific markets like education.)
The Walmart near me stopped selling Windows PCs and only sells Chromebooks. ChromeOS is extremely successful.
2% marketshare despite the incredible pricing, but ok.
For an OS most of us would consider useless that's been around for maybe a quarter of the time desktop Linux has been and half the time OSX has 2% is pretty impressive.
As to the pricing, it's not like Desktop Linux doesn't work very well on cheap hardware either. OS popularity comes down to social things like PR (especially with children) and has little to do with merit.
As to the pricing, it's not like Desktop Linux doesn't work very well on cheap hardware either. OS popularity comes down to social things like PR (especially with children) and has little to do with merit.
> For an OS most of us would consider useless
It's almost as if readers of HackerNews aren't the target audience of ChromeOS.
> As to the pricing, it's not like Desktop Linux doesn't work very well on cheap hardware either.
It's almost as if potential Linux users aren't the target audience of ChromeOS.
It's almost as if readers of HackerNews aren't the target audience of ChromeOS.
> As to the pricing, it's not like Desktop Linux doesn't work very well on cheap hardware either.
It's almost as if potential Linux users aren't the target audience of ChromeOS.
The present? The very vast majority of applications are ran in the browser nowadays.
Which run command lines?
Godot can export to web.
https://docs.godotengine.org/en/stable/tutorials/export/expo...
Godot can export to web.
https://docs.godotengine.org/en/stable/tutorials/export/expo...
The docker desktop one for instance.
No.
Inasmuch as desktop applications continue to exist, the future is Electron. The only applications for which there is still demand for traditional GUI apps are military and medical device applications.
Electron is literally write once, run anywhere. It's leaps and bounds beyond anything else in this regard. RAM is cheap, and a few hundred megabytes per installation are a small price to pay for increased productivity and accelerated time to market.
Inasmuch as desktop applications continue to exist, the future is Electron. The only applications for which there is still demand for traditional GUI apps are military and medical device applications.
Electron is literally write once, run anywhere. It's leaps and bounds beyond anything else in this regard. RAM is cheap, and a few hundred megabytes per installation are a small price to pay for increased productivity and accelerated time to market.
Inasmuch as desktop applications continue to exist, the future is Electron. The only applications for which there is still demand for traditional GUI apps are military and medical device applications.
Oddly specific, and definitely authoritative-sounding. You might be correct but it's the sort of wording that demands evidence in support to differentiate it from pure partisanism.
Oddly specific, and definitely authoritative-sounding. You might be correct but it's the sort of wording that demands evidence in support to differentiate it from pure partisanism.
When I see a job req out there for traditional desktop GUI skills (C++, Qt, Win32, etc.) it's for a military application or a medical device.
I did a quick search on Qt and the first result was entertainment/broadcast. Second result was defence.
Godot is fine for GUI in Games and 3D apps. And that's it.
I personally prefer not designing my gui but coding it.
I met a guy who said he wanted to write whatever documentation, essentially a gui in Godot and I was like, why not use the proper tool for the job. Well he said he's familiar with Godot so he'd write it in Godot.
And now this.
I was learning about Android development, jetpack compose, the new thing where you essentially write components in code, I prefer it over the old way, gui design with Android Studio in xml files. I guess I can get used to both but would prefer jetpack compose because it's so similar to "the web wayTM".
I'm guessing if you're used to graphical layout and design you'd disagree so TL;DR it isn't for me, but I've had Godot on the list of things to get into or at least try to scratch the surface and create a test project with it.
I met a guy who said he wanted to write whatever documentation, essentially a gui in Godot and I was like, why not use the proper tool for the job. Well he said he's familiar with Godot so he'd write it in Godot.
And now this.
I was learning about Android development, jetpack compose, the new thing where you essentially write components in code, I prefer it over the old way, gui design with Android Studio in xml files. I guess I can get used to both but would prefer jetpack compose because it's so similar to "the web wayTM".
I'm guessing if you're used to graphical layout and design you'd disagree so TL;DR it isn't for me, but I've had Godot on the list of things to get into or at least try to scratch the surface and create a test project with it.
[deleted]
psyc(3)
Godot has those features because game devs often need to make UIs for the game e.g. menus, etc. A decent game engine has to have that kind of functionality. Godot dogfooding is not a good indicator of it's potential as a ui toolkit. It's probably easier for them since they might need specialized components and because they're already familiar with the tools. There's a very strong advantage unique to them.
There are alot of edge cases and broader applications that the right tool for the job like Qt and even electron cover because that's what they're specialized for.
The expectation that godot will cover two major disciplines is possible... but unlikely.