Suggestion: create an own framework for KGlobalAccel
Hi, at the moment KGlobalAccel is part of XmlGui which I consider semantically wrong. Global shortcuts have nothing to do with XmlGui and there are quite some examples for applications which need global shortcuts but do not use xml gui (e.g. everything in the desktop shell). My suggestion is to move the following source files into an own framework: * kglobalaccel.cpp * kglobalaccel.h * kglobalaccel_p.h * kglobalshortcutinfo.cpp * kglobalshortcutinfo.h * kglobalshortcutinfo_dbus.cpp * kglobalshortcutinfo_p.h * org.kde.kglobalaccel.Component.xml * org.kde.KGlobalAccel.xml From checking the source files this would become a tier1 framework as the dependencies are: * QtCore * QtDBus * QtWidgets * QtX11Extras Opinions? Cheers Martin P.S. I blame Aurélien and his diagrams for this proposal. It made me look into the dependencies of KWin and I had a wtf why are we linking sonnet? moment and looked into what we used of XmlGui. 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: Suggestion: create an own framework for KGlobalAccel
El Diumenge, 8 de desembre de 2013, a les 10:16:36, Martin Graesslin va escriure: Hi, at the moment KGlobalAccel is part of XmlGui which I consider semantically wrong. Global shortcuts have nothing to do with XmlGui and there are quite some examples for applications which need global shortcuts but do not use xml gui (e.g. everything in the desktop shell). My suggestion is to move the following source files into an own framework: * kglobalaccel.cpp * kglobalaccel.h * kglobalaccel_p.h * kglobalshortcutinfo.cpp * kglobalshortcutinfo.h * kglobalshortcutinfo_dbus.cpp * kglobalshortcutinfo_p.h * org.kde.kglobalaccel.Component.xml * org.kde.KGlobalAccel.xml From checking the source files this would become a tier1 framework as the dependencies are: * QtCore * QtDBus * QtWidgets * QtX11Extras Opinions? Not an oposition but... Is there no other tier1 framework where it would fit logically and dependency wise? Sometimes I have the fear we might be splitting a bit too much (which can result in nightmare for release and package people amonsght otther stuff). Cheers, Albert Cheers Martin P.S. I blame Aurélien and his diagrams for this proposal. It made me look into the dependencies of KWin and I had a wtf why are we linking sonnet? moment and looked into what we used of XmlGui. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Suggestion: create an own framework for KGlobalAccel
On Sunday 08 December 2013 10:16:36 Martin Graesslin wrote: Hi, at the moment KGlobalAccel is part of XmlGui which I consider semantically wrong. Global shortcuts have nothing to do with XmlGui and there are quite some examples for applications which need global shortcuts but do not use xml gui (e.g. everything in the desktop shell). My suggestion is to move the following source files into an own framework: * kglobalaccel.cpp * kglobalaccel.h * kglobalaccel_p.h * kglobalshortcutinfo.cpp * kglobalshortcutinfo.h * kglobalshortcutinfo_dbus.cpp * kglobalshortcutinfo_p.h * org.kde.kglobalaccel.Component.xml * org.kde.KGlobalAccel.xml From checking the source files this would become a tier1 framework as the dependencies are: * QtCore * QtDBus * QtWidgets * QtX11Extras Opinions? It ended up in XmlGui because otherwise we would have a framework with a just a pair of public classes. Now I see where you come from from kwin point of view, so let's split it out after all. Now the trick is that we're about to split (pending emptying the patch queue), so if you want it please make it happen in the next couple of days. 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: Suggestion: create an own framework for KGlobalAccel
On Sunday 08 December 2013 18:44:59 Martin Graesslin wrote: On Sunday 08 December 2013 18:04:45 Albert Astals Cid wrote: El Diumenge, 8 de desembre de 2013, a les 10:16:36, Martin Graesslin va escriure: Hi, at the moment KGlobalAccel is part of XmlGui which I consider semantically wrong. Global shortcuts have nothing to do with XmlGui and there are quite some examples for applications which need global shortcuts but do not use xml gui (e.g. everything in the desktop shell). My suggestion is to move the following source files into an own framework: * kglobalaccel.cpp * kglobalaccel.h * kglobalaccel_p.h * kglobalshortcutinfo.cpp * kglobalshortcutinfo.h * kglobalshortcutinfo_dbus.cpp * kglobalshortcutinfo_p.h * org.kde.kglobalaccel.Component.xml * org.kde.KGlobalAccel.xml From checking the source files this would become a tier1 framework as the dependencies are: * QtCore * QtDBus * QtWidgets * QtX11Extras Opinions? Not an oposition but... Is there no other tier1 framework where it would fit logically and dependency wise? Probably Kevin or David can better comment on it. For me the only somewhat fitting framework would be KWidgetsAddons, but I don't know whether it would be OK to have more dependencies in that framework. WidgetsAddons only depends on Widgets, but GlobalAccel also needs DBus and X11Extras. KWidgetsAddons doesn't fit indeed. It has to keep depending on QtWidgets only. Cheers. -- 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
