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.
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."
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.
> 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.
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"...
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.
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!)
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?
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.
Readit News
Godot doesn't display native widgets, so it has no support for accessibility, for example to screen readers and blind users. Some people think blind people bring too little profit to care, but this is wrong for one single reason. There are some laws mandating accessibility, and more laws are being passed, for example in the EU. Even if you don't really focus on accessibility at this point, you always want to keep your options open, in case the law forces you to. If you choose Electron, WX or even QT, some minor tweaks will usually be enough to make it right. If you choose Godot, you will need to rewrite the whole thing from the ground, which might kill your business, or risk fines and litigation, which might also kill your business. This is even true about internal tools, as there are laws mandating accessibility of the tools used at the workplace, and you never know when a blind person gets hired for a job they theoretically should be able to perform.
This might sound very harsh, but it's important to get this right early, as one bad decision here is usually irreversible. Of course, this applies not just to Godot, but to any GUI tool which doesn't implement accessibility properly (including those that theoretically work on the web, but use canvas instead of DOM rendering).
As for the rest, I'm frustrated because you're partially right but also kinda defeatist and that makes me sad.
I went checking and found a long history of discussion about accessibility in Godot's GUI toolkit (because the Godot editor is built in the Godot engine). It's an active topic, spanning multiple tickets over years. Their stance has evolved dramatically over time, but they appear to be putting real effort into improving the situation. Here's what I think is the current tracking ticket: https://github.com/godotengine/godot-proposals/issues/983
Accessibility isn't a feature of Godot...yet, but it's obviously something that's important for mainstream adoption of serious software, especially non-audio-visual experience software. And it's obvious that people in the community care and are both asking for it and working on it.
If anything we need to keep doing this and revisiting it over and again and keep improving it, testing it, giving feedback, contributing. Because for as many applications that wouldn't benefit from this approach, there are as many that would.
Maybe what the community needs is a real-world application which would benefit from these accessibility features to help drive adoption and development.
- Almost no one does accessibility properly in web apps. Even native apps get it wrong more often than not.
- Using Electron does not give you accessibility in any way.
- What laws? I use everyday general purpose commercial applications, both webapps and native apps, with glaring accessibility flaws and I do not see anybody caring to sue.
- I don't know of any business doing general purpose commercial applications that has faced any issues with that.
Screen readers can still (badly) work on web sites that haven't been made with accessibility in mind. And if you find you need to add proper accessibility to a web or native app, you can. With something like godot, you might have to rewrite the entire GUI to get accessibility working properly.
> - Using Electron does not give you accessibility in any way.
Yes it does. Electron gives you basic out-of-the-box crossplatform support for accessibility, just like chrome. And you can tweak the screen reader output the same way you would a website. See: https://www.electronjs.org/docs/tutorial/accessibility
> - What laws?
EU: According to the first google result, by September 23 2020 all websites and mobile apps must be accessible to everyone, have a public accessibility policy, provide a feedback mechanism for users to report inaccessible content and provide a link to the enforcement procedure:
https://siteimprove.com/en-au/accessibility/eu-web-accessibi...
California (govt): As of July 2019 all websites made by the state of california must be accessible: https://www.levelaccess.com/california-passes-new-digital-ac... . There's similar results at the US federal level.
> - I don't know of any business doing general purpose commercial applications that has faced any issues with that.
You don't know anyone who's faced issues yet. Momentum behind these laws is growing in most countries, bolstered by the 2008 UN Convention on the Rights of Persons with Disabilities - which requires countries to "Provide information in accessible formats and technologies appropriate to different kinds of disabilities in a timely manner and without additional cost". In the US and Canada the law currently only requires government websites to be accessible, but its not a safe bet to assume things will stay like that.
Fairbanks points out that there's risk in every design. How much it should influence your architecture depends on how much it matters to your project.
He uses the example of installing a mailbox. You shouldn't approach that with the same level of planning you'd use to architect a building. They're similar projects in some sense, but risk with the former is so much lower that it isn't worth it.
In this case, for some projects, the risk of low accessibility might be significant enough that it should be high priority. For others, dependency churn or framework bloat might be higher. Or tooling capabilities. It depends on what you're building.
No biggie if one of them is opengl based and might be expensive to add accessibility to it...
Oh, and stop spreading fud in general, you might use an accessibility-friendly toolkit and still end up with a practically unusable for visually impaired ppl UI, just as you can make a custom coded UI screen reader friendly...
Just be honest, accept that UI dev will eat up at least 50% of your resources if you wanna do it right, don't cheap out on it, embrace re-writes and maintaining multiple versions of similar functionality things, and stop being afraid of new tech...
I haven't learn much about Godot yet (but I will after this post), but Flutter solved accessibility in declarative widget UIs in a way that might be a good example for others.
Isn't this also the case with Google's Flutter on iOS by default?
The solution is, as far as it is possible, to add accessibility to these frameworks.
Something somewhat common in videogames is to add one or several colour blindness colour palettes to the games.
I don't like this constant reinvention of wheels. Look at Blender, it also has its own, mice UI and many other specialized graphical, image and audio apps have. Flutter also renders its widgets.But none of them is as universal and flexible as those big, battle-tested frameworks.
They are no shortcuts, proper UI is a complicated thing.
For quick, simple UIs, you may like Tk or Python's module Tkinter [1]. It is capable of creating pretty fast UIs with little code. Gitk [2] Git UI is written in Tcl + Tk.
[1] https://www.tutorialspoint.com/python/python_gui_programming...
[2] https://www.atlassian.com/git/tutorials/gitk
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):
* https://github.com/lightsoutgames/godot-accessibility
* https://github.com/lightsoutgames/godot-tts
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
Dead Comment
If you're making something for free or for fun, then let curiosity guide you. Bureaucrats like yourself can comment all you want. I'll be making applications.
Imagine the headline "company goes bust due to regulatory violations after hiring blind person". That would basically be sending the message "never hire a blind person", because no company can ever be sure to be in compliance.
> Do you know of cases where not implementing accessibility really did become a big financial hazard?
"Jason Camacho, a blind resident of Brooklyn, N.Y., is suing 50 colleges over the accessibility of their websites.
The 50 lawsuits, filed in November, say the colleges are in violation of the Americans With Disabilities Act, as their websites are not accessible to people with disabilities. Camacho uses a screen reader and said he experienced barriers when trying to access the colleges' websites."
Source: https://www.insidehighered.com/news/2018/12/10/fifty-college...
In that case the main complaint seemed to be that they had more of an obligation because they were receiving federal funding.
1: https://www.nytimes.com/2015/02/13/education/harvard-and-mit...
2: https://www.thecrimson.com/article/2019/12/2/Harvard-settles...
Not sure what are you saying here. Are you saying that while it might become a law, companies that can't find the money to comply don't need to comply in such cases..? Or that it hasn't happened yet, so it's not bound to happen?
Most relevant comment [2], from gunibert is here:
The problem in a framework like GoDot is, that it is meant for Games. A game renders screens in 30/60 fps. A Desktop application like a Gtk application does exactly nothing if you dont interact with the application. If you click a button only the button gets re-rendered. This is more efficient then using something like a game engine which has no concept about damaged regions and so on.
Also, people like to have something like "native" look and feel. This would be possible with Java-SWT as it abstracts away the toolkit. This is possible but in the case of SWT it is just broken (think about margins, text, scroll behaviour).
The other option is to use electron as it is just plain simple, works even in the web (you can basically make a webapp and repackage that as an electron app)
Or you package a toolkit with your application and avoid native libraries. This happens in the world of Qt for example. Gtk is cross-platform too but not statically linkable.
[1] https://news.ycombinator.com/item?id=23580213 [2] https://news.ycombinator.com/item?id=23584258
> If true, the engine optimizes for low processor usage by only refreshing the screen if needed
https://docs.godotengine.org/en/stable/classes/class_os.html...
At first we were worried about the screen always updating and consuming so much energy, but reading the code it became obvious that it was extremely simple to fork the imgui with a very small update screen change, so it only updates when we do something.
Imguis and game engines are much simpler to code than conventional GUI because you don't need to handle so much state.
https://www.lazarus-ide.org/
A game engine can avoid redraws trivially if no relevant input/event has occurred.
Further, AFAIK some graphic APIs do support dirty rectangles too, but to be honest, for desktop/laptop GUI apps I doubt it matters compared to anything else going on in the system.
And GUIs runs perfectly fine on integrated GPUs, further reducing the cost.
Blender does this perfectly fine, for instance.
Recently Godot gained the ability to selectively remove features from the editor:
* https://godotengine.org/article/godot-32-will-allow-disablin...
* https://docs.godotengine.org/en/stable/classes/class_editorf...
The documentation describes it like this:
"""
When disabled, the features won't appear in the editor, which makes the editor less cluttered.
This is useful in education settings to reduce confusion or when working in a team.
For example, artists and level designers could use a feature profile that disables the script editor to avoid accidentally making changes to files[...]
"""
There's lots of superfluous stuff if you're making tools instead of games, but it doesn't really get in the way.
Edit: It was in the editor, just realized I didn't explicitly mention that.
Deleted Comment
If you want your game engine to be useful, it needs to perform well. It doesn't matter if your engine is home grown and only for your application, or if it is something you license to other developers. If it is to be useful, it needs to perform well. So, they do. Game engine developers are not stupid.
Sorry, just: no. Game engines which don't handle rectangle updates are poorly designed junk.
BTW, most game engines do keep track of regions needing update - its one of the most important aspects of performance tuning, for any app which presents objects on a screen to the user. Usually, the OS is doing this for an app in the apps own context - game engines also do this, and if they don't do it well, they get passed over for better-performing engines.
(Disclaimer: contributor to the MOAI game engine, which does this very, very well, and which is an amazing way to do a UI - for any app..)
I just figured that I'd share what appeared to be a useful comment from someone else the last time I participated in a discussion about this, I'm glad I did as I now have a number of further resources to do better research.
Also, just took a look at MOAI, it looks pretty cool, I'll have to add it to the list of things to play with when bored.
Having said that, the other issues concerning Qt may be valid, but for a code-only set of widgets, they work for me. For these kinds of comparisons to have value, you have to list the pros and cons of all things, not just the pros of what you like and cons of what you don't.
I wonder if, in another 20 years, we may see people speaking of "just 20GB"...
Do you want to flash image to USB drive? There is Electron app (balenaEtcher) for that.
Do you want to control your mouse/keyboard? There is Electron app for that (Logitech GHub), which also includes many Qt libraries.
Do you want a terminal emulator? There is an Electron based app for that.
...
I agree with you, although one thing worth pointing out is that with Qt (or similar) application frameworks on any decent operating system, you only have to download those libraries once, which means the individual overhead of an application remains extremely low.
For example, the LXQT default terminal, qterminal, comes in a package that is only 200 KB on Arch Linux, for the entire thing. (To be fair it directly depends on a library that provides a terminal widget, which is another 200 KB.)
that really depends on the application though. say you want to make a media player, you likely want to embed FFMPEG and that alone will be heavier than windows 3.11 because there are so many codecs today. Likewise for an image editor, you're gonna have to pack a whole lot of image format encoders / decoders.
Also note that Qt can basically run as-is on top of a linux kernel, directly rendering to the framebuffer and doing everything itself so it'll mechanically be a bit heavier than something like wx which uses the OS widget APIs instead.... but won't be able to run in place where there are no "OS widget APIs" (that is, 99.9% of embedded platforms), while Qt has that as a main market.
But other than Qt or wx, I really can't get behind these new GUI platforms which keep cropping up. They all have too many issues and don't end up presenting a native experience (or often even a good one).
In any case I think I’ve gotten a stripped static executable down to 5 or 6 MB.
I have an (admittedly simple) application using QtWidgets that is under 10 MiB statically linked.
Particularly in Windows.
Are there any visual scripting languages that aren't terrible? The system in unreal works but every time I use it I find myself wanting a text editor (I have spent years learning to program well, be that C++ or shaders, just let me do that!).
https://youtu.be/ydd6l3iYOZE
It is still just connecting blocks though as pierrec says below so it can take a lot of connections to get something done
What were the motivations behind creating GDScript?
In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed.
The main reasons for creating a custom scripting language for Godot were:
Poor threading support in most script VMs, and Godot uses threads (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
Poor class-extending support in most script VMs, and adapting to the way Godot works is highly inefficient (Lua, Python, JavaScript).
Many existing languages have horrible interfaces for binding to C++, resulting in large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.) We wanted to focus on a great engine, not a great amount of integrations.
No native vector types (vector3, matrix4, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
Garbage collector results in stalls or unnecessarily large memory usage (Lua, Python, JavaScript, ActionScript, etc.).
Difficulty to integrate with the code editor for providing code completion, live editing, etc. (all of them). This is well-supported by GDScript.
GDScript was designed to curtail the issues above, and more.
An additional aspect is that--in terms of language design--in many cases "do what Python does" was the design principle followed, so that helps reduce the learning curve for those with Python experience and potentially helps avoid language design roadblocks during development of GDScript itself.
It's extremely common for people to be resistant to using GDScript initially but then be: "oh, actually, this is really good".
And there's now additional bindings for other languages (e.g. C++, C#, Rust, Python to various degrees of completeness) via the "GDNative" interface that essentially provides a C API for communicating with Godot & passing objects around.
- Bloat... Both are extremely heavy dependencies if you want "the real deal" vs a stripped down version that looks like Python or JavaScript.
- Performance too. Python is slow. JavaScript too, unless you use the modern JITs.
- Licensing perhaps?
- Lack of support for that use case?
- Painful interop? No idea.
I personally dislike the python ecosystem and am not missing anything.
a lot of visual programming environments, like LabVIEW (1986) or Max/MSP (1985), predate Python and JS by at least a good few years :p
It's simple and straight forward.
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.
Deleted Comment
> 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.
A search about accessibility immediately popped up github issues acknowledging the difficulty making screen readers work: https://github.com/godotengine/godot/issues/29736
There are some applications that mimic all those friendly native behaviors, but it tends to take a lot of work, and sometimes pushing updates when the OS behaviors change.
I'm using cljfx these days and really enjoying it. For desktop apps I think it is a great choice [1].
The approach described using Godot could work well depending on the type of app, I think. For instance, this commercial app [2] is built using Kivy [3], which basically draws the controls using sdl+openGL, so a similar kind of setup as the Godot one described in the OP.
1: https://github.com/cljfx/cljfx
2: http://www.yeco.io/
3: https://kivy.org/#gallery