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.
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).
One nit to pick; Electron is just HTML/CSS/JS and accessibility can be as good or bad as any other website.
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.
> - Almost no one does accessibility properly in web apps.
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:
> - 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.
The screen reader is not supported or useless on most web apps.
Again, we are talking apps and their GUI (web and native), not sites or documents.
> With something like godot, you might have to rewrite the entire GUI
Again a "might". I don't see any reason why you need any "rewrite".
> laws
Those are not for general purpose commercial apps as I wrote, only for public or specialized apps.
> You don't know anyone who's faced issues yet.
So then it is fear mongering, aka FUD.
> Provide information in accessible formats and technologies
Information, not GUI on apps.
Public information, at that.
It is simply impossible to require at the moment accessibility for web apps or native apps.
It does not even make sense for a huge amount of software. For example, an image editor or the vast majority of games cannot be accessible for a blind person with current technology.
Accessibility is critical on information and documents, not on common apps. That is why things like websites using fancy web frameworks just to display text is bad because they tend to break it. Nobody is discussing that, you are conflating apps with documents.
If you've made a "web app", it must be accessible through the web, i.e. it is either a web site or a part of web site, according to all sorts of laws including probably the ones mentioned by the GP post.
Forget about the fear-mongering - think about the actual people with disabilities though.
If you're in the public sector, or have customers in the EU or Australia, you might get sued or fined if your app isn't accessible.
Weirdly even in the US you might not be in the clear for internal tooling. My understanding is its illegal to refuse to hire a blind person because they're blind. If you hire someone who's blind and they can't do their job because your internal tools are written in Godot, you might be leaving yourself open to discrimination suits. Not a big deal when you're a startup, but it will matter at google / fb / etc. I'm sure google has blind employees today who care a great deal about being able to do their jobs.
That sounds like a legal minefield, with more mines added over time.
In short, if you aren't making a video game or a toy, it seems like good advice to use tools that work with accessibility.
1. There is no law on the horizon that will require any accessibility for general purpose commercial apps.
2. Further, one can add accessibility features on Godot or other engines if needed. No technical limitation whatsoever.
3. If such laws came to be in a decade or two, engines and frameworks of all kinds will most likely support those features on their own.
4. The only case you can make against Godot is that someone has a company which hires people; and finds a blind person that is as productive as a non-blind to the point they are the best candidate for the job; and the company is in a country with such laws; and someone is an asshole that does not want to hire such person even if they are the best; and the position requires to use Godot tools; and the tools are non-accessible to begin with; and that someone does not want to spend the money to make them accesible; and the rejected candidate sues you and wins the case.
No business will even think about such an scenario. In an ideal world, they would. In the real world, they don't. And I am siding with the blind person in such a case and hoping such a company is busted in that case. But the case is extremely rare.
So, as a busines risk, for a commercial startup, this is pretty negligable, right?
Even if they widen the scope, EU commercial laws on this kind of thing (e.g. content filters) tend to be only applied to companies over a certain revenue level (10m euros for the content filters).
Also, EU regulation is enforced differently to US regulation. EU regulators tend to ask nicely the first time, and only impose fines if it's a repeat offence, or the company has flat-out refused to do anything about the problem.
In other words, even if the regulation scope is widened, anyone building their GUI with Godot will probably have enough revenue and be given enough time to rebuild it completely before they'll reach the point of "business-killing" fines.
<of course, being accessible is a good thing in its own right, and I'm glad Godot appear to be doing something about it>
> They are not applicable to websites or applications built in the private sector.
The Americans with Disabilities Act, however, is applicable to private businesses; though (unless things have changed recently) there is currently an unresolved three-way split in federal circuits about high it applies to website with the Third Circuit saying it doesn’t, the First, Second, and Seventh Circuits saying it does generally, and the Sixth, Ninth, and Eleventh Circuits splitting the difference and saying it does if their is sufficient nexus between the website and a physical location of business, and the California State Courts seem to (in applying the state Unruh Civil Rights Act, which includes among it's triggers ADA violations) holding that it is at least applicable in the nexus case.
George Fairbanks's book _Just Enough Software Architecture: A Risk-Driven Approach_ comes to mind.
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.
Cut the crap, if you're app is really successful you're gonna end up re-writing the UI at least three times, trust me, and you're probably also have to maintain different multiple UIs (think Android native, iOS native, web etc.)...
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...
But HTML/CSS/JS is horrible experience even for non blind people :(
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.
Yes, at the end of the day, one can see why there are UI frameworks like Qt, GTK, Cocoa. It took many, many, many years and people to develop them and they are designed for complex desktop interfaces.
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.
It's fair to identify accessibility as an area where Godot is currently lacking.
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):
It's also very possible for existing employees to require accessibility as time goes on. Either old age or an accident can leave them less able than before.
Well, if what you are saying were 100% true, the entire VST market would be non-existent. (I agree with you to some extent, but let's not exaggerate to make a point.)
>>>This might sound very harsh, but it's important to get this right early, as one bad decision here is usually irreversible.
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
It's easier to pull out a soapbox and make ridiculous speeches like these, than to actually make a gui application.
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.
He's not a bureaucrat. He's a blind person who, I'm sure, has been frustrated many times at the inaccessibility of an application that he needed or wanted to use. So go ahead and make your applications, but please try not to block people who need and want to use them.
Are you speaking out of professional experience? Do you know of cases where not implementing accessibility really did become a big financial hazard?
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.
You don't need to hire a blind person to be compliant with regulations. What if you are building consumer facing products? Can you pick who your consumer will be? What stops a blind person from using your product? And what if the user is suffering from another physical disability which doesn't let the user operate a keyboard/mouse? What if the employee were a medically fit person but met with an unfortunate accident and lost his/her eyesight/limb and have to now continue job after recovery? How can s/he continue their job? Will you fire the person? You never hired a physically challenged person but s/he can always become physically challenged due to some accident later.
> 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."
What if tomorrow some change of parameters makes my business impossible? I'll go out of business. That's always an option.
Dealing with every possible risk ahead of time generally isn't an option.
> "Jason Camacho, a blind resident of Brooklyn, N.Y., is suing 50 colleges over the accessibility of their websites.
This is referring to public websites, which arguably are covered by the ADA.
I'm looking more of a story like "We wrote all our software without regards to accessibility. Then we got sued. It bankrupted us."
If this was a real problem for software in general, why is there no cottage industry of shady lawyers using people with disabilities to sue software vendors in particular? There's obviously lots of software that is not accessible, or not accessible enough.
> What if tomorrow some change of parameters makes my business impossible? I'll go out of business. That's always an option.
Yes and no one can sue you for going out of business. But you can be sued for violating a law while your business is in operation.
> Dealing with every possible risk ahead of time generally isn't an option.
No you need not if you use standard software development tools that do it for you. You would need to worry about it if you plan to implement everything on your own.
> If this was a real problem for software in general, why is there no cottage industry of shady lawyers using people with disabilities to sue software vendors in particular? There's obviously lots of software that is not accessible, or not accessible enough.
When there is a clear law that states that you have to make your software accessible you have no choice but to implement accessibility. For personal use you need not. For open source projects, the implementation rests on the shoulders of those using the project for end-user facing software. You can get away with it for a while, just like you can get away with using pirated software. But then law will catch up anyways. Just because there is no precedent set doesn't mean that it is legally allowed. Would you want to be the first test case? A scapegoat? I bet not!
As far as why there are no cottage industry of shady lawyers: Maybe those shady lawyers have bigger fish to catch. Maybe there isn't much awareness about it in the legal circles. Could be variety of reasons why.
> No you need not if you use standard software development tools that do it for you.
The belief that you just need to use "standard toolkits" and accessibility "just works" is wrong.
> When there is a clear law that states that you have to make your software accessible you have no choice but to implement accessibility.
There is no law that mandates implementing accessibility for all commercial software.
> As far as why there are no cottage industry of shady lawyers: Maybe those shady lawyers have bigger fish to catch. Maybe there isn't much awareness about it in the legal circles. Could be variety of reasons why.
...or maybe the law doesn't actually say what you think it says.
> The belief that you just need to use "standard toolkits" and accessibility "just works" is wrong.
Toolkits provide you the tools to do accessibility right. Toolkits don't do your accessibility for you. That is the biggest difference. You just misunderstood what I said.
> There is no law that mandates implementing accessibility for all commercial software.
Wrong! It applies to all software. Period.
"The Department of Justice (DOJ) published the Americans with Disabilities Act (ADA) Standards for Accessible Design in September 2010. These standards state that all electronic and information technology must be accessible to people with disabilities.
The ADA differs from Section 508 regulations, which are an amendment to the Rehabilitation Act of 1973 and apply to all information technology, including computer hardware, software and documentation."
In fact, the DOJ clarifies it further that accessibility is paramount and that even though the regulatory process isn't complete on paper doesn't mean that the software should remain inaccessible in the meantime.
'"The Department is currently developing regulations specifically addressing the accessibility of goods and services offered via the web by entities covered by the ADA. The fact that the regulatory process is not yet complete in no way indicates that web services are not already covered by title III."'
Harvard & MIT were sued for putting up free lectures, because they didn't have captions[1]. Harvard eventually settled[2], not sure about MIT. I believe MIT's response was actually to pull a lot of the lectures, but I don't know if that stuck.
In that case the main complaint seemed to be that they had more of an obligation because they were receiving federal funding.
this is how things work these days, for the sake of equality, minority overrule majority everywhere, i.e. if something makes a small percentage of people unhappy, then it is too unfair, the solution to play it safe, is that let's get rid it of for all.
Are you complaining that the United States has laws to make sure organizations don’t simply choose to ignore the needs of blind people, deaf people, and other people with disabilities?
Not the person you replied to, but I do think it's ridiculous that they were able to sue them over free content. All it did was put up barriers against dissemination. I know at least one institution removed lectures because of it. Those courses are just... Gone now. Poof.
> Are you speaking out of professional experience? Do you know of cases where not implementing accessibility really did become a big financial hazard?
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?
See, in the USA we have this thing called the Americans with Disabilities Act, under which providing accessibility options for people with disabilities to access your goods and services is required in order to do business.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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?
> 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[...]
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.
>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.
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.
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.)
> 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
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.
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.
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!).
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.
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!)
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.
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.
> 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
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.
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.
> 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 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.
Yeah no kidding, choosing a GUI framework is pretty difficult task... all of them suck for a different reason :-).
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.
Several years ago using Unity3d to make an advanced cross platform (half business half industrial) GUI was an excellent experience and result.
So yes, I readily believe modern game engines are good for cross platform GUIs and may conquer a niche here.
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.
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.
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.
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.
Nice post. I look forward also to a future where Godot helps facilitate VR (office) applications as well.
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.
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.
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.
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.
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.
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.
I think Lazarus is a much better environment for creating desktop apps which are small, cross-platform and very fast. The component architecture is much more advanced than Godot and you have access to a huge number of components. Extending these components or creating new components is also very easy.
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.
That's good. Converting between pascal and C calling conventions is one part of the 1980/1990s that I have absolutely zero desire to revisit.
I do recall that some of the Object Pascal class hierarchies that got developed were quite nice, and I am glad to hear there's more development continuing that direction.
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.
My question - what happened to microsoft in this space?
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.
I'm pretty excited to see where the new .NET MAUI [1] goes. It's still in development, but it seems like it could be a great contender for fully cross-platform native UIs.
Paired with F# the proposed Elm-like model-view-update style would be the dream.
You can do the "WinForms approach" with WPF/XAML still, but once you got the ideas and concepts behind MVVN, observables, bindings, converters, collection controls and so on, there is absolutely no turning back and you start to miss that stuff on WinForms.
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 have been playing around with Godot (to help my kids) and, to be honest, I had largely the same idea. For personal apps that have simple GUIs and have no formal spec, it might be just the ticket.
(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...)
That article is very flawed and also misses a critical point about UI in general, the reason why Windows feels like Windows in the last 20 years is because of UI/UX, I used Windows all my life and when I have to open a new app eventough I never used it before I can naviguate easily, everything makes sense, I click it does what it's supposed to, pop messages are all the same, menu looks the same, they all follow the same standard.
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.
If you're going to do something like this, just use Flutter. It's the same principle, draw pixels to a screen, but it has a lot of advantages over Godot for application development, such as accessibility and only rerendering components when they change.
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
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
> 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)
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.
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.
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.
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.
> 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.
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.
Not familiar with godot, but the GUI reminds me a lot of the blender GUI. I always wondered if the devs would ever spin out that GUI so that it became a library, because it always felt blazingly fast compared to e.g. Qt or GTK
An underlying tone of this article which most people in this thread have missed, was the impact of hitting the ground running. Godot quickly gets something on the screen for someone to build on. Qt is difficult to get something running. The impact of this makes technical benefits one way or the other moot. After all, if it works, who cares what technology is better?
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.
> 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?
When I came here I was hoping to hear all about godot making minority report type futuristic GUIs... I was surprised to see it was all about a game engine making regular every day 2020 UIs!
Reminds me how in 2015 I built a web server in Godot. It's very limited, uses busy polling to listen for new connections, but nothing else was available at the time (IDK about current Godot). https://github.com/KOBUGE-Games/godot-httpd/blob/master/http...
I feel strongly that OP should check out Google's Flutter project. It has many of the benefits he sees in Godot, with a more general focus rather than the singular focus on games.
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.
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.
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.
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.
The author has a point that game engines may be suitable for some applications. In arquitecture I've used Twinmotion, based on unreal and Lumion, not sure about the engine on that one, probably unreal too. It may be obvious in this field, where game like visualization is directly usable, but I can see other areas where It may work. Anything regarding 3d objects will find in a game engine state of the art, real time, visualization tools.
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.
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.
I personally got so used to the look of Gnome3 + GTK that I want all my applications to either use GTK or at least try to attempt to use a similar theme. The most important factor, as petty as it may sound, is the size of the control elements. If there is a generic dark theme it's usually okay but if the standard controls look off it usually doesn't appeal to me.
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 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.
...god, my eyes, they hurt, that design, they're bleeding now ...you almost made me change my mind of whether this would be a good idea :)
(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.)
[...] 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.
This is an area I've been actively exploring and think has real potential.
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.
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. ;) )
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.
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...
I am a big fan of the MOAI toolkit, which is similar to Godot in some ways - inasmuch as its a game engine toolkit with a Lua front-end - and with which I have created a number of 'non-game' GUI apps.
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 ..
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).