Re: Re: Where to put kglobalacceld?
On Saturday 12 April 2014 17:11:47 David Faure wrote: On Monday 07 April 2014 21:20:19 Ben Cooksley wrote: On Mon, Apr 7, 2014 at 9:12 PM, Àlex Fiestas afies...@kde.org wrote: On Friday 04 April 2014 15:41:07 Martin Gräßlin wrote: Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. I would put it in a separate repo just to make sure distributions do not add plasma-workspace as a dependency of kglobalaccel (which will mean that application developers will run away from the dependency). What about kglobalaccel-runtime ? Frameworks has gone well overkill with the desire to split everything into separated repositories. Such a repository makes no sense. If this is such a problem, then kglobalaccel (the framework) should gain backends for Windows, Mac, Other DE, etc. integration and kglobalacceld is merely the implementation used in a Plasma workspace. But kglobalacceld is probably the correct implementation for gnome, lxqt, xfce, and all others on the X11 platform, isn't it? It's not related to the DE, only to X11. So making it (kglobalacceld, the X11 backend) part of Plasma excludes these other DEs for good. Martin's comment indicates that with wayland the functionality would become part of the DE though but that's another backend. I would make it part of the kglobalaccel framework, and only compiled on X11. The dependencies can certainly be trimmed down, I just removed some unnecessary ones. We're left with KF5::GlobalAccel KF5::I18n KF5::WindowSystem # KKeyServer KF5::DBusAddons # KDBusService KF5::CoreAddons # KAboutData KF5::ConfigCore KF5::Crash where I18n and CoreAddons could be removed too. Note that I already started to trim down the dependencies ([1], [2]). KCrash might also be possible to remove - see my question on whether it's needed for dbus activated apps. KKeyServer might also be a dependency which could be ported to a more low level variant through xkb. I'll have to look into that. Cheers Martin [1] https://git.reviewboard.kde.org/r/117455/ [2] https://git.reviewboard.kde.org/r/117464/ signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put kglobalacceld?
On Monday 07 April 2014 21:20:19 Ben Cooksley wrote: On Mon, Apr 7, 2014 at 9:12 PM, Àlex Fiestas afies...@kde.org wrote: On Friday 04 April 2014 15:41:07 Martin Gräßlin wrote: Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. I would put it in a separate repo just to make sure distributions do not add plasma-workspace as a dependency of kglobalaccel (which will mean that application developers will run away from the dependency). What about kglobalaccel-runtime ? Frameworks has gone well overkill with the desire to split everything into separated repositories. Such a repository makes no sense. If this is such a problem, then kglobalaccel (the framework) should gain backends for Windows, Mac, Other DE, etc. integration and kglobalacceld is merely the implementation used in a Plasma workspace. But kglobalacceld is probably the correct implementation for gnome, lxqt, xfce, and all others on the X11 platform, isn't it? It's not related to the DE, only to X11. So making it (kglobalacceld, the X11 backend) part of Plasma excludes these other DEs for good. Martin's comment indicates that with wayland the functionality would become part of the DE though but that's another backend. I would make it part of the kglobalaccel framework, and only compiled on X11. The dependencies can certainly be trimmed down, I just removed some unnecessary ones. We're left with KF5::GlobalAccel KF5::I18n KF5::WindowSystem # KKeyServer KF5::DBusAddons # KDBusService KF5::CoreAddons # KAboutData KF5::ConfigCore KF5::Crash where I18n and CoreAddons could be removed too. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Where to put kglobalacceld?
On Friday 04 April 2014 16:06:32 Aleix Pol wrote: On Fri, Apr 4, 2014 at 3:41 PM, Martin Gräßlin mgraess...@kde.org wrote: Hi, similar as to what we already have with DrKonqi moving kglobalacceld from kde- runtime into the globalaccel framework would significantly raise the tier and dependencies. At the moment KGlobalAccel is a tier1 framework. The runtime component though depends on: * KF5::GlobalAccel * KF5::KCMUtils * KF5::I18n * KF5::XmlGui * KF5::WindowSystem * KF5::DBusAddons * KF5::Notifications * KF5::KIOWidgets * KF5::Crash Even if we consider that some are probably not needed it would at least become tier2. Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. Opinions? Cheers Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel In that case, I'd suggest moving it to plasma-workspace, but then we'll have to make sure to make it explicit that KGlobalAccel is not a portable framework, rendering components depending on it not portable (with emphasis on KXmlGui) to platforms not supported by Plasma (or KWin). Not having a functional KGlobalAccel on Gnome sounds quite a regression to me though... I just got the feedback from LXQt that they might consider using KGlobalAccel. That would clearly speak against putting the runtime component into plasma- workspace. But I also think that our current dependencies in the runtime component are too heavy. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Where to put kglobalacceld?
On Wed, Apr 9, 2014 at 9:34 AM, Martin Gräßlin mgraess...@kde.org wrote: On Friday 04 April 2014 16:06:32 Aleix Pol wrote: On Fri, Apr 4, 2014 at 3:41 PM, Martin Gräßlin mgraess...@kde.org wrote: Hi, similar as to what we already have with DrKonqi moving kglobalacceld from kde- runtime into the globalaccel framework would significantly raise the tier and dependencies. At the moment KGlobalAccel is a tier1 framework. The runtime component though depends on: * KF5::GlobalAccel * KF5::KCMUtils * KF5::I18n * KF5::XmlGui * KF5::WindowSystem * KF5::DBusAddons * KF5::Notifications * KF5::KIOWidgets * KF5::Crash Even if we consider that some are probably not needed it would at least become tier2. Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. Opinions? Cheers Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel In that case, I'd suggest moving it to plasma-workspace, but then we'll have to make sure to make it explicit that KGlobalAccel is not a portable framework, rendering components depending on it not portable (with emphasis on KXmlGui) to platforms not supported by Plasma (or KWin). Not having a functional KGlobalAccel on Gnome sounds quite a regression to me though... I just got the feedback from LXQt that they might consider using KGlobalAccel. That would clearly speak against putting the runtime component into plasma- workspace. But I also think that our current dependencies in the runtime component are too heavy. Cheers Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel It's in Plasma Workspace for the moment. Maybe they can help us work on the dependencies...? Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put kglobalacceld?
On Friday 04 April 2014 15:41:07 Martin Gräßlin wrote: Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. I would put it in a separate repo just to make sure distributions do not add plasma-workspace as a dependency of kglobalaccel (which will mean that application developers will run away from the dependency). What about kglobalaccel-runtime ? Cheers. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put kglobalacceld?
On Mon, Apr 7, 2014 at 9:12 PM, Àlex Fiestas afies...@kde.org wrote: On Friday 04 April 2014 15:41:07 Martin Gräßlin wrote: Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. I would put it in a separate repo just to make sure distributions do not add plasma-workspace as a dependency of kglobalaccel (which will mean that application developers will run away from the dependency). What about kglobalaccel-runtime ? Frameworks has gone well overkill with the desire to split everything into separated repositories. Such a repository makes no sense. If this is such a problem, then kglobalaccel (the framework) should gain backends for Windows, Mac, Other DE, etc. integration and kglobalacceld is merely the implementation used in a Plasma workspace. Cheers. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Regards, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Where to put kglobalacceld?
On Monday 07 April 2014 11:12:50 Àlex Fiestas wrote: On Friday 04 April 2014 15:41:07 Martin Gräßlin wrote: Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. I would put it in a separate repo just to make sure distributions do not add plasma-workspace as a dependency of kglobalaccel (which will mean that application developers will run away from the dependency). they cannot as that would be a circular dependency. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put kglobalacceld?
On Monday 07 April 2014 21:20:19 Ben Cooksley wrote: On Mon, Apr 7, 2014 at 9:12 PM, Àlex Fiestas afies...@kde.org wrote: On Friday 04 April 2014 15:41:07 Martin Gräßlin wrote: Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. I would put it in a separate repo just to make sure distributions do not add plasma-workspace as a dependency of kglobalaccel (which will mean that application developers will run away from the dependency). What about kglobalaccel-runtime ? Frameworks has gone well overkill with the desire to split everything into separated repositories. Such a repository makes no sense. If this is such a problem, then kglobalaccel (the framework) should gain backends for Windows, Mac, Other DE, etc. integration and kglobalacceld is merely the implementation used in a Plasma workspace. Yes, that's exactly the situation we should aim at. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put kglobalacceld?
El Dilluns, 7 d'abril de 2014, a les 21:20:19, Ben Cooksley va escriure: On Mon, Apr 7, 2014 at 9:12 PM, Àlex Fiestas afies...@kde.org wrote: On Friday 04 April 2014 15:41:07 Martin Gräßlin wrote: Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. I would put it in a separate repo just to make sure distributions do not add plasma-workspace as a dependency of kglobalaccel (which will mean that application developers will run away from the dependency). What about kglobalaccel-runtime ? Frameworks has gone well overkill with the desire to split everything into separated repositories. +1 Remember when the slackware people stopped building Gnome because it was too hard? Wonder what they'll think of the repo monstruosity we're creating :D Yes, and I know we have tools to build it, and I'm using them to some extent. I just feel we went ran away from one monolothic kdelibs too fast and ended up with probably too much repos. Sorry for the rant, feel free to ignore :-) Cheers, Albert Such a repository makes no sense. If this is such a problem, then kglobalaccel (the framework) should gain backends for Windows, Mac, Other DE, etc. integration and kglobalacceld is merely the implementation used in a Plasma workspace. Cheers. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Regards, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Where to put kglobalacceld?
On Saturday 05 April 2014 17:01:53 Albert Astals Cid wrote: El Divendres, 4 d'abril de 2014, a les 15:41:07, Martin Gräßlin va escriure: Hi, similar as to what we already have with DrKonqi moving kglobalacceld from kde- runtime into the globalaccel framework would significantly raise the tier and dependencies. At the moment KGlobalAccel is a tier1 framework. The runtime component though depends on: * KF5::GlobalAccel * KF5::KCMUtils * KF5::I18n * KF5::XmlGui * KF5::WindowSystem * KF5::DBusAddons * KF5::Notifications * KF5::KIOWidgets * KF5::Crash Even if we consider that some are probably not needed it would at least become tier2. Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Do you mean that global accelerators created with KGlobalAccel have never worked on apps when run under gnome? I said that I don't know whether they work and how they work in case of conflict. The way how kglobalaccel works I consider it as very likely that they would not work. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put kglobalacceld?
El Divendres, 4 d'abril de 2014, a les 15:41:07, Martin Gräßlin va escriure: Hi, similar as to what we already have with DrKonqi moving kglobalacceld from kde- runtime into the globalaccel framework would significantly raise the tier and dependencies. At the moment KGlobalAccel is a tier1 framework. The runtime component though depends on: * KF5::GlobalAccel * KF5::KCMUtils * KF5::I18n * KF5::XmlGui * KF5::WindowSystem * KF5::DBusAddons * KF5::Notifications * KF5::KIOWidgets * KF5::Crash Even if we consider that some are probably not needed it would at least become tier2. Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Do you mean that global accelerators created with KGlobalAccel have never worked on apps when run under gnome? Cheers, Albert Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. Opinions? Cheers Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Where to put kglobalacceld?
Hi, similar as to what we already have with DrKonqi moving kglobalacceld from kde- runtime into the globalaccel framework would significantly raise the tier and dependencies. At the moment KGlobalAccel is a tier1 framework. The runtime component though depends on: * KF5::GlobalAccel * KF5::KCMUtils * KF5::I18n * KF5::XmlGui * KF5::WindowSystem * KF5::DBusAddons * KF5::Notifications * KF5::KIOWidgets * KF5::Crash Even if we consider that some are probably not needed it would at least become tier2. Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. Opinions? Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put kglobalacceld?
On Fri, Apr 4, 2014 at 3:41 PM, Martin Gräßlin mgraess...@kde.org wrote: Hi, similar as to what we already have with DrKonqi moving kglobalacceld from kde- runtime into the globalaccel framework would significantly raise the tier and dependencies. At the moment KGlobalAccel is a tier1 framework. The runtime component though depends on: * KF5::GlobalAccel * KF5::KCMUtils * KF5::I18n * KF5::XmlGui * KF5::WindowSystem * KF5::DBusAddons * KF5::Notifications * KF5::KIOWidgets * KF5::Crash Even if we consider that some are probably not needed it would at least become tier2. Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. Opinions? Cheers Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel In that case, I'd suggest moving it to plasma-workspace, but then we'll have to make sure to make it explicit that KGlobalAccel is not a portable framework, rendering components depending on it not portable (with emphasis on KXmlGui) to platforms not supported by Plasma (or KWin). Not having a functional KGlobalAccel on Gnome sounds quite a regression to me though... Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Where to put kglobalacceld?
On Friday 04 April 2014 16:06:32 Aleix Pol wrote: On Fri, Apr 4, 2014 at 3:41 PM, Martin Gräßlin mgraess...@kde.org wrote: Hi, similar as to what we already have with DrKonqi moving kglobalacceld from kde- runtime into the globalaccel framework would significantly raise the tier and dependencies. At the moment KGlobalAccel is a tier1 framework. The runtime component though depends on: * KF5::GlobalAccel * KF5::KCMUtils * KF5::I18n * KF5::XmlGui * KF5::WindowSystem * KF5::DBusAddons * KF5::Notifications * KF5::KIOWidgets * KF5::Crash Even if we consider that some are probably not needed it would at least become tier2. Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. Opinions? Cheers Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel In that case, I'd suggest moving it to plasma-workspace, but then we'll have to make sure to make it explicit that KGlobalAccel is not a portable framework, rendering components depending on it not portable (with emphasis on KXmlGui) to platforms not supported by Plasma (or KWin). Not having a functional KGlobalAccel on Gnome sounds quite a regression to me though... it already says so in http://community.kde.org/Frameworks/List I honestly have no idea whether it works on other X11 desktops and how it behaves in case of conflicting global shortcuts by other desktops. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put kglobalacceld?
Hello, On Friday 04 April 2014 16:10:23 Martin Gräßlin wrote: In that case, I'd suggest moving it to plasma-workspace, but then we'll have to make sure to make it explicit that KGlobalAccel is not a portable framework, rendering components depending on it not portable (with emphasis on KXmlGui) to platforms not supported by Plasma (or KWin). As a matter of fact we should probably make KXmlGui be able to treat KGlobalAccel as optional if the daemon isn't available at runtime. Not having a functional KGlobalAccel on Gnome sounds quite a regression to me though... it already says so in http://community.kde.org/Frameworks/List I honestly have no idea whether it works on other X11 desktops and how it behaves in case of conflicting global shortcuts by other desktops. Yes, it was likely not working properly in such cases anyway. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Where to put kglobalacceld?
2014-04-04 11:10 GMT-03:00 Martin Gräßlin mgraess...@kde.org: On Friday 04 April 2014 16:06:32 Aleix Pol wrote: On Fri, Apr 4, 2014 at 3:41 PM, Martin Gräßlin mgraess...@kde.org wrote: Hi, similar as to what we already have with DrKonqi moving kglobalacceld from kde- runtime into the globalaccel framework would significantly raise the tier and dependencies. At the moment KGlobalAccel is a tier1 framework. The runtime component though depends on: * KF5::GlobalAccel * KF5::KCMUtils * KF5::I18n * KF5::XmlGui * KF5::WindowSystem * KF5::DBusAddons * KF5::Notifications * KF5::KIOWidgets * KF5::Crash Even if we consider that some are probably not needed it would at least become tier2. Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. Opinions? Cheers Martin In that case, I'd suggest moving it to plasma-workspace, but then we'll have to make sure to make it explicit that KGlobalAccel is not a portable framework, rendering components depending on it not portable (with emphasis on KXmlGui) to platforms not supported by Plasma (or KWin). Not having a functional KGlobalAccel on Gnome sounds quite a regression to me though... it already says so in http://community.kde.org/Frameworks/List I honestly have no idea whether it works on other X11 desktops and how it behaves in case of conflicting global shortcuts by other desktops. KDE4 on Windows runs a kglobalaccel.exe. I'd welcome getting rid of the daemon on Windows, it should be possible to implement the functionality in-process. I don't know if the global accelerator functionality currently works on Windows, with or without the daemon. -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
