Godot doesn't display native widgets, so it has no support for accessibility, for example to screen readers and blind users. Some people think blind people bring too little profit to care, but this is wrong for one single reason. There are some laws mandating accessibility, and more laws are being passed, for example in the EU. Even if you don't really focus on accessibility at this point, you always want to keep your options open, in case the law forces you to. If you choose Electron, WX or even QT, some minor tweaks will usually be enough to make it right. If you choose Godot, you will need to rewrite the whole thing from the ground, which might kill your business, or risk fines and litigation, which might also kill your business. This is even true about internal tools, as there are laws mandating accessibility of the tools used at the workplace, and you never know when a blind person gets hired for a job they theoretically should be able to perform.
This might sound very harsh, but it's important to get this right early, as one bad decision here is usually irreversible. Of course, this applies not just to Godot, but to any GUI tool which doesn't implement accessibility properly (including those that theoretically work on the web, but use canvas instead of DOM rendering).
As for the rest, I'm frustrated because you're partially right but also kinda defeatist and that makes me sad.
I went checking and found a long history of discussion about accessibility in Godot's GUI toolkit (because the Godot editor is built in the Godot engine). It's an active topic, spanning multiple tickets over years. Their stance has evolved dramatically over time, but they appear to be putting real effort into improving the situation. Here's what I think is the current tracking ticket: https://github.com/godotengine/godot-proposals/issues/983
Accessibility isn't a feature of Godot...yet, but it's obviously something that's important for mainstream adoption of serious software, especially non-audio-visual experience software. And it's obvious that people in the community care and are both asking for it and working on it.
If anything we need to keep doing this and revisiting it over and again and keep improving it, testing it, giving feedback, contributing. Because for as many applications that wouldn't benefit from this approach, there are as many that would.
Maybe what the community needs is a real-world application which would benefit from these accessibility features to help drive adoption and development.
- Almost no one does accessibility properly in web apps. Even native apps get it wrong more often than not.
- Using Electron does not give you accessibility in any way.
- What laws? I use everyday general purpose commercial applications, both webapps and native apps, with glaring accessibility flaws and I do not see anybody caring to sue.
- I don't know of any business doing general purpose commercial applications that has faced any issues with that.
Screen readers can still (badly) work on web sites that haven't been made with accessibility in mind. And if you find you need to add proper accessibility to a web or native app, you can. With something like godot, you might have to rewrite the entire GUI to get accessibility working properly.
> - Using Electron does not give you accessibility in any way.
Yes it does. Electron gives you basic out-of-the-box crossplatform support for accessibility, just like chrome. And you can tweak the screen reader output the same way you would a website. See: https://www.electronjs.org/docs/tutorial/accessibility
> - What laws?
EU: According to the first google result, by September 23 2020 all websites and mobile apps must be accessible to everyone, have a public accessibility policy, provide a feedback mechanism for users to report inaccessible content and provide a link to the enforcement procedure:
California (govt): As of July 2019 all websites made by the state of california must be accessible: https://www.levelaccess.com/california-passes-new-digital-ac... . There's similar results at the US federal level.
> - I don't know of any business doing general purpose commercial applications that has faced any issues with that.
You don't know anyone who's faced issues yet. Momentum behind these laws is growing in most countries, bolstered by the 2008 UN Convention on the Rights of Persons with Disabilities - which requires countries to "Provide information in accessible formats and technologies appropriate to different kinds of disabilities in a timely manner and without additional cost". In the US and Canada the law currently only requires government websites to be accessible, but its not a safe bet to assume things will stay like that.
We are talking about web apps, not web sites.
> the screen reader output
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".
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.
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.
(I am not a lawyer. This is not legal advice.)
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.
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>
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.
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.
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
No biggie if one of them is opengl based and might be expensive to add accessibility to it...
Oh, and stop spreading fud in general, you might use an accessibility-friendly toolkit and still end up with a practically unusable for visually impaired ppl UI, just as you can make a custom coded UI screen reader friendly...
Just be honest, accept that UI dev will eat up at least 50% of your resources if you wanna do it right, don't cheap out on it, embrace re-writes and maintaining multiple versions of similar functionality things, and stop being afraid of new tech...
I haven't learn much about Godot yet (but I will after this post), but Flutter solved accessibility in declarative widget UIs in a way that might be a good example for others.
Isn't this also the case with Google's Flutter on iOS by default?
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 . It is capable of creating pretty fast UIs with little code. Gitk  Git UI is written in Tcl + Tk.
The solution is, as far as it is possible, to add accessibility to these frameworks.
Something somewhat common in videogames is to add one or several colour blindness colour palettes to the games.
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):
If you're making something for free or for fun, then let curiosity guide you. Bureaucrats like yourself can comment all you want. I'll be making applications.
Imagine the headline "company goes bust due to regulatory violations after hiring blind person". That would basically be sending the message "never hire a blind person", because no company can ever be sure to be in compliance.
> Do you know of cases where not implementing accessibility really did become a big financial hazard?
"Jason Camacho, a blind resident of Brooklyn, N.Y., is suing 50 colleges over the accessibility of their websites.
The 50 lawsuits, filed in November, say the colleges are in violation of the Americans With Disabilities Act, as their websites are not accessible to people with disabilities. Camacho uses a screen reader and said he experienced barriers when trying to access the colleges' websites."
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.
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.
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.
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."'
> ...or maybe the law doesn't actually say what you think it says.
It does. Read it.
In that case the main complaint seemed to be that they had more of an obligation because they were receiving federal funding.
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?
Often times, people make claims based on what they think should be happening. That doesn't mean it is happening.
Most relevant comment , from gunibert is here:
The problem in a framework like GoDot is, that it is meant for Games. A game renders screens in 30/60 fps. A Desktop application like a Gtk application does exactly nothing if you dont interact with the application. If you click a button only the button gets re-rendered. This is more efficient then using something like a game engine which has no concept about damaged regions and so on.
Also, people like to have something like "native" look and feel. This would be possible with Java-SWT as it abstracts away the toolkit. This is possible but in the case of SWT it is just broken (think about margins, text, scroll behaviour).
The other option is to use electron as it is just plain simple, works even in the web (you can basically make a webapp and repackage that as an electron app)
Or you package a toolkit with your application and avoid native libraries. This happens in the world of Qt for example. Gtk is cross-platform too but not statically linkable.
> If true, the engine optimizes for low processor usage by only refreshing the screen if needed
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.
Have both use the same specialised libraries.
If anyone wants inspiration, Winamp is the gold standard for media players with excellent GUI bling and skinning.
If your test involves two different GUI systems running the same 'specialised libraries', you are running the specialised libraries, not the GUI systems.
A media player involves heavy crunching and streaming and memory I/o, and access to the GPU if possible - these things that game engines excel at.
Most GOOD game engines are in fact an entire operating system, abstracting away the host operating system, and attempting to depend on it very minimally - giving coders an environment which does not have to conform to "business user" semantics.
This doesn't mean game engines don't burn through energy. But on mobile, at least, most of the good game engines do allow you to fine-tune your frame-rate such that, indeed, you don't need to update anything - video or stream - at all unless some event happens..
It would be an interesting test - but beware that there are multiple approaches, and even plain ol' definitions, for how a 'game engine' differentiates from an 'operating system'.
The two systems of thought have been intertwined, commercially, for decades...
You'd be amazed how much overhead a change can introduce even if the real work is done by a dedicated library. This is the whole point I was making.
eg A library like imgui that repeatedly redraws itself isn't actually that wasteful power wise if you tune it and make it fit for purpose. We've done exactly that for mobile. The simplicity of its approach enables all sorts of optimisations. Imgui is a straightforward animal that can be optimised in all sorts of directions, that is actually one of its drawcards. Reorientating it to output text has already been done - thats how flexible it can get.
> 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  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.
At first we were worried about the screen always updating and consuming so much energy, but reading the code it became obvious that it was extremely simple to fork the imgui with a very small update screen change, so it only updates when we do something.
Imguis and game engines are much simpler to code than conventional GUI because you don't need to handle so much state.
A game engine can avoid redraws trivially if no relevant input/event has occurred.
Further, AFAIK some graphic APIs do support dirty rectangles too, but to be honest, for desktop/laptop GUI apps I doubt it matters compared to anything else going on in the system.
And GUIs runs perfectly fine on integrated GPUs, further reducing the cost.
Blender does this perfectly fine, for instance.
Recently Godot gained the ability to selectively remove features from the editor:
The documentation describes it like this:
When disabled, the features won't appear in the editor, which makes the editor less cluttered.
This is useful in education settings to reduce confusion or when working in a team.
For example, artists and level designers could use a feature profile that disables the script editor to avoid accidentally making changes to files[...]
There's lots of superfluous stuff if you're making tools instead of games, but it doesn't really get in the way.
Edit: It was in the editor, just realized I didn't explicitly mention that.
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.
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.
Having said that, the other issues concerning Qt may be valid, but for a code-only set of widgets, they work for me. For these kinds of comparisons to have value, you have to list the pros and cons of all things, not just the pros of what you like and cons of what you don't.
I wonder if, in another 20 years, we may see people speaking of "just 20GB"...
Do you want to flash image to USB drive? There is Electron app (balenaEtcher) for that.
Do you want to control your mouse/keyboard? There is Electron app for that (Logitech GHub), which also includes many Qt libraries.
Do you want a terminal emulator? There is an Electron based app for that.
Qt is the best I've seen, but it has the normal c++ FUD plus the infamous licensing FUD.
And honestly, I'll have to admit that how react models GUIs is a really attractive.
Not sure what you mean exactly; C++ is complex, but why the fear and doubt?
Also - Qt is based on veeery old C++ - a 22-year-old standard. The language has changed significantly since then, while Qt's fundamental design (in terms of programming) - not really, or not much. So, Qt is not "normal C++" these days.
It feels like a beautiful old walking path that detours around a wall that's long since been torn out. It's still fine... but... it's not how you'd design it if you were to start from scratch.
I agree with you, although one thing worth pointing out is that with Qt (or similar) application frameworks on any decent operating system, you only have to download those libraries once, which means the individual overhead of an application remains extremely low.
For example, the LXQT default terminal, qterminal, comes in a package that is only 200 KB on Arch Linux, for the entire thing. (To be fair it directly depends on a library that provides a terminal widget, which is another 200 KB.)
that really depends on the application though. say you want to make a media player, you likely want to embed FFMPEG and that alone will be heavier than windows 3.11 because there are so many codecs today. Likewise for an image editor, you're gonna have to pack a whole lot of image format encoders / decoders.
Also note that Qt can basically run as-is on top of a linux kernel, directly rendering to the framebuffer and doing everything itself so it'll mechanically be a bit heavier than something like wx which uses the OS widget APIs instead.... but won't be able to run in place where there are no "OS widget APIs" (that is, 99.9% of embedded platforms), while Qt has that as a main market.
As someone who has written some video and image decoders --- 20MB is still very large. Minimal-complexity H.261 through H.263 decoders are in the "dozens of KB" range, and optimisations in Asm are unlikely to make them that much bigger. ffdshow, an all-in-one codec that can decode and encode a few dozen formats, is 2MB and that not only includes code that does the real work, but also the COM-based bloat of the DirectShow API it uses. A GIF decoder is a few KB. JPEG is also roughly the same, maybe slightly bigger, and PNG is around that size too.
Also note that Qt can basically run as-is on top of a linux kernel, directly rendering to the framebuffer and doing everything itself
So does Windows (on top of DOS.)
But other than Qt or wx, I really can't get behind these new GUI platforms which keep cropping up. They all have too many issues and don't end up presenting a native experience (or often even a good one).
In any case I think I’ve gotten a stripped static executable down to 5 or 6 MB.
I have an (admittedly simple) application using QtWidgets that is under 10 MiB statically linked.
Particularly in Windows.
Are there any visual scripting languages that aren't terrible? The system in unreal works but every time I use it I find myself wanting a text editor (I have spent years learning to program well, be that C++ or shaders, just let me do that!).
It is still just connecting blocks though as pierrec says below so it can take a lot of connections to get something done
What were the motivations behind creating GDScript?
In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed.
The main reasons for creating a custom scripting language for Godot were:
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.
- Licensing perhaps?
- Lack of support for that use case?
- Painful interop? No idea.
I personally dislike the python ecosystem and am not missing anything.
a lot of visual programming environments, like LabVIEW (1986) or Max/MSP (1985), predate Python and JS by at least a good few years :p
It's simple and straight forward.
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.
And really, you can drag and drop elements into the live previews and it writes the code for you, including automatically wrapping existing components in horizontal/vertical stacks as needed to arrange the layout. So SwiftUI still has some of the visual UI editor benefits, just broken into smaller pieces with a much more useful text representation.
With Godot it is possible to design the UI in code--the editor itself uses that approach, e.g.: https://github.com/godotengine/godot/blob/27d12092821df77a61...
> you can practically throw your version control system out of the window for UI files.
While not "perfect" with VCS (there's a bit of automatic-generated file content churn at times), Godot stores its files (UI & other) as plain text (not even XML) with a very shallow hierarchy, e.g. here's a "scene" file from a project of mine: https://gitlab.com/RancidBacon/godot-foreigner-export-demo/-...
While I wouldn't really recommend two people working on one scene simultaneously, if it were necessary for some reason, Godot does provide the ability to separate a scene into "subscenes" which could be worked on independently.
While it is possible to hard-code widget positions, with the Container-based layout
method the values in that file actually get completely ignored & recalculated on the fly.
The fact that the values end up in the file at all is something I consider a bug/implementation flaw.
In Godot a UI Control has an "anchor" setting for each of left/right/top/down margin which affects where the margin value is measured from in relation to the bounding box. So (hand-waving a bit here), e.g. for, say a margin value of 10px, for the left margin an anchor value of 0 means "inset 10px from the left margin of bounding box" and with anchor value of 0.5 means "move left 10px from center of bounding box" and with anchor value of 1 it calculates relative to the right-most margin. (But for right margin an anchor value of 0 means "calculate relative to right margin of bounding box, and, somewhat confusingly, I think requires the value to be negative to "inset".)
What this means in practice, is that if you use an anchor value of 0 for all margins, even when you resize an element you don't need to adjust any of the margin values.
Unfortunately Godot (and Containers--even though they re-calculate all the margins themselves) default to an anchor value of 0 for left margin and 1 for right margin which means the right margin is a non-zero value & gets re-calculated & updated/save every time you adjust the layout.
In general the layout system works pretty well & is flexible but it does have some slightly confusing aspects (and in the past at least some implementation bugs) and is somewhat difficult to explain in text. :) (And it would definitely benefit from even more detailed documentation--than what it currently has--in terms of the "sizing flags" that determine how multiple Controls occupy/share the space available.)
So, in short: Once set up correctly, Godot UI layouts generally adapt well to different text-widths, font sizes and window dimensions.
A search about accessibility immediately popped up github issues acknowledging the difficulty making screen readers work: https://github.com/godotengine/godot/issues/29736
There are some applications that mimic all those friendly native behaviors, but it tends to take a lot of work, and sometimes pushing updates when the OS behaviors change.
I'm using cljfx these days and really enjoying it. For desktop apps I think it is a great choice .
The approach described using Godot could work well depending on the type of app, I think. For instance, this commercial app  is built using Kivy , which basically draws the controls using sdl+openGL, so a similar kind of setup as the Godot one described in the OP.
Even the Godot editor itself is not non-English friendly. It's got a horrible experience for any language that uses an IME. If you try to insert an emoji on Mac the IME won't even appear.
That said, complete and robust i18n support may take a while, given the small size of the core development team (< 30 regular contributors) and the fact that text display is probably not the highest priority for a game development tool and engine.
I am confident if Godot sees usage as a GUI/app framework, they will take care of that.
Text input and manipulation is so incredibly ugly and hard, that basically nobody cares it enough to to it really well.
Unicode to start is complicated. Then you have things like bidirectional text.
Line breaking is complicated.
There are no accepted practices for a lot of use cases.
Hyperlinks. Embedded content like images.
Copying/inserting html and other formats.
Rendering 100 000 lines of styled content without screwing up user input.
Line-heights. Tabs. Font definitions that are ambiguous an inconsistent (a lot of font tables today still don't provide enough space for accents on capital letters, think Swedish - so you have broken looking text or have to 'fake it'). Screwed up Kerning tables.
No established standard for real pixelation and rendering - zoom in and you'll see font's can be rendered a variety of ways.
Emojis, fat finger cursor navigation on mobile devcies, input managers.
It's hard to describe how messy it gets because none of it is academic, it's not some scary-hard algorithm - it's just an incredibly ugly pile of cross-cutting code with a zillion little bits and pieces of corner cases.
And a big one for gaming engines: they don't render text 'natively'. You basically have to create textures. Every big of text, it's own texture. How big is the texture for 100 000 lines of code? Big.
This is actually one are where Qt falls flat. In the 'new and improved' Qt, they do everything in the GPU, if you try to load 100 000 lines of something the app will use up 1G of memory and puke. So then you have to magically code your way around it.
All for what? Why would you want to render text in a gaming engine in the first place ...
Then you discover that 'apps' and 'games' are really different things, and they use different tech for good reason. It only gets ugly when they really have cross paths.
> Why would you want to render text in a gaming engine in the first place ...
Just about every game needs text, including Unicode text. Every proper engine handles it.
The platform does not offer anything.
"Just about every game needs text, including Unicode text. Every proper engine handles it"
No, what they do is paste a few characters on screen, handling a more common subset of Unicode. They don't come close to handling most of the things I described above.
Not even Qt handles text well - Qt allows you to do some fun 3D things with text, but not you can't open 100K lines of formatted code like VSCode.
Webkit is just as bad - MS had to invent 'Monaco' a huge layer on top to be able to manage text properly and it's kind of a hack.
Simply put nobody does it well out of the box.
All major platforms offer advanced text rendering support.
How do you think Windows or macOS render their UI?
> what they do is paste a few characters on screen, handling a more common subset of Unicode.
Some games do that, in particular old ones or indies. Most games do actual text rendering properly.
> you can't open 100K lines of formatted code
You definitely can, but not naively. VS Code doesn't render all the text at once either and neither does any serious text editor.
No, they don't realy.
I think you're missing a few pieces in your understanding of what the platform does in these contexts
The platform does not support text rendering for Qt and such platforms. They are rendered 'from scratch'.
Some platforms offer some built in components, but even they are quite limited.
No platform offers the ability, out of the box, to do for example, a 'coded editor' with properly highlighted syntax. Not even close.
"Most games do actual text rendering properly."
They are 'rendering text properly' for the extremely limited subset of text that they put on the screen.
Have you ever used even a basic 'text editor' in a game? No? Because they don't even do that.
" you can't open 100K lines of formatted code"
"You definitely can, but not naively."
'Natively' means nothing on the context of 'browser'. If you mean to say 'the browser doesn't do it out of the box' - then ok, yes, we agree. And why not, because it's extremely hard?
There are 0 comprehensive text APIs that are built upon gaming or even 3D engines today. Most of the barely handle basic text formatting. They put a few lines of text on the screen in a limited number of languages, and that's it.
There are very, very few platforms that offer comprehensive text rendering, including Qt, GTK, and native platform components - they're basic.
Providing comprehensive text API is not only something that has to be layered on top of those things - they also have to 'hack' those platforms to work around inherent bugs and limitations.
so godot will only see usage as a GUI framework for the use cases that won't see emoji or non-english IME.
Mentioning Electron to solve Unicode is like thinking about a bulldozer when you need to unclog your toilet.
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.
But I'm not sure that I can echo the sentiment here exactly. I took the time to read the entire article.
This is what it boils down to for me:
IF you are going to build a native desktop app with a drag-and-drop WYSIWYG editor, I think it's arguably a solid choice over QT or whatever else you might do it with.
But the latter part of the article focuses on the argument against using web technologies:
> My discussion of Web technologies needs some disclaimers. I have little experience with web technologies, and I am not very fond of web technology. I am an old school GUI toolkit guy, who did his first GUI stuff using the Intuition toolkit on an old Amiga 1000.
There are a couple of really big problems I see however:
2. It was made for web pages not applications. When trying to make a GUI for an application I found that I so often hit on the limitations imposed by the assumption that we are in some scrollable webpage.
3. It is not made for reusable components, like real GUI toolkits.
It's all pixels on a screen. Any design asset you can whip up, with whatever animations and effects, can be rendered identically on a web, or native mobile/desktop app.
And modern web applications are entirely made of reusable components and the principles behind them.
I like to think I don't say without some perspective -- some of the first applications I ever wrote were VB.NET apps in Visual Studio 2007 using Windows Forms.
But today the idea of saying "An app made with web technologies cannot look or function quite like a native desktop app, and it lacks reusable components" is a bit wild.
Can you imagine trying to build <insert omnipresent application>'s desktop client with a WYSIWYG.
Finally, will conclude the rant here -- author talks about how Godot's 30MB compressed/70MB uncompressed size is fantastic, but with Tauri you can build native desktop apps using HTML/JS in 1-2MB.
The issue is that no one bothers to do all the OS integrations you get for free when you make a native app.
Also, every web app I've used that pretends to be a desktop app has issues that make it feel off. Using Discord as an example; I have to focus the title bar before I can use the minimize/maximize window buttons - unlike every native macOS app. I run into this almost every day.
I'm not denying that web applications are useful, but if you want something really high quality, native is the only solution in my opinion.
I was hopeful that web applications could offer a really great way to make cross-platform applications. After trying some frameworks out, and following the web standards more closely, I'm pretty pessimistic. The complexity of web browsers is out of control and I don't think they'll ever be comparable to native apps.
It's just bringing up an option that most developers wouldn't even consider. This article is asking a question, and just focuses on providing enough detail to frame that question.
I don't think the negativity is justified.
"I would bet that the easiest thing would be FLTK. You can use system colors and make an openGL window while having everything else you would expect in a UI library. Executables with no dependencies start at a few hundred KB and it is very fast. There is even a single big pdf for documentation and dozens of examples that show off every widget. FLTK is very underrated these days because no one is out there marketing it.
GLFW and IMGUI are great libraries, but once you start wanting a program with various modal and non-modal windows, menus, widget layout, a native look, file dialogs, fonts, drag and drop, copy and paste, unicode, spreadsheet tables, physical printing, custom widgets, functions to hide OS specific system stuff (like stat, directory listing etc.) you might wish you had started with something made for what you are trying to do. "
If I'm not mistaken, the most lightweight cross-platform UI toolkit that draws its own widgets (unlike wx or SWT) and implements accessibility is sciter . It's a good thing the antivirus vendors (who seem to be sciter's biggest customers) want to sell to governments.
Yeah, this is currently a valid criticism--it's an aspect I'm hoping will see more development attention in the future.
I did recently discover this project which is working on improving the situation: https://github.com/lightsoutgames/godot-accessibility/
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.
One of the few weaknesses of IMGUI is theming though. Don't expect to create one of those fancy Material-themed apps with animations, it's primarily intended for creating dry, technical tools of the likes of game engines and modelling/animation tools. It's more in the mindset of creating 'tools' rather than 'apps', and it really depends on your usecase.
As noted elsewhere in the thread, the Godot editor (supporting UI, 2D & 3D) itself is built with Godot, so it's definitely not just "very basic" UIs.
FWIW, from your list, Godot doesn't currently support these AFAIK:
* physical printing, spreadsheet tables, a native look
And, does support:
* fonts, drag and drop, copy and paste, custom widgets, widget layout, functions to hide OS specific system stuff [for Windows, Mac, Linux, Android, iOS + others].
And, does support these with some privosos:
* various modal and non-modal windows (v3.2 is all in one window but shows modal/non-modal sub-windows within it, v4.0 in dev supports multiple system windows)
* menus (but not native system menus)
* unicode (Freetype is used for rendering but higher level multi-language support is currently less advanced)
This point was mentioned in the article. Seems like you made up your mind without reading too closely.
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.
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.
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?)
The get up and go speed of the super old windows forms approach was fantastic.
Now I'm supposed to use - XAML? UWP? WPF? Do these have great windows form designer still?
I'm talking speed between download and go with an GUI, a button, a text box (maybe data bound) etc.
This will age me, but for all the decades of "improvements" this tooling has, every time I've tried to do the little widget apps thing I used to be able to do trivially I end up wondering in the woods.
Paired with F# the proposed Elm-like model-view-update style would be the dream.
In addition, we are enabling developers to write fluent C# UI and implement the increasingly popular Model-View-Update (MVU) pattern.
Ah, some SwiftUI envy.
It isn't as powerful as WPF/UWP, and it has some caveats depending on the .NET Framework version, but it does the job.
However if you want to unit test your UI then it makes more sense.
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 :-)
Here's a good illustration of the program in usage: https://www.youtube.com/watch?v=JCY4dfVNq9Q
(I've been thinking of building an app to do photo triage, and Godot can certainly load up a bucketload of image assets and render them...)
It's like driving a car, you can have thousand of different models and yet you get inside one you can drive it right away. You don't have that kind of usability if everyone was doing custom GUI running with a game engine.
Same reason why there is a learning curve with UI in games, every games are different so every UI are also different, it takes time to naviguate properly in a new game.
Consistance is key.
I found the hassle of setting up Qt painful, but it didn't scare me away. The final nail the coffin was their prioritization of Qt Creator over SDK integration. juggling two IDEs just didn't seem right with an existing codebase.
Curious what you mean by that? What did you need Qt Creator for that you couldn't do otherwise?
Where there's a will, there's a way :).
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 ..
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.
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.
Erik Engheim: Qt5 is 5GB
Actual fact (on arch linux): qt5-base = 64.07 MiB, qt5-declarative = 24.72 MiB, qt5-quickcontrols2 = 8.56 MiB
> Try having somebody look at a Qt design you made. “Oops sorry you need a 5 GB download to do that. Oh and btw you need to register an account on a website, login and search really hard to find the free version.”
...blatant lie, etc. I won't bother, this guy is nuts. Thanks god for Qt, it has its quirks but on the desktop it's the best we can do to dev cross-platform
Erik Engheim: Consider Qt Creator IDE which is quite minimalist, without Qt which it requires to run, requires over 200 MB
Actual fact: 108.03 MiB
In this case, you need the SDK to develop a UI with Qt, so I think the author's comparison is fair.
> Consider Qt Creator IDE which is quite minimalist, without Qt which it requires to run, requires over 200 MB Actual fact: 108.03 MiB
Probably depends on the platform, I wouldn't be surprised if it was > 200 MB on OS X. But either way, 100 vs 200, same order of magnitude
keep in mind that Qt Creator comes with a full clang for its C++ code model which is already 40-50 megabytes at least ; no decent C++ IDE can skip that.
Regarding the Qt SDK size, what can take gigabytes is installing it for all android & iOS ... ABIs / versions.
for a fast SDK installation experience, I recommend aqtinstall:
$ pip install aqtinstall
$ time python -m aqt install 5.15.0 linux desktop -O ~/Qt/
10,43s user 2,14s system 153% cpu 8,213 total
$ du -csh ~/Qt/5.15.0
"From February onward, everyone, including open-source Qt users, will require valid Qt accounts to download Qt binary packages."
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 have written a few 3D applications in both Unity and Unreal, and I can tell you that the cross-platform build process with those is impressive. I can package an app for three different platforms and get pixel perfect equivalent output and the exact same behavior on all three platforms without any trickery at all.
Qt probably also does this, and that's great! Qt existing doesn't take away from the utility of game engines, is all, nor the reverse.
In my personal experience and opinions QML is the best domain specific language for GUI development I’ve ever used and was a dream to work with in comparison to others. Nowadays, my UIs are mainly react based web applications and I often wish I could use QML instead and dream of a warm future where I can use something like QML on web without any major tradeoffs.
So I strongly disagree with him on this point.
https://screen-play.app/ (Live wallpaper)
Why are they shooting themselves in the foot there?
sudo apt install qt5-default qtcreator
I think you could add `--install-suggests` to that command if you wanted to get everything and the kitchen sink.
I think the future of interactive immersive VR work environments is looking very strong so using it for GUI apps seems like a good first step.
The author of this article said that he is not a web developer and he has a pro-application perspective. I think he misses the huge opportunity for web properties to also render into Virtual Reality.
Out of curiosity I looked at some of the examples in the Oculus Quest SDK. Basically Android+3D, effective but there is lots of room for improvement.
I'd also take issue with the notion that 2D UI frameworks based on game engines are more performant than their alternatives, because game engines are optimized for 3D graphics and often struggle with performance once your UI state becomes reasonable large.
Very well (it's a game engine)
> localization, and accessibility?
Poorly and not at all. Godot has a student adding PO files:
The GSOC project you linked to is about enhancing the existing .po based feature: "In Godot, we [already] have two ways of importing translation - by using CSV or PO files."
Here's a blog post about someone's experience doing a translation for a Godot game: https://sites.miis.edu/vprolow/2019/12/15/godot-game-localiz...
And here's an official tutorial: https://docs.godotengine.org/en/stable/tutorials/i18n/intern...
It supports this through use of its "Container" UI Controls--which have a bit of a steep learning curve but works pretty well.
> I'd also take issue with the notion that 2D UI frameworks based on game engines are more performant than their alternatives, because game engines are optimized for 3D graphics
One aspect of Godot that is a bit different in this regard is that pre-3.0 the focus was very much more on the 2D side of things, so the 2D support isn't just "a flat 2D plane in a 3D world" unlike some other engines.
Which begs the question how do other areas of development get such easy conditions?
Fifteen years later and the competition is huge, and the demand in overtime and the stress followed.
As you start to make even more “programming is fun” classes, what they don’t see is the other end, and then queue in the FAANG salaries as if that is indicative of what programmers salaries are.
If I get kids, I’ll tell them to do some soul digging to find out what they find fun that the majority instead finds boring or something that has a clear path through a moat.
Java went with webapps thinking it'd be easier to manage distribution of the application if a browser did it for you. Or at least that's how the trends played out.
It kind of works, but the real missed opportunity was all the client side processing and storage that desktop apps bring to the table.
(Hint: I'm interested in mostly using this for creating a graphically rich but minimalistic distraction-free ADHD-friendly experience ...that could also be usable in VR for even more distraction free coding - I mean since most pro devs touch type anyway, using a keyboard in VR would just work for us, without any extra stuff.)
From a quick search there's this: https://docs.godotengine.org/en/stable/classes/class_videopl...
(But that may not be a live stream, necessarily, I guess.)
Also there's this that may be relevant: https://docs.godotengine.org/en/stable/classes/class_spatial...
The latter is documented as:
[...] enables the "shadow to opacity" render mode where lighting modifies the alpha so shadowed areas are opaque and non-shadowed areas are transparent. Useful for overlaying shadows onto a camera feed in AR.
For context, my interest is in:
* Cross-platform support.
* Ease of distribution.
* Ease of construction.
* Platform stability.
* "Licensing"/business issues.
In the past I've used Qt w/ C++, Qt w/ Python, web w/Python backend, Python w/embedded web server and dabbled/looked into things like wx etc. (Oh, and, MS Access with VBA. :D )
# Platform Native UI
If you want/need Platform Native UI, then Godot is not going to work for you, period. But neither are most of the other cross-platform options because if they're only 95% they're not native. My impression is that if you want platform native and cross-platform then per-platform clients w/shared backend implementation is pretty much required.
But I also think that platform native (as much as I might like it) is not necessarily mandatory for successful product, see, e.g. Slack.
I think the key around this is once you've chosen to not be platform native don't pretend to be platform native. Lean into making the UI tailored for your application.
And with a game engine there's a whole lot of space to lean into in this regard--particularly in relation to visualisation.
If you're happy with 95% and don't care about any other aspect then likely Qt will be a contender for you.
# Ease of Distribution
Trying to distribute a Qt + Python app as a single binary (within the last 2 years) was how I ended up ditching Qt & using an embedded web server instead. Despite all the effort & projects trying to make this work, IMO it still doesn't.
With the small initial Godot download and, a (admittedly half gig) "templates" download containing the cross-platform app "shells", it's possible to export to Windows, Mac, Linux, iOS, Android & HTML5. Depending on the platform the output might be a single binary, a disk image, zip file or binary + support files but where required traditional packaging tools can also be used.
This is really powerful for me (as both a developer & user) when the platforms I use (primarily Mac/Linux) are not in the majority & frequently get left out of releases.
# Ease of Construction
In relation to games, the highest praise I have for Godot is:
* Since I downloaded Godot I've actually made and released games.
I've found the integrated nature of the IDE really supports iterative development.
Game-making is often a very collaborative effort and because Godot has been developed (in part) to enable non-developers to not have developers be the bottle-neck it has visual-based tools & a node/component based architecture which also can make it a powerful tool for other technical but "non-developer" people.
# Why not use web technologies?
If your project makes sense as a web site then, make it a web site.
If you want to have a standalone app, you have experience with web technologies and memory/performance aspects aren't an issue, then, sure build it on Electron.
But if you can do those things, you can almost certainly use GDScript and gain the benefit of an integrated IDE and comparatively tiny downloads. (And still export it to HTML5/WebAssembly--admittedly currently probably with a slower initial page load time--but it's still an option.)
Additionally, currently Godot runs on older OS (e.g. even back as far as Mac OS 10.9) than Electron does which keeps getting dragged along to newer versions by Chrome's requirements which seem to place little emphasis on supporting older machines/OS.
# Why not Qt?
Ah, Qt, I really want to like you.
If Qt works for you, then use it.
But my experience with Qt has been one of a business that continually seems to struggle with how to survive; tries to stretch their license compliance in terms of LGPL & contract with KDE to breaking pointing (because, really, they wish they didn't have that constraint at all); and, a continual churn of the underlying technology that results in apps that only support newer & newer OS/Qt versions even if they don't require anything more than, say, Qt 5.2.
If you're a big corporate and/or if a 95% cross-platform solution is enough, then I think there's still situations where Qt probably makes sense but in terms of my niche desktop application development needs it's just too much hassle.
# Is Godot ready for applications now?
Somewhat. Obviously if your application is a game & the required feature set matches Godot's, then yes. :)
Based on my own experience using Godot to develop non-game applications tends to run into some areas of its feature-set which have seen less attention & so have bugs, lack features and/or lack documentation. (e.g. complex Tree controls, more sophisticated font rendering (e.g. kerning), very complex layouts.)
Overall, I think Godot is at a stage where a bunch of people (including OP) have realised it has potential around non-game application development but also has some rough edges in that regard that still needs to be improved.
Given the size & focus of the development team up to this point that's not surprising but I'm excited to see where it may go in future.
# A Note on Accessibility
As mentioned elsewhere in the comments, Godot also unfortunately doesn't currently have a great accessibility story.
There is at least at least one project that I know of that is working on improving that: https://github.com/lightsoutgames/godot-accessibility/
In addition, Godot's node-based UI system in particular I think lends itself to retro-fitting better accessibility support more than a different architecture might.
But if you need your app to be accessible today then Godot probably won't meet your needs.
# Bonus: Are InfoSec tools a potential niche for Godot-based apps?
I think that's a strong...maybe. :)
To explore the potential of Godot for non-game apps I've been working on developing a Godot-based hex viewer/editor with a focus on binary/format reverse-engineering & visualisation motivated in part by a talk where someone complained that hex editors hadn't done much new for years.
Early in development I realised that InfoSec has a combination of aspects that might make it particularly well suited for Godot-based apps:
* Many people who are technically skilled but consider themselves "non-developers".
* Has problems to solve that benefit from new forms of visualisation (often with large amounts of data) not met by standard UI.
* Has an affinity for flashy visuals. :)
* Need tools that don't only run in the cloud.
(In InfoSec and want to make this happen? I'm available for hire. ;) )
Also I saw this Kanban board posted on Reddit earlier:
Heavypaint, mentioned elsewhere here:
- 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.
Cloud infra and micro services can still be what they are, all the usual safety features.
Web/mobile development landscape just feels bloated and insane compared to building once in Unreal or Godot and outputting to multiple platforms like the game engines are doing.
In a day to day engineering perspective it’s all a mess of abstraction and indirection anyway?
If we’re going to optimize ONE stack, I’d prefer the one with all the optimized rendering and input mapping, rather than hacking that all into a bloated document parser like we’re hacking into a browser?
IMO that is textbook functional fixedness.
> If we’re going to optimize ONE stack
Why would we though? There are different classes of applications and there are multiple platforms with different conventions. Different use cases require different tools. Every time something "to rule them all" was tried, multiple niche tools grown around.
Some engines do have accessibility support. Most games don't do accessibility because it costs money. Same as web apps, by the way. It is not a technical limitation.
> What about IME?
What about it? It works just fine in any proper engine. There are a lot of non-Latin-charset speakers in the world...