[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