Nevermind. rebuilt and everything seems to be working for now. On Mon, Mar 6, 2023 at 10:02 AM Jeremy Whiting <jpwhit...@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 <aleix...@kde.org> wrote: > >> On Tue, Feb 14, 2023 at 10:13 AM Kevin Ottens <er...@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 >> >
