Godot doesn't display native widgets, so it has no support for accessibility, for example to screen readers and blind users. Some people think blind people bring too little profit to care, but this is wrong for one single reason. There are some laws mandating accessibility, and more laws are being passed, for example in the EU. Even if you don't really focus on accessibility at this point, you always want to keep your options open, in case the law forces you to. If you choose Electron, WX or even QT, some minor tweaks will usually be enough to make it right. If you choose Godot, you will need to rewrite the whole thing from the ground, which might kill your business, or risk fines and litigation, which might also kill your business. This is even true about internal tools, as there are laws mandating accessibility of the tools used at the workplace, and you never know when a blind person gets hired for a job they theoretically should be able to perform.
This might sound very harsh, but it's important to get this right early, as one bad decision here is usually irreversible. Of course, this applies not just to Godot, but to any GUI tool which doesn't implement accessibility properly (including those that theoretically work on the web, but use canvas instead of DOM rendering).
As for the rest, I'm frustrated because you're partially right but also kinda defeatist and that makes me sad.
I went checking and found a long history of discussion about accessibility in Godot's GUI toolkit (because the Godot editor is built in the Godot engine). It's an active topic, spanning multiple tickets over years. Their stance has evolved dramatically over time, but they appear to be putting real effort into improving the situation. Here's what I think is the current tracking ticket: https://github.com/godotengine/godot-proposals/issues/983
Accessibility isn't a feature of Godot...yet, but it's obviously something that's important for mainstream adoption of serious software, especially non-audio-visual experience software. And it's obvious that people in the community care and are both asking for it and working on it.
If anything we need to keep doing this and revisiting it over and again and keep improving it, testing it, giving feedback, contributing. Because for as many applications that wouldn't benefit from this approach, there are as many that would.
Maybe what the community needs is a real-world application which would benefit from these accessibility features to help drive adoption and development.
- Almost no one does accessibility properly in web apps. Even native apps get it wrong more often than not.
- Using Electron does not give you accessibility in any way.
- What laws? I use everyday general purpose commercial applications, both webapps and native apps, with glaring accessibility flaws and I do not see anybody caring to sue.
- I don't know of any business doing general purpose commercial applications that has faced any issues with that.
Screen readers can still (badly) work on web sites that haven't been made with accessibility in mind. And if you find you need to add proper accessibility to a web or native app, you can. With something like godot, you might have to rewrite the entire GUI to get accessibility working properly.
> - Using Electron does not give you accessibility in any way.
Yes it does. Electron gives you basic out-of-the-box crossplatform support for accessibility, just like chrome. And you can tweak the screen reader output the same way you would a website. See: https://www.electronjs.org/docs/tutorial/accessibility
> - What laws?
EU: According to the first google result, by September 23 2020 all websites and mobile apps must be accessible to everyone, have a public accessibility policy, provide a feedback mechanism for users to report inaccessible content and provide a link to the enforcement procedure:
https://siteimprove.com/en-au/accessibility/eu-web-accessibi...
California (govt): As of July 2019 all websites made by the state of california must be accessible: https://www.levelaccess.com/california-passes-new-digital-ac... . There's similar results at the US federal level.
> - I don't know of any business doing general purpose commercial applications that has faced any issues with that.
You don't know anyone who's faced issues yet. Momentum behind these laws is growing in most countries, bolstered by the 2008 UN Convention on the Rights of Persons with Disabilities - which requires countries to "Provide information in accessible formats and technologies appropriate to different kinds of disabilities in a timely manner and without additional cost". In the US and Canada the law currently only requires government websites to be accessible, but its not a safe bet to assume things will stay like that.
Fairbanks points out that there's risk in every design. How much it should influence your architecture depends on how much it matters to your project.
He uses the example of installing a mailbox. You shouldn't approach that with the same level of planning you'd use to architect a building. They're similar projects in some sense, but risk with the former is so much lower that it isn't worth it.
In this case, for some projects, the risk of low accessibility might be significant enough that it should be high priority. For others, dependency churn or framework bloat might be higher. Or tooling capabilities. It depends on what you're building.
No biggie if one of them is opengl based and might be expensive to add accessibility to it...
Oh, and stop spreading fud in general, you might use an accessibility-friendly toolkit and still end up with a practically unusable for visually impaired ppl UI, just as you can make a custom coded UI screen reader friendly...
Just be honest, accept that UI dev will eat up at least 50% of your resources if you wanna do it right, don't cheap out on it, embrace re-writes and maintaining multiple versions of similar functionality things, and stop being afraid of new tech...
I haven't learn much about Godot yet (but I will after this post), but Flutter solved accessibility in declarative widget UIs in a way that might be a good example for others.
Isn't this also the case with Google's Flutter on iOS by default?
The solution is, as far as it is possible, to add accessibility to these frameworks.
Something somewhat common in videogames is to add one or several colour blindness colour palettes to the games.
I don't like this constant reinvention of wheels. Look at Blender, it also has its own, mice UI and many other specialized graphical, image and audio apps have. Flutter also renders its widgets.But none of them is as universal and flexible as those big, battle-tested frameworks.
They are no shortcuts, proper UI is a complicated thing.
For quick, simple UIs, you may like Tk or Python's module Tkinter [1]. It is capable of creating pretty fast UIs with little code. Gitk [2] Git UI is written in Tcl + Tk.
[1] https://www.tutorialspoint.com/python/python_gui_programming...
In addition to the tracking issue mentioned elsewhere, I'm also aware of this project which has the goal of improving accessibility within Godot--both for playing games made with Godot and also for making games in Godot (which is one benefit of the editor being built with the engine itself):
Nothing in software is irreversible
>>Godot doesn't display native widgets, so it has no support for accessibility,
Then it would be better to evangelize adding accessibility support into Godot.
>If you want to use this in a business, either for an internal tool or for an application you sell, this is a horrible idea. There are some laws mandating accessibility, a
That largely depends on the type of application and the target. There are some LOB applications that would never need accessibility because the jobs they are for require sight and/or hearing for safety reasons. For example if you are building a LOB application that is used on Factory floor with large machinery
If you're making something for free or for fun, then let curiosity guide you. Bureaucrats like yourself can comment all you want. I'll be making applications.
Imagine the headline "company goes bust due to regulatory violations after hiring blind person". That would basically be sending the message "never hire a blind person", because no company can ever be sure to be in compliance.
> Do you know of cases where not implementing accessibility really did become a big financial hazard?
"Jason Camacho, a blind resident of Brooklyn, N.Y., is suing 50 colleges over the accessibility of their websites.
The 50 lawsuits, filed in November, say the colleges are in violation of the Americans With Disabilities Act, as their websites are not accessible to people with disabilities. Camacho uses a screen reader and said he experienced barriers when trying to access the colleges' websites."
Source: https://www.insidehighered.com/news/2018/12/10/fifty-college...
In that case the main complaint seemed to be that they had more of an obligation because they were receiving federal funding.
1: https://www.nytimes.com/2015/02/13/education/harvard-and-mit...
2: https://www.thecrimson.com/article/2019/12/2/Harvard-settles...
Not sure what are you saying here. Are you saying that while it might become a law, companies that can't find the money to comply don't need to comply in such cases..? Or that it hasn't happened yet, so it's not bound to happen?
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...
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.
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.
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[...]
"""
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.
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.
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.
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!).
It is still just connecting blocks though as pierrec says below so it can take a lot of connections to get something done
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.
- 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.
I personally dislike the python ecosystem and am not missing anything.
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
It's simple and straight forward.
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 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:
$ 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
"From February onward, everyone, including open-source Qt users, will require valid Qt accounts to download Qt binary packages."
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.
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)
Why are they shooting themselves in the foot there?
sudo apt install qt5-default qtcreator
I think you could add `--install-suggests` to that command if you wanted to get everything and the kitchen sink.
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 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.
...
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.
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 have an (admittedly simple) application using QtWidgets that is under 10 MiB statically linked.
Particularly in Windows.
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/
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.
The get up and go speed of the super old windows forms approach was fantastic.
Now I'm supposed to use - XAML? UWP? WPF? Do these have great windows form designer still?
I'm talking speed between download and go with an GUI, a button, a text box (maybe data bound) etc.
This will age me, but for all the decades of "improvements" this tooling has, every time I've tried to do the little widget apps thing I used to be able to do trivially I end up wondering in the woods.
Paired with F# the proposed Elm-like model-view-update style would be the dream.
[1] https://devblogs.microsoft.com/dotnet/introducing-net-multi-...
In addition, we are enabling developers to write fluent C# UI and implement the increasingly popular Model-View-Update (MVU) pattern.
Ah, some SwiftUI envy.
https://docs.microsoft.com/en-us/dotnet/api/system.windows.f...
It isn't as powerful as WPF/UWP, and it has some caveats depending on the .NET Framework version, but it does the job.
> 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.
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.
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.
I am confident if Godot sees usage as a GUI/app framework, they will take care of that.
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.
so godot will only see usage as a GUI framework for the use cases that won't see emoji or non-english IME.
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.
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.
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.
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.
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.
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.
(Hint: I'm interested in mostly using this for creating a graphically rich but minimalistic distraction-free ADHD-friendly experience ...that could also be usable in VR for even more distraction free coding - I mean since most pro devs touch type anyway, using a keyboard in VR would just work for us, without any extra stuff.)
I'm sure the tooling is better by now, but I remember being pretty happy not to need to touch Pascal anymore by the late '90s. The APIs that expected Pascal conventions were often pretty miserable to use.
- 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.
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?)
Here's a good illustration of the program in usage: https://www.youtube.com/watch?v=JCY4dfVNq9Q
I found the hassle of setting up Qt painful, but it didn't scare me away. The final nail the coffin was their prioritization of Qt Creator over SDK integration. juggling two IDEs just didn't seem right with an existing codebase.
Curious what you mean by that? What did you need Qt Creator for that you couldn't do otherwise?
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.
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.
"""
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
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.
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.
I'm using cljfx these days and really enjoying it. For desktop apps I think it is a great choice [1].
The approach described using Godot could work well depending on the type of app, I think. For instance, this commercial app [2] is built using Kivy [3], which basically draws the controls using sdl+openGL, so a similar kind of setup as the Godot one described in the OP.
We have developed SimulaVR (https://github.com/SimulaVR/Simula -- a Linux VR Desktop) on top of Godot, and I think there's a lot of potential for this in Linux.
My main issue is the amount of learning necessary for doing "simple" stuff - I think onboarding of new people will be a challenge.
But I guess time will tell :-)
That said i do enjoy the experience - and some of the "game" features do give an amazing opportunity to make a nice interface.
I you go this route, do prepare yourself to spend your hours very different - making an animation takes no time - making a simple tab sequence takes time :-)
(I've been thinking of building an app to do photo triage, and Godot can certainly load up a bucketload of image assets and render them...)
It's like driving a car, you can have thousand of different models and yet you get inside one you can drive it right away. You don't have that kind of usability if everyone was doing custom GUI running with a game engine.
Same reason why there is a learning curve with UI in games, every games are different so every UI are also different, it takes time to naviguate properly in a new game.
Consistance is key.
Where there's a will, there's a way :).
Flutter is very "game-like" in the way it does its UI. It does not use the native graphics elements. Everything is a component that is rendered by Flutter's own rendering engine ... AND even the inputs (like touch) are handled directly in Flutter.
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.
For context, my interest is in:
* Cross-platform support.
* Ease of distribution.
* Ease of construction.
* Platform stability.
* "Licensing"/business issues.
* Accessibility.
In the past I've used Qt w/ C++, Qt w/ Python, web w/Python backend, Python w/embedded web server and dabbled/looked into things like wx etc. (Oh, and, MS Access with VBA. :D )
# Platform Native UI
If you want/need Platform Native UI, then Godot is not going to work for you, period. But neither are most of the other cross-platform options because if they're only 95% they're not native. My impression is that if you want platform native and cross-platform then per-platform clients w/shared backend implementation is pretty much required.
But I also think that platform native (as much as I might like it) is not necessarily mandatory for successful product, see, e.g. Slack.
I think the key around this is once you've chosen to not be platform native don't pretend to be platform native. Lean into making the UI tailored for your application.
And with a game engine there's a whole lot of space to lean into in this regard--particularly in relation to visualisation.
If you're happy with 95% and don't care about any other aspect then likely Qt will be a contender for you.
# Ease of Distribution
Trying to distribute a Qt + Python app as a single binary (within the last 2 years) was how I ended up ditching Qt & using an embedded web server instead. Despite all the effort & projects trying to make this work, IMO it still doesn't.
With the small initial Godot download and, a (admittedly half gig) "templates" download containing the cross-platform app "shells", it's possible to export to Windows, Mac, Linux, iOS, Android & HTML5. Depending on the platform the output might be a single binary, a disk image, zip file or binary + support files but where required traditional packaging tools can also be used.
This is really powerful for me (as both a developer & user) when the platforms I use (primarily Mac/Linux) are not in the majority & frequently get left out of releases.
# Ease of Construction
In relation to games, the highest praise I have for Godot is:
* Since I downloaded Godot I've actually made and released games.
I've found the integrated nature of the IDE really supports iterative development.
Game-making is often a very collaborative effort and because Godot has been developed (in part) to enable non-developers to not have developers be the bottle-neck it has visual-based tools & a node/component based architecture which also can make it a powerful tool for other technical but "non-developer" people.
# Why not use web technologies?
If your project makes sense as a web site then, make it a web site.
If you want to have a standalone app, you have experience with web technologies and memory/performance aspects aren't an issue, then, sure build it on Electron.
But if you can do those things, you can almost certainly use GDScript and gain the benefit of an integrated IDE and comparatively tiny downloads. (And still export it to HTML5/WebAssembly--admittedly currently probably with a slower initial page load time--but it's still an option.)
Additionally, currently Godot runs on older OS (e.g. even back as far as Mac OS 10.9) than Electron does which keeps getting dragged along to newer versions by Chrome's requirements which seem to place little emphasis on supporting older machines/OS.
# Why not Qt?
Ah, Qt, I really want to like you.
If Qt works for you, then use it.
But my experience with Qt has been one of a business that continually seems to struggle with how to survive; tries to stretch their license compliance in terms of LGPL & contract with KDE to breaking pointing (because, really, they wish they didn't have that constraint at all); and, a continual churn of the underlying technology that results in apps that only support newer & newer OS/Qt versions even if they don't require anything more than, say, Qt 5.2.
If you're a big corporate and/or if a 95% cross-platform solution is enough, then I think there's still situations where Qt probably makes sense but in terms of my niche desktop application development needs it's just too much hassle.
# Is Godot ready for applications now?
Somewhat. Obviously if your application is a game & the required feature set matches Godot's, then yes. :)
Based on my own experience using Godot to develop non-game applications tends to run into some areas of its feature-set which have seen less attention & so have bugs, lack features and/or lack documentation. (e.g. complex Tree controls, more sophisticated font rendering (e.g. kerning), very complex layouts.)
Overall, I think Godot is at a stage where a bunch of people (including OP) have realised it has potential around non-game application development but also has some rough edges in that regard that still needs to be improved.
Given the size & focus of the development team up to this point that's not surprising but I'm excited to see where it may go in future.
# A Note on Accessibility
As mentioned elsewhere in the comments, Godot also unfortunately doesn't currently have a great accessibility story.
There is at least at least one project that I know of that is working on improving that: https://github.com/lightsoutgames/godot-accessibility/
In addition, Godot's node-based UI system in particular I think lends itself to retro-fitting better accessibility support more than a different architecture might.
But if you need your app to be accessible today then Godot probably won't meet your needs.
# Bonus: Are InfoSec tools a potential niche for Godot-based apps?
I think that's a strong...maybe. :)
To explore the potential of Godot for non-game apps I've been working on developing a Godot-based hex viewer/editor with a focus on binary/format reverse-engineering & visualisation motivated in part by a talk where someone complained that hex editors hadn't done much new for years.
Early in development I realised that InfoSec has a combination of aspects that might make it particularly well suited for Godot-based apps:
* Many people who are technically skilled but consider themselves "non-developers".
* Has problems to solve that benefit from new forms of visualisation (often with large amounts of data) not met by standard UI.
* Has an affinity for flashy visuals. :)
* Need tools that don't only run in the cloud.
(In InfoSec and want to make this happen? I'm available for hire. ;) )
It was easily one of the nicest projects I've ever done - no web stuff to deal with, only MOAI for the core layer, with Hanappe doing the regular work of providing the GUI controls and abstractions I need - scroller views, buttons, sliders, etc.
And since that experience, I really yearn for a similar kind of framework on the better-supported engines out there (MOAI has gotten a bit long in the tooth in the last few years).
Its really quite a neat feeling to ship an app that uses highly optimised game code for its lower interface abstractions, with a mid-layer framework on top of it - which then can be packaged and run on any platform: iOS, Android, Windows, Linux, MacOS - and looks the same, functions the same, on every platform.
It does take some courage however. You do have to make a great UI experience for the end user - if its half-assed or buggy, the whole thing falls down. But, when it works, it works very well and blows away the whole Web framework. I really don't like doing apps any other way these days ..