[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: Re: Splitting KGlobalAccel interface and runtime
From: Jeremy Whiting <jpwhiting () kde ! org>
Date: 2023-03-06 18:38:28
Message-ID: CADWV2K7kT3sME6EqQn3S73RgwsuFKGzyeehzigURsWkWOnSZxQ () mail ! gmail ! com
[Download RAW message or body]
Nevermind. rebuilt and everything seems to be working for now.
On Mon, Mar 6, 2023 at 10:02 AM Jeremy Whiting <jpwhiting@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@kde.org> wrote:
>
>> On Tue, Feb 14, 2023 at 10:13 AM Kevin Ottens <ervin@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
>>
>
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Nevermind. \
rebuilt and everything seems to be working for now.<br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 6, 2023 at \
10:02 AM Jeremy Whiting <<a \
href="mailto:jpwhiting@kde.org">jpwhiting@kde.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" \
style="font-family:monospace">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?)</div><div class="gmail_default" \
style="font-family:monospace"><br></div><div class="gmail_default" \
style="font-family:monospace">thanks,</div><div class="gmail_default" \
style="font-family:monospace">Jeremy<br></div></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Tue, Feb 14, 2023 at 8:25 AM Aleix Pol <<a \
href="mailto:aleixpol@kde.org" target="_blank">aleixpol@kde.org</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Feb 14, 2023 \
at 10:13 AM Kevin Ottens <<a href="mailto:ervin@kde.org" \
target="_blank">ervin@kde.org</a>> wrote:<br> ><br>
> Hello,<br>
><br>
> On Monday, 13 February 2023 21:25:54 CET Vlad Zahorodnii wrote:<br>
> > On 2/13/23 22:05, Nicolas Fella wrote:<br>
> > > Hi,<br>
> > ><br>
> > > the kglobalaccel framework currently contains two pieces: \
kglobalacceld,<br> > > > the runtime component that manages global \
shortcuts, and an<br> > > > application-side library to interact with \
it.<br> > > ><br>
> > > The two communicate with each other via DBus. On X11 there is a<br>
> > > standalone kglobalacceld5 process providing the interface, on \
Wayland<br> > > > the runtime is linked into KWin and thus the kwin_wayland \
process<br> > > > provides the interface.<br>
> > ><br>
> > > The current architecture has a number of downsides:<br>
> > ><br>
> > > - Any call to the KGlobalAccel library may DBus-activate the<br>
> > > kglobalacceld5 process, which may be undesired on Desktop other \
than<br> > > > Plasma since it competes with their native shortcut system. \
We tried<br> > > > fixing that by making such calls no-op on !Plasma, but \
that broke things<br> > > > for people that did want it to run, for example \
people using KWin with<br> > > > LXQt, because KWin relies on KGlobalAccel \
for shortcuts<br> > > ><br>
> > > - We want to keep the dependencies of the interface library \
minimal,<br> > > > which is inconvenient for the development of the runtime \
part. For<br> > > > example we really want to use \
KIO::ApplicationLauncherJob in the<br> > > > runtime, but currently \
can't, because that would introduce a dependency<br> > > > cycle in \
Frameworks (KIO depends on KXmlGui, which depends on<br> > > > KGlobalAccel, \
which would depend on KIO)<br> > > ><br>
> > > - Coinstallability of KF5 and KF6. Conceptually there can only be \
one<br> > > > kglobalacceld. If both KF5 KGlobalAccel and KF6 KGlobalAccel \
install a<br> > > > kglobalacceld this is going to be problematic. This also \
means that a<br> > > > KF6-based kglobalacceld must work with a KF5 \
interface library<br> > > ><br>
> > > - Other shortcut daemon implementations. Since somewhat recently \
there<br> > > > is an XDG Portal for global shortcuts. Platforms like \
Windows and macOS<br> > > > also have ways for applications to register \
global shortcuts. While we<br> > > > are currently not using any of these \
it's very well possible that we<br> > > > would eventually want to use \
the KGlobalAccel interface library to<br> > > > interact with those. Having \
the kglobalacceld runtime in the same<br> > > > frameworks therefore \
doesn't feel right.<br> > > ><br>
> > > To address these issues I suggest we split out the runtime part of<br>
> > > kglobalaccel into its own project, under the Plasma release group,<br>
> > > because that's primarily where it's used/supported. The \
interface<br> > > > library would remain in frameworks. We have a similar \
situation with<br> > > > activities, where the manager (kactivitymanagerd) \
is in Plasma and the<br> > > > interface is in Frameworks. When doing this \
we'd also change the way how<br> > > > kglobalacceld is started away \
from DBus activation towards explicitly<br> > > > starting it as part of the \
Plasma startup. This avoids accidentally<br> > > > launching it when it \
shouldn't be but still allows to explicitly start<br> > > > outside of \
Plasma if really wanted. It would also allow for greater<br> > > > \
flexibility in the development of the runtime, especially around<br> > > > \
dependency constraints.<br> > > ><br>
> > > It wouldn't automatically solve the coinstallability problem of \
KF5 and<br> > > > KF6, because a kglobalacceld provided by KF5-KGlobalAccel \
would still<br> > > > conflict with a Plasma-provided kglobalacceld, but \
it's at least<br> > > > conceptually less messy since it's clear \
that the Plasma-provided one<br> > > > would be the preferred one to \
use.<br> > > ><br>
> > > Thoughts about this?<br>
> ><br>
> > +1<br>
> ><br>
> > There's one caveat though: given that the library and the runtime \
parts<br> > > will have different release schedules, we will have to be careful \
about<br> > > protocol changes. Perhaps we could borrow a thing or two from \
activities?<br> ><br>
> Or... move both runtime and API on the Plasma side? This way no problem of<br>
> different release schedules and it makes it clear that using it ties you to \
a<br> > specific desktop anyway?<br>
><br>
> With a quick grep it looks like most of the users are already shipped with<br>
> Plasma or desktop specific anyway. Granted that leaves with a couple of \
tough<br> > nuts to crack though.<br>
><br>
> Regards.<br>
<br>
That would make sense. FWIW, on Wayland the kglobalaccel API as it is<br>
right now is Plasma-specific. Then there's the XDG Desktop Portals<br>
Global Shortcuts spec that should be implemented on apps. So it could<br>
make sense to rethink what kglobalaccel is to us. That said, this is<br>
quite a bit of work and I'm not sure it should be a top priority.<br>
<br>
Aleix<br>
</blockquote></div>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic