Edit: To clarify, this is not my personal blog. It's just intended to raise awareness and spread it around here as well. I just don't believe in editorializing titles

all 3 comments

sorted by: hot top controversial new old
[–] 6 points 5 months ago (1 child)

The only touching point I ever had with accessability Hardware was a steelseries sentry (tobii eyetracker rebranded) out of novelty for my stream back then.

This was a very interesting read, stay strong mate! <3

  • source
  • hideshow 1 child comment
  • [–] [S] 8 points 5 months ago*

    Just to clarify, I didn't write this blog post. It's just intended to raise awareness and spread it around here as well. I just don't believe in editorializing titles

  • source
  • parent
  • [–] 0 points 5 months ago

    Use-case for having a functional desktop?

  • source
  • 3 comments in c/linux@lemmy.ml view that post
    [–] 7 points 5 months ago (2 children)

    not a single one of those compositors implement the entire API surface you need.

    Aegis has requested that those of us who wish to not see Talon on Linux die out do the following:

    • Do not, for any reason, discuss Wayland support with him;
    • As a community, gather together, and successfully implement the entire API surface needed for Talon on GNOME, KDE, and wlroots,

    At which point a new Wayland backend will be considered for Talon.

    I agree that it's not up to Talon to implement the missing APIs in the compositors. However, I think the dev is doing a disservice to the users of Talon by not adding wayland support (ie making the calls to the APIs Talon needs to function). If Talon used those wayland protocols, users could point to the software and say it's "not working on compositor because the compositor is missing wayland protocols".

    IMO its a much easier sell to the compositor people when they know a useful piece of software is actively trying to target those APIs.

    That being said, I sure hope the situation improves. The state of accessibility on wayland is pitiful.

  • source
  • hideshow 2 child comments
  • [–] 3 points 5 months ago (1 child)

    I don't know how you add a call to an API that doesn't exist

    as a solo dev, I honestly feel for him. It's just too much work to actually even think about when you have other environments to support

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 5 months ago

    I don't know how you add a call to an API that doesn't exist

    As far as I know, these messages are passed to the portal using dbus. So the app could just fire the correct dbus message with correct parameters (you can find the correct values in the Wayland specs). The portal, used by the compositor, then takes the message and runs the requested action or returns something like not implemented or unknown method.

    The trickier part is testing when no portal supports the API calls.

    But yeah, interoperability between systems can be a pain in the ass.

    The process is analogous to sending an http request. Your app sets up the httpclient and points it to a URI and after sending the request you get back either the content with 200 status or 404. If you get 404 you can show the user a message like "this website doesnt support feature xyz"

  • source
  • parent
  • 1 comment in c/technology@lemmy.world view that post
    [–] 3 points 5 months ago

    Talon Voice sounds to be an interesting thing.

    I think wayland developers could be further motivated to implement support for input accessibility tools by telling them it would help a lot for automation software too. Accessibility software can help the healthy users too, like in a form of a password manager that automatically fills out forms. Or like AutoHotkey or many other tools known from windows.

  • source