2013/11/22 David Faure <fa...@kde.org>: > On Wednesday 13 November 2013 07:22:18 Martin Gräßlin wrote: >> Hi, >> >> I'm currently trying to port kglobalaccel in kde-runtime to frameworks. I'm >> facing an issue in the file globalshortcut.cpp: it tries to access the >> private header of KGlobalShortcutInfo to create a custom >> KGlobalShortcutInfo object[1]. Now this looks obviously wrong and doesn't >> work as the private header doesn't get installed any more. >> >> KGlobalShortcutInfo on the other hand only provides a default ctor and read- >> only properties. So I cannot just create a KGlobalShortcutInfo and set the >> properties. I assume that this has been done on purpose to make it non- >> constructable. Even more the KGlobalShortcutInfo is friended with the >> GlobalShortcut which tries to access the private. >> >> Any suggestions on what to do here? > > The daemon should move into the same framework as the library code > (which happens to be xmlgui). > It was already decided that this is what would happen to runtime daemons, and > in addition it solves the dependency on private headers.
Why is the daemon needed? Why can't global shortcuts handling be done in-process by the library? -- Nicolás _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
