KDE Goals - Call For Submissions
blogs.kde.org
In 2015, some members of the KDE community began a conversation about where KDE was heading and how it would get there. That conversation became the seed of what is now KDE Goals - a community initiative to help guide KDE's efforts around shared objectives.
  • definitemaybe@lemmy.ca
    1·
    3 days ago

    There was a fantastic blog post about accessibility problems with Wayland, but I think Wayland is upstream of KDE, isn’t it?

    In other words, do you know if what you’re suggesting within scope, or is it upstream? Or maybe it’s both, and KDE and Wayland both need changes to enable proper accessibility?

    I don’t know enough, but I’ll see if I can track down that blog post and post about accessibility. Worst case, it lets KDE devs know that accessibility with KDE/Wayland is a major issue for many users.

    Edit: I found the post: My Accessibility Stack and the future on Wayland

    • Obin@feddit.org
      2·
      3 days ago

      If there’s still wayland protocol extensions required for this functionality (which I don’t think, kwin should have everything it needs, protocols would only be necessary if you’d want a DE-agnostic client application to manage the hotkeys), then KDE is in the best position to get things moving. With wayland development, nothing gets done without a reference implementation and vote from a big compositor, so sitting back and waiting “until things improve” is rarely a valid strategy.

      I don’t know about the accessibility side of this, but from how uninterested the devs are every time it’s brought up I can only assume that a keyboard-centric workflow is no longer a focus for KDE. Which is a shame, because with khotkey, KDE previously did provide the best experience out of all major DEs. Now it’s down among worst, when even Gnome(!) has retained some kind of custom hotkey functionality on wayland.

      • definitemaybe@lemmy.ca
        1·
        3 days ago

        It’s tightly interconnected with accessibility because alternative input systems, like eye gaze input, macros to expand text, and other accessibility tools for alternative input hardware all friends in the same types of window-agnostic input interacting. (Similarly for output hardware, I think?)

        Like, custom text replacement with XCompose breaks because of how Wayland “silos” programs, which is why ~/.XCompose files only partially work in KDE Plasma. If Wayland/KDE fully implemented accessibility tools, then it would be possible to solve all of these problems.

        Or, at least, that’s my layman’s understanding of the situation.