top | item 30298534

SixtyFPS Becomes Slint

92 points| tronical | 4 years ago |slint-ui.com

58 comments

order

whylo|4 years ago

Hopefully this starts supporting accessibility tools before it gets too much traction and people start shipping inaccessible apps. The WebAssembley output demos on the homepage just render to a <canvas> and are completely inaccessible with any of the usual tools (screen reader, keyboard-only, voice dictation etc) but there's a GitHub issue (https://github.com/slint-ui/slint/issues/32) so fingers crossed.

robin_reala|4 years ago

Yeah, a UI toolkit that doesn’t have even basic accessibility bindings is basically illegal to use for commercial products in multiple major countries now. No specific shame on Slint (everyone has their own roadmaps) but when even big companies are failing* in this way it does seem like we’ve got a long way to go as an industry.

* Flutter has no accessibility bindings on the web and therefore falls under the same “illegal” category.

Cthulhu_|4 years ago

I don't think tools like this should be used to make websites / webapps, period; good enough for demo purposes, but just because you can, doesn't mean you should. Just make a good website / webapp, you get a lot of accessibility for free if you use semantically correct HTML and sprinkle in accessibility hints where needed.

Likewise, if you're building apps, prefer to build them using native toolkits if you value accessibility. The major platforms have it built in. When building an app, did you ever consider VoiceOver gestures [1]? Providing a readable text for the text-to-speech engine as an alternative to a UI element?

https://support.apple.com/guide/iphone/learn-voiceover-gestu...

cnity|4 years ago

To be clear, using canvas elements for UI is not inherently inaccessible so long as some accessible content on the page is also available to screen readers. Slint could in theory additionally render a kind of keyboard accessible overlay with invisible page elements, for example.

Edit: accessible -> inaccessible

torginus|4 years ago

The thing that (the generally excellent) MS UI Automation API has taught me is that making the UI accessible makes it testable and vice versa. Since any serious software projects needs tests, having a good accessibility story is paramount to delivering high-quality applications.

charcircuit|4 years ago

It should be possible with a good screen reader. It can read to the icons and text on the page to you. It might be hard to know which boxes are clickable, but that applies to using it normally too.

RobLach|4 years ago

This is an important factor. Accessibility only gets harder to integrate with time and is fundamental to any serious general long-term usage.

milesvp|4 years ago

The need to rebrand is unfortunate. High framerate is not nearly as important as low standard deviation in the framerate. Naughty dog has blogged on the topic, but it was well known decades earlier in the demo scene. Getting smooth animations on old hardware was not trivial, but people discovered that the way the brain and eye work in conjunction, you could create marquees that looked flawlessly smooth at 8 fps provided you always redrew the pixels with very precise timing.

I’ve sort of known this for a while, but I got to see a demo a few years ago. A friend set up an old amiga demo on a modern fpga, and I saw him get all the timings right for it to finally look smooth as silk on the monitor he had. Then he attached the original signal to a second monitor and the difference was night and day side by side. One was smooth, the other jerky. Both the same fps.

boondaburrah|4 years ago

The requirements state "If you're using C++, a compiler that supports C++ 20" and All I'm thinkin' is it must be nice to be able to choose a modern compiler like that. Some of us are lucky to get C++14.

I'm not saying we should be stuck on old compilers forever, but in C++ land, especially when I have to integrate with other frameworks or game engines, the assumption that I can choose my compiler or will always be on latest kinda irks me. Even Qt has versions for the last few MSVC releases (though thankfully the ABI stopped changing every release after VS2015).

That being said, this still looks pretty new, and by the time it's a mature framework C++20 itself may be more available.

milliams|4 years ago

I think that's a deliberate decision. They know that by the time it gains adoption even C++20 will be "old". By pinning the requirement high now, while there will mostly be early-adopters, startups, open source projects etc there's less of a cost.

pornel|4 years ago

On the Rust side they require a compiler released 10 weeks ago, and it is actually reasonable, thanks to Rust's strong backwards compatibility and painless auto-update.

ahartmetz|4 years ago

It's usually very old projects that are stuck with old C++ versions, no? I mostly work in embedded, and even there, new GCC or Clang versions are rarely hard to pull in.

s9w|4 years ago

[deleted]

zokier|4 years ago

The biggest problem to me with the old SixtyFPS brand was that it was always just aspirational thing and not really describing any property of the framework. As such it oversold the product and muddled the message as it was easy to point out that it in fact did not always hit 60fps. So while Slint as a brand might be less ambitious, at least it feels bit more honest

the_gipsy|4 years ago

In the kitchensink demo, the keyboard doesn't show when clicking the input, on mobile.