Re: Splitting KGlobalAccel interface and runtime
Nevermind. rebuilt and everything seems to be working for now. On Mon, Mar 6, 2023 at 10:02 AM Jeremy Whiting 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 wrote: > >> On Tue, Feb 14, 2023 at 10:13 AM Kevin Ottens 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
Re: Splitting KGlobalAccel interface and runtime
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 wrote: > On Tue, Feb 14, 2023 at 10:13 AM Kevin Ottens 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
Re: Splitting KGlobalAccel interface and runtime
On Tue, Feb 14, 2023 at 10:13 AM Kevin Ottens 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
Re: Splitting KGlobalAccel interface and runtime
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. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud supporting member of KDE https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: Splitting KGlobalAccel interface and runtime
Am Montag, 13. Februar 2023, 21:05:33 CET schrieb Nicolas Fella: > 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. While running both may never work, I would suggest making the KF6 kglobacceld register a versioned name (i.e. org.kde.kglobalaccel6) instead of org.kde.kglobalaccel and have the interface talk to that name to avoid autostarting a KF5 kglobalacceld. We can also go further and version the whole API http://0pointer.de/blog/ projects/versioning-dbus.html to make changes easier in the future. > This also means that a KF6-based kglobalacceld must work with a KF5 interface library The KF6 one should also register the old name and support the current DBus API so KF5 applications will not autostart a KF5 kglobalacceld. David
Re: Splitting KGlobalAccel interface and runtime
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? Regards, Vlad
