Re: KGlobalAccel on ~Linux?
David Faure wrote: > On Friday 13 November 2015 22:04:35 René J. V. Bertin wrote: >> I can imagine that the session dbus doesn't look in /opt/local by default on >> Linux (guess I'll have to look into that) > > Right. Add /opt/local/share to XDG_DATA_DIRS before starting the DBus daemon, > otherwise the dbus service cannot be autostarted. > Well, that didn't help. I waited to react until I had upgraded to Qt 5.5.1 and all 5.16.0 because I saw some mention of better support for Qt 5.5 . Fact is, even with /opt/local/share appended to XDG_DATA_DIRS (now /usr/share:/usr/share/kde-plasma:/usr/local/share/:/usr/share/:/opt/local/share) kglobalacces5 crashes calling `KDBusService service(KDBusService::Unique);` from main(). The actual crash is in QInternal::activateCallbacks(), so I'm not sure what to report and where ... FWIW, with this setting for XDG_DATA_DIRS I now get what I think is appropriate output from kbuildsycoca5, including a message "Menu "applications- kmenuedit.menu" not found". On OS X where the dbus daemon is configured to look in /opt/local/share and where QSP adds that to the relevant standard locations the crash doesn't happen but I keep getting same error message "No such object path '/org/kde/kglobalaccel'" R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KGlobalAccel on ~Linux?
David Faure wrote: > Right. Add /opt/local/share to XDG_DATA_DIRS before starting the DBus daemon, > otherwise the dbus service cannot be autostarted. BTW, I presume this DBus issue has nothing to do with QStandardPaths, but should /opt/local/share show up only in GenericDataLocation or also (or even, rather) in DataLocation? R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KGlobalAccel on ~Linux?
On Friday, November 13, 2015 5:24:51 PM CET René J.V. Bertin wrote: > Hi, > > KDE4's kglobalaccel works just fine on Mac OS X; is there a reason why the > KF5 wouldn't? because nobody ported it to Qt's new native event filter. I would love to see this enabled again for the non Linux platforms. 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: KGlobalAccel on ~Linux?
On Friday, November 13, 2015 5:54:01 PM CET René J. V. Bertin wrote: > Martin Graesslin wrote: > > because nobody ported it to Qt's new native event filter. I would love to > > see this enabled again for the non Linux platforms. > > Hmm, I see. That's something I should look into then, if I find its > functionality is indeed lacking. I know kglobalaccel4 works and gets started > when apparently needed, but I actually do not know what it's used for ... > :) > > After applying my (committed!) patch from KDE4 that ensures the daemon runs > as an "agent", the autotest succeeds (and starts the KDE4 kglobalaccel). > However, starting kglobalaccel5 directly gives > > $ /opt/local/bin/kglobalaccel5 > Could not find drkonqi at /opt/local/lib/libexec/drkonqi > "No such object path '/org/kde/kglobalaccel'" > > which seems like it has nothing to do with a missing backend or however > you'd want to call it. Well it could also mean that kglobalaccel5 directly crashes because it doesn't have a backend and we just don't see the backtrace due to missing drkonqi. Anyway, I'm quite certain that it needs porting as I did the X11 porting :-) 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: KGlobalAccel on ~Linux?
Martin Graesslin wrote: > Well it could also mean that kglobalaccel5 directly crashes because it doesn't > have a backend and we just don't see the backtrace due to missing drkonqi. Running under a debugger should show if it crashes, before kcrash gets a chance to call drkonqi, no? Drkonqi is going to another hurdle; its KDE4 version required serious patching, and I'm not sure the author of those patches is going to be willing to repeat his efforts for KF5... R ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KGlobalAccel on ~Linux?
Martin Graesslin wrote: > because nobody ported it to Qt's new native event filter. I would love to see > this enabled again for the non Linux platforms. Hmm, I see. That's something I should look into then, if I find its functionality is indeed lacking. I know kglobalaccel4 works and gets started when apparently needed, but I actually do not know what it's used for ... :) After applying my (committed!) patch from KDE4 that ensures the daemon runs as an "agent", the autotest succeeds (and starts the KDE4 kglobalaccel). However, starting kglobalaccel5 directly gives $ /opt/local/bin/kglobalaccel5 Could not find drkonqi at /opt/local/lib/libexec/drkonqi "No such object path '/org/kde/kglobalaccel'" which seems like it has nothing to do with a missing backend or however you'd want to call it. R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KGlobalAccel on ~Linux?
On Friday 13 November 2015 22:04:35 René J. V. Bertin wrote: > I can imagine that the session dbus doesn't look in /opt/local by default on > Linux (guess I'll have to look into that) Right. Add /opt/local/share to XDG_DATA_DIRS before starting the DBus daemon, otherwise the dbus service cannot be autostarted. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
