Splitting KGlobalAccel interface and runtime

[Jeremy Whiting]

Nevermind. rebuilt and everything seems to be working for now.

On Mon, Mar 6, 2023 at 10:02 AM Jeremy Whiting <jpwhiting at kde.org> wrote:

> Was something decided about this? I ask because I went and built
> frameworks kf6 over the weekend with kdesrc-build into /usr/local/ with my
> existing arch packages in /usr, etc. and afterwards the kf5 version of
> yakuake can no longer receive keyboard shortcuts (to hide/show, etc.) It's
> entirely possible I messed something up in the process, but thought I'd ask
> here in case kglobalaccel is still up in the air in regards to how it will
> work with kf5 and kf6 applications (or maybe I need to run both
> kglobalaccel5 and kglobalaccell6 or something during transition times?)
>
> thanks,
> Jeremy
>
> On Tue, Feb 14, 2023 at 8:25 AM Aleix Pol <aleixpol at kde.org> wrote:
>
>> On Tue, Feb 14, 2023 at 10:13 AM Kevin Ottens <ervin at kde.org> wrote:
>> >
>> > Hello,
>> >
>> > On Monday, 13 February 2023 21:25:54 CET Vlad Zahorodnii wrote:
>> > > On 2/13/23 22:05, Nicolas Fella wrote:
>> > > > Hi,
>> > > >
>> > > > the kglobalaccel framework currently contains two pieces:
>> kglobalacceld,
>> > > > the runtime component that manages global shortcuts, and an
>> > > > application-side library to interact with it.
>> > > >
>> > > > The two communicate with each other via DBus. On X11 there is a
>> > > > standalone kglobalacceld5 process providing the interface, on
>> Wayland
>> > > > the runtime is linked into KWin and thus the kwin_wayland process
>> > > > provides the interface.
>> > > >
>> > > > The current architecture has a number of downsides:
>> > > >
>> > > > - Any call to the KGlobalAccel library may DBus-activate the
>> > > > kglobalacceld5 process, which may be undesired on Desktop other than
>> > > > Plasma since it competes with their native shortcut system. We tried
>> > > > fixing that by making such calls no-op on !Plasma, but that broke
>> things
>> > > > for people that did want it to run, for example people using KWin
>> with
>> > > > LXQt, because KWin relies on KGlobalAccel for shortcuts
>> > > >
>> > > > - We want to keep the dependencies of the interface library minimal,
>> > > > which is inconvenient for the development of the runtime part. For
>> > > > example we really want to use KIO::ApplicationLauncherJob in the
>> > > > runtime, but currently can't, because that would introduce a
>> dependency
>> > > > cycle in Frameworks (KIO depends on KXmlGui, which depends on
>> > > > KGlobalAccel, which would depend on KIO)
>> > > >
>> > > > - Coinstallability of KF5 and KF6. Conceptually there can only be
>> one
>> > > > kglobalacceld. If both KF5 KGlobalAccel and KF6 KGlobalAccel
>> install a
>> > > > kglobalacceld this is going to be problematic. This also means that
>> a
>> > > > KF6-based kglobalacceld must work with a KF5 interface library
>> > > >
>> > > > - Other shortcut daemon implementations. Since somewhat recently
>> there
>> > > > is an XDG Portal for global shortcuts. Platforms like Windows and
>> macOS
>> > > > also have ways for applications to register global shortcuts. While
>> we
>> > > > are currently not using any of these it's very well possible that we
>> > > > would eventually want to use the KGlobalAccel interface library to
>> > > > interact with those. Having the kglobalacceld runtime in the same
>> > > > frameworks therefore doesn't feel right.
>> > > >
>> > > > To address these issues I suggest we split out the runtime part of
>> > > > kglobalaccel into its own project, under the Plasma release group,
>> > > > because that's primarily where it's used/supported. The interface
>> > > > library would remain in frameworks. We have a similar situation with
>> > > > activities, where the manager (kactivitymanagerd) is in Plasma and
>> the
>> > > > interface is in Frameworks. When doing this we'd also change the
>> way how
>> > > > kglobalacceld is started away from DBus activation towards
>> explicitly
>> > > > starting it as part of the Plasma startup. This avoids accidentally
>> > > > launching it when it shouldn't be but still allows to explicitly
>> start
>> > > > outside of Plasma if really wanted. It would also allow for greater
>> > > > flexibility in the development of the runtime, especially around
>> > > > dependency constraints.
>> > > >
>> > > > It wouldn't automatically solve the coinstallability problem of KF5
>> and
>> > > > KF6, because a kglobalacceld provided by KF5-KGlobalAccel would
>> still
>> > > > conflict with a Plasma-provided kglobalacceld, but it's at least
>> > > > conceptually less messy since it's clear that the Plasma-provided
>> one
>> > > > would be the preferred one to use.
>> > > >
>> > > > Thoughts about this?
>> > >
>> > > +1
>> > >
>> > > There's one caveat though: given that the library and the runtime
>> parts
>> > > will have different release schedules, we will have to be careful
>> about
>> > > protocol changes. Perhaps we could borrow a thing or two from
>> activities?
>> >
>> > Or... move both runtime and API on the Plasma side? This way no problem
>> of
>> > different release schedules and it makes it clear that using it ties
>> you to a
>> > specific desktop anyway?
>> >
>> > With a quick grep it looks like most of the users are already shipped
>> with
>> > Plasma or desktop specific anyway. Granted that leaves with a couple of
>> tough
>> > nuts to crack though.
>> >
>> > Regards.
>>
>> That would make sense. FWIW, on Wayland the kglobalaccel API as it is
>> right now is Plasma-specific. Then there's the XDG Desktop Portals
>> Global Shortcuts spec that should be implemented on apps. So it could
>> make sense to rethink what kglobalaccel is to us. That said, this is
>> quite a bit of work and I'm not sure it should be a top priority.
>>
>> Aleix
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20230306/35ea8c71/attachment-0001.htm>