221–230 of 259 posts
Earlier quoted context omitted.
The node/noodle system in Blender is really good.
There's a node system in Blender?
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
The cited laws only cover public bodies, though. They are not applicable to websites or applications built in the private sector.
Yes; for now. 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, y…
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.
Earlier quoted context omitted.
Also, modern processors might run the code anyway and trow away the path not taken. Its better to optimize by generating a function that does not have branches.
I don't think that applies to conditional rendering, does it? You can't speculatively execute a graphics API command buffer submission and then dash after it shouting "wait, come back, I didn't mean it". Same with any kind of I/O, I'd think.
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 somethi…
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.
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.
I think Lazarus is a much better environment for creating desktop apps which are small, cross-platform and very fast. The component architecture is much more advanced than Godot and you have access to a huge number of components. Extending these components or creating new components is also very easy.
I'm sure the tooling is better by now, but I remember being pretty happy not to need to touch Pascal anymore by the late '90s. The APIs that expected Pascal conventions were often pretty miserable to use.
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.
Why would any software not use an established scripting language like Python or JavaScript? Isn't it just makework and reinventing the wheel (badly)?
Earlier quoted context omitted.
This is FUD unless you source your claims. - 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…
> - 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…
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".
> laws
Those are not for general purpose commercial apps as I wrote, only for public or specialized apps.
> You don't know anyone who's faced issues yet.
So then it is fear mongering, aka FUD.
> Provide information in accessible formats and technologies
Information, not GUI on apps.
Public information, at that.
It is simply impossible to require at the moment accessibility for web apps or native apps.
It does not even make sense for a huge amount of software. For example, an image editor or the vast majority of games cannot be accessible for a blind person with current technology.
Accessibility is critical on information and documents, not on common apps. That is why things like websites using fancy web frameworks just to display text is bad because they tend to break it. Nobody is discussing that, you are conflating apps with documents.
Earlier quoted context omitted.
The cited laws only cover public bodies, though. They are not applicable to websites or applications built in the private sector.
Yes; for now. 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, y…
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.
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 bei…