[HN Gopher] SixtyFPS Becomes Slint
___________________________________________________________________
SixtyFPS Becomes Slint
Author : tronical
Score : 90 points
Date : 2022-02-11 08:11 UTC (14 hours ago)
(HTM) web link (slint-ui.com)
(TXT) w3m dump (slint-ui.com)
| zokier wrote:
| 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 wrote:
| In the kitchensink demo, the keyboard doesn't show when clicking
| the input, on mobile.
| ComodoHacker wrote:
| Slint sounds to me like a linter for Swift or something like
| that. A variation on "slick" would be better IMO.
| SideburnsOfDoom wrote:
| I loved their 1991 album, "Spiderland"
|
| https://www.theguardian.com/music/2014/may/01/spiderland-sli...
| jfb wrote:
| It's a classic.
| beepbooptheory wrote:
| Any other frameworks that name overlap with a band?
| benplumley wrote:
| https://en.wikipedia.org/wiki/OSI_model /
| https://en.wikipedia.org/wiki/OSI_(band)
| alophawen wrote:
| To name a few:
|
| SDL: https://www.discogs.com/artist/707518-SDL
|
| DirectX: https://www.discogs.com/artist/4506329-Direct-X-2
|
| Vulkan: https://www.discogs.com/artist/1464296-Vulk%C3%A1n
| SideburnsOfDoom wrote:
| the "Direct X" one looks like an artist picking a "high-tech"
| name from a software framework.
|
| Slint is the other way around, if anything.
| whylo wrote:
| 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.
| RobLach wrote:
| This is an important factor. Accessibility only gets harder to
| integrate with time and is fundamental to any serious general
| long-term usage.
| charcircuit wrote:
| 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.
| robin_reala wrote:
| A screenreader doesn't literally read the screen, it reads
| the accessibility tree that apps build for their interfaces.
| If your user interface kit doesn't create an accessibility
| tree then your users' screenreaders are completely lost at
| sea.
| badsectoracula wrote:
| Considering year old mobiles are able to perform on-the-fly
| language translations in photos even via awful cameras, i
| find it weird that screenreaders still rely on such hints.
| kroltan wrote:
| Delete every CSS declaration (both inline or stylesheets)
| from every website and see how easy it is to read them.
| Not very, huh? Same deal with accessibility.
|
| You can't "just OCR stuff" without losing all the visual
| meaning in a page. Just like we use borders and paddings
| and colors to hierarchize information, screenreaders use
| an information hierarchy too so users can conveniently
| navigate around.
| badsectoracula wrote:
| I wasn't referring to just OCR stuff (or even just web
| stuff) though, my point was that there is enough
| information in the screen to make out detail - computer
| vision is more a broad subject than just scanning text.
| ~12 years ago i was working on getting a computer figure
| out where 2D boxes were in a feed from a camera (for
| augmented reality, not accessibility) and my algorithm
| was quite naive and primitive, but also the source was
| some awful web camera, not something "pristine" like a
| screen's content.
|
| Of course i don't _know_ that it is possible, it could be
| impossible, i 'm just having the impression that there
| hasn't been much effort towards that approach. And TBH it
| kinda feels like it'd be much better to have a solution
| that works with "everything" without that "everything"
| knowing about it (or at least with very little
| participation from that).
|
| Also FWIW i often use a "simple" web browser like Dillo
| or Elinks to read articles since it bypasses all the
| cruft and the usual suspect for making things unreadable
| isn't CSS but JavaScript.
| gostsamo wrote:
| OCR is relatively easy, but the accessibility information
| is not only that. There are the types of elements, the
| possible interactions and the changes on the screen.
| Also, it gives the ability to skip unnecessary
| information. Using ml for all of that is taxing and
| probably not very practical until the invention of AGI.
| badsectoracula wrote:
| I wasn't referring to just OCR, check my other comment.
| charcircuit wrote:
| >A screenreader doesn't literally read the screen
|
| Why not? The approach of creating an accessibility tree can
| take extra work from developers instead of it just working.
| It's convenient to be able to just use an image without
| writing alt text for it. For example in a group chat.
| marcellus23 wrote:
| > The approach of creating an accessibility tree can take
| extra work from developers instead of it just working.
|
| Because this isn't true unless you're using a nonnative
| framework like Flutter. If you write your apps in HTML or
| native frameworks, the tree is built automatically. You
| only have to fiddle with it if you're doing really custom
| stuff (which almost no one is).
| charcircuit wrote:
| The project that is being linked to renders everything
| into a canvas. It's extra work to create a separate tree
| for another program to digest.
| marcellus23 wrote:
| You asked why not. That's the answer -- why should
| platforms create an overcomplicated ML-based solution to
| try to screen read (assuming such a thing is even
| possible, which I don't believe it is), when existing
| solutions using standard frameworks work fine and _don't_
| require devs to spend extra time?
| robin_reala wrote:
| An image on its own: sure, our tech is getting pretty
| good at recognising the contents. An image in context?
| Almost impossible to tell whether it's meant to be
| decorative, inspirational, factual, or to be OCRed for
| text without some sort of hint.
|
| Or what about a chart, or an assembly or measurement
| diagram? Can current image recognition reliably reproduce
| that information?
|
| At the end of the day, the extra work by developers is
| part of what it means to be a developer. If you're not
| doing that work then is the end product really meeting
| your users' needs?
| charcircuit wrote:
| A screen reader could be made to describe those things.
| Even if it failed I don't see how it could be worse than
| it just saying that there is an image there.
| cnity wrote:
| 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
| whylo wrote:
| Sure - that's the approach Google have taken with Docs, which
| switched to canvas-based rendering last year
| (https://thenewstack.io/google-docs-switches-to-canvas-
| render...). It's definitely not for the faint of heart
| though.
| torginus wrote:
| 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.
| robin_reala wrote:
| 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.
| easrng wrote:
| Flutter does handle accessibility on the web, but not very
| well. You need to press a button hidden from non-screenreader
| users and then Flutter will make a tree of dummy elements
| with aria attributes that let you use the app. You can see
| this if you use a screenreader or your browser of choice's
| accessibility tree inspector on the demo app.
| robin_reala wrote:
| Ah, OK, looks like they've progressed a bit since I
| evaluated it. Thanks for the update.
| nindalf wrote:
| I'm surprised by how much progress we've made in this area. I
| used to make android apps circa 2013-15. Accessibility was an
| afterthought, a nice to have.
|
| Reading the SwiftUI docs in 2022, it's front and centre. They
| tutorial covers accessibility soon after "hello world". Every
| module of the tutorial has a section on setting the right
| accessibility info, rather than a single, optional
| accessibility tutorial. It makes me happy that doing the
| right thing is the default.
|
| I'm planning on making a small productivity app just for
| myself, but it'll be 100% accessible simply because they've
| made it so easy.
| paxswill wrote:
| Integrating accessibility into the tutorial is fantastic,
| but I'd also attribute it to Apple emphasizing
| accessibility in their developer documentation for a long
| time. I remember one of the early Interface Builder
| tutorials explaining accessibility pretty early on.
| mirashii wrote:
| I wouldn't attribute this to progress. iOS and macOS have
| always heavily prioritized accessibility. For Google, you
| can see in this example and in the flutter example that
| accessibility is an after thought.
| ATsch wrote:
| The last time I spoke to a blind person it was quite a
| different picture, she was more or less forced to
| exclusively use apple products because nobody else took
| accessibility seriously enough.
| badsectoracula wrote:
| > a UI toolkit that doesn't have even basic accessibility
| bindings is basically illegal to use for commercial products
| in multiple major countries now
|
| Any sources for that? I've never seen such a claim outside of
| Hacker News. A quick Google search i did about it only shows
| some court cases in U.S. (and in those cases it seems to be
| up to the judge with many failing). The closest is a
| requirement from EU in 2018 that web sites by the member
| states' government (ie. it is only for government web sites)
| has to be accessible. That makes sense, but it only covers
| government web sites specifically, not any other use for a
| toolkit (e.g. desktop apps) or even private sites.
| robin_reala wrote:
| Sure.
|
| In the US is the ADA which stipulates "reasonable
| accomodations" to be made for users with disabilities. You
| could argue that providing e.g. a phone system as an
| alternative helps to satisfy this, but it's debatable, and
| has been debated backwards and forwards in the US court
| system.
|
| In Canada, from 2021-01-01 the AODA (Accessibility for
| Ontarians with Disabilities Act) specifically calls out
| WCAG 2.0 double-AA (with a few, very minor, changes around
| closed captioning) as the minimum for both public and
| private sector businesses.
|
| Israel also has a minimum requirement of WCAG 2.0 double-AA
| codified into law.
|
| Norway, while not specifically mentioning a standard or
| guideline, has accessibility requirements interpreted by
| their regulator to meet WCAG 2.1 double-AA.
|
| And the whole of the EU will gain a minimum requirement of
| WCAG 2.1 double-AA for the private sector from 2025-06-28
| (that's already the case for the EU public sector).
| Something to be aware of if you're purchasing software /
| white-label systems now.
|
| While it's a little out of date now, a good starting point
| is https://www.w3.org/WAI/policies/.
| badsectoracula wrote:
| Hoes do all those translate to UI toolkits not having
| accessibility functionality being illegal though?
|
| It is largely a legalese infodump that makes it very hard
| to parse, but i skimmed through the EU proposal (most of
| its requirements being at the annex) and it largely seems
| to be for websites or for very specific uses where it'd
| make sense (Check-in stations, ticket stations, ATMs,
| E-commerce sites, etc). The closest to a more general
| requirement would be the requirement for operating
| systems to provide functionality like text-to-speech (it
| mentions "more than one sensory channel" so i assume that
| would fit), zooming, etc but the wording on that seems to
| be about the complete package - so i guess if that
| proposal passes, a store wouldn't be able to sell, e.g.,
| a computer with Linux and IceWM preinstalled as the only
| desktop (no text to speech there).
|
| When you wrote that UI toolkits without accessibility
| functionality being illegal was there anything more clear
| and specific or is it this just more of a "just in case"
| scenario?
| carapace wrote:
| > How do all those translate to UI toolkits not having
| accessibility functionality being illegal though?
|
| You put up a non-conforming website using one of these UI
| toolkits, someone sues you (there are lawyers who
| specialize in this), you lose and have to pay lots of
| money. And then you still have to make your site
| conforming.
| lelandfe wrote:
| Note: this is all specific to the US.
|
| https://equidox.co/blog/robles-v-dominos-pizza-explained-
| no-...
|
| Domino's was sued by a man who is blind who was unable to
| order a pizza online.
|
| Unfortunately, requirements for websites to be considered
| "accessible" in a legal sense are essentially undefined
| in the US. Here's how the site above summarizes, emphasis
| theirs:
|
| > Title III of the ADA mandates that all places of public
| accommodation _and their services_ must not discriminate
| against those with disabilities. According to the 9th
| Circuit Court of Appeals, that includes making websites
| equally accessible for people who use assistive
| technology.
|
| Lacking precise guidelines, the thinking in the web
| community generally is that if your site adheres to WCAG
| 2.0 or higher, there will be little purchase for folks to
| sue. Adherence to that standard has also been mandated in
| the past by courts in settlements.
| robin_reala wrote:
| An inaccessible toolkit itself wouldn't be illegal in the
| EU, but producing an end-user facing interface under the
| scope of the EU directive[1] (which as you mentioned is
| rambling but pretty wide ranging - "consumer terminal
| equipment with interactive computing capability, used for
| electronic communications services" could apply to most
| things that HN people work on) using that inaccessible
| toolkit would be.
|
| But that's just the EU. In the AODA[2] for example (which
| is already law), "barrier" is defined as "anything that
| prevents a person with a disability from fully
| participating in all aspects of society because of his or
| her disability, including a physical barrier, an
| architectural barrier, an information or communications
| barrier, an attitudinal barrier, a technological barrier,
| a policy or a practice" and sets out a process for the
| development / adoption of standards (the aforementioned
| WCAG 2.0 double-AA) and binds public and private sector
| to meet those standards to remove the barriers. Use of an
| inaccessible toolkit would certainly constitute "a
| technological barrier".
|
| [1] https://eur-lex.europa.eu/legal-
| content/EN/TXT/?uri=uriserv%...
|
| [2] https://www.ontario.ca/laws/statute/05a11
| [deleted]
| badsectoracula wrote:
| I think even in those the application would matter. For
| example i don't see how something like an image editor
| (which was the original application for Gtk, for example,
| even if nowadays Gtk has some accessibility support) or a
| specialized tool like [0] would be illegal (i don't know
| if it has accessibility support but for the sake of
| argument lets assume it doesn't).
|
| I can see there being an issue with something like a chat
| program though (i wonder if XChat will now be illegal to
| sell :-P).
|
| [0] https://shadermap.com/home/
| lelandfe wrote:
| US FE engineer here. I have worked with major online
| retailers for accessibility remediation after they were
| successfully sued for WCAG failures.
|
| The biggest thing, folks, is your navigation. If you run
| a large site and users can't control your navigation with
| a keyboard at _minimum_ , you're really leaving people
| out in the cold - and asking for a lawsuit, depending on
| the industry and your country. I'm looking at you,
| dropdowns.
|
| Full WCAG compliance is expensive and requires vigilance,
| but getting your navigation right should be priority 0.
| Cthulhu_ wrote:
| 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...
| milesvp wrote:
| 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 wrote:
| 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.
| s9w wrote:
| pornel wrote:
| 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.
| boondaburrah wrote:
| Yeah the problem isn't nearly as pronounced for rust, since
| rustup exists and rust itself isn't really available on any
| platforms you can't just update the toolchain yourself.
|
| C++ has a lot more tangled dependencies going on especially
| when you're stuck with a vendor's compiler.
|
| Make no mistake: the problem here isn't necessarily
| technological.
| jcelerier wrote:
| I don't understand what would be an environment where you
| could fetch the latest rust from internet but not the
| latest clang. I do my builds on centos:8 (well, rockylinux
| now) and it has access to the latest GCC 11. On Debian
| derivatives llvm itself provides up to date repos and on
| Windows, llvm-mingw works perfectly.
| TonyTrapp wrote:
| C++ the language also has pretty strong backwards
| compatibility. It's also trivial to install a new Clang
| version on most systems. But it certain spaces that's not
| what matters. Maybe you are only allowed to use That One
| Certified Compiler from 15 years ago and getting a
| certification for a newer compiler is not feasible. Or maybe
| you're on a system where the C++ standard library is part of
| the system and so you cannot use newer language features
| because that would require raising the minimum required OS
| version (I remember that some parts of the C++ standard
| library are not available if you compile for older macOS
| versions, for example).
| ahartmetz wrote:
| 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.
| milliams wrote:
| 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.
___________________________________________________________________
(page generated 2022-02-11 23:02 UTC)