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.
  • Obin@feddit.org
    2·
    2 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·
      2 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.