https://bugs.kde.org/show_bug.cgi?id=479127
Nate Graham <n...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REPORTED |RESOLVED
Resolution|--- |INTENTIONAL
--- Comment #3 from Nate Graham <n...@kde.org> ---
How would apps read those settings, though? Typically they just open up the raw
device right now, which means any settings we make around this would be ignored
and useless. What we would have to do is write a wrapper library that
facilitates interacting with a camera which does read our settings. But then
the problem is that every app that uses the camera would have to be ported to
use that library. This is feasible for KDE apps, but not for 3rd-party apps,
who it would be difficult to impossible to convince to use a KDE-specific
library for accessing the camera. As a result it would be a "broken promise"
global setting of the type that we are trying to move away from; see
https://community.kde.org/Get_Involved/Design/Frequently_Discussed_Topics#%22Broken_promise%22_global_options.
What would be a more appropriate approach would be to write the library
upstream in the XDG/FreeDesktop namespace, (like Libinput), define the settings
with a cross-desktop spec, and then begin the painful process of convincing
everyone in the world to use that library. This would probably take at least 10
years, and that's if the resources for such a project were even to materialize.
The reason this worked for Libinput is because Red Hat paid Peter Hutterer a
full-time salary to consistently put in that effort for over 10 years.
Prevailing wages being what they are, I'd guess that Red Hat has sunk more than
$1 million into the project.
As you can see, this would be an enormous amount of work. It's a good idea, but
it would be a multi-year project and I'm afraid is rather outside of the scope
of a KDE bug report. :)
--
You are receiving this mail because:
You are watching all bug changes.
