cross-posted from: https://feditown.com/post/3071906

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

    • trevor (he/they)@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      1
      ·
      36 minutes ago

      I agree, but this seems like a matter of poor communication. It doesn’t sound like the Talon dev knows that actual members of the KDE team are earnestly interested in making Talon work with their Wayland compositor. It sounds like they assumed is just another user asking for Wayland support without any way of helping to make it happen.

      The Talon and KDE devs should open a direct line of communication to actually get this going.

  • rumba@lemmy.zip
    link
    fedilink
    English
    arrow-up
    13
    ·
    8 hours ago

    Yeah, even from a non-accessibility standpoint, they’re severely lacking. Text replacement shortcuts, mouse automation, it feels like a nightmare when you long for the control Windows users still have over their systems.

    I’ve been using the Speed of Sound appimage for voice input, but it’s just basic whisper to text on a global hotkey. I can get mouse control via python but only relative positioning. I tried to hack in some dead reckoning going to a bounding corner and coming back out but it’s super cagey with accelleration which i’m not willing to turn off.

    You’re not an edge case; there are lots of us out there who would use a proper input api.

      • esc@piefed.social
        link
        fedilink
        English
        arrow-up
        1
        ·
        17 minutes ago

        There is wdotool, it’s not complete re-implementation yet, but it works.

      • rumba@lemmy.zip
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 hours ago

        same, these are surfaced in python, but it’s barely usable

        device = uinput.Device([
        uinput.BTN_LEFT,
        uinput.BTN_RIGHT,
        uinput.REL_X,
        uinput.REL_Y,
        ])

        device.emit(uinput.REL_X, 0)
        device.emit(uinput.REL_Y, 0)
        device.emit(uinput.BTN_LEFT, 1)
        device.emit(uinput.REL_X, -100)
        device.emit(uinput.REL_Y, -100)

    • exu@feditown.comOP
      link
      fedilink
      English
      arrow-up
      5
      ·
      6 hours 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 :)

      • Skullgrid@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        4 hours ago

        You can avoid the ambiguity by posting it as “Author: title of post”. This way we can see you attribute the post to someone else.

    • esc@piefed.social
      link
      fedilink
      English
      arrow-up
      7
      ·
      8 hours ago

      It’s not so bad like the article author describes, there is work being done to address the input issue e.g. libei and wayland protocols. (also N.Graham answer that says that it should be done on wayland level if they require universal solution is right if a bit unkind)

      • nyan@lemmy.cafe
        link
        fedilink
        English
        arrow-up
        5
        ·
        4 hours ago

        And how many years will it take before this reaches a usable state, when people need (not just want) it now?