Re: [ANNOUNCE] GammaRay 2.1.0
On Fri, Jun 27, 2014 at 6:08 PM, Allen Winter wrote: > > Announcing GammaRay 2.1.0 > Now with the much requested support for QtQuick 2! > > Highlights of this Release: > === > * Aggregated property view combining static, dynamic and non-QObject > property views. > * Qt5Qml/Qt5Quick support > * Probe ABI auto-detection on Linux, Mac and Windows. > * Support to navigate to objects that are property values. > * Plug-ins can now add specialized tabs to the property view. > * Support adding and deleting dynamic QObject properties. > * Support for "hidden" plug-ins, ie. plug-ins that only provide type support > but no own tool view. > * Support KDE Frameworks 5 in the KJob tracker plug-in. > * Support for Qt 5.4 object creation/destruction callbacks. > * Improved connection view, and support for viewing connections in Qt5 > applications. > > The source code can be found on GitHub at: > https://github.com/KDAB/GammaRay > > Tarballs and zipballs for v2.1.0 are available from: > https://github.com/KDAB/GammaRay/tags (see the v2.1.0 tag) > > Prebuilt (against Qt4) packages for some popular Linux distributions can be > found at: > https://build.opensuse.org/project/repositories/isv:KDAB > > [I may try to provide Qt5-built versions for some of the modern Linux distros > where Qt5 is available. > Let me know if you're interested in that.] > > > GammaRay is a tool to poke around in a Qt-application and also to manipulate > the application to some extent. GammaRay uses various DLL injection > techniques to hook into an application at runtime and provide access to a > lot of interesting information. > > For more information about GammaRay, please visit > http://www.kdab.com/gammaray GammaRay is a tool so awesome to help debugging Qt applications that it should go together with the Qt Package :) > -- > Allen Winter | allen.win...@kdab.com | Software Engineer > KDAB (USA), LLC, a KDAB Group company > Tel. USA +1-866-777-KDAB(5322) ext3, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Should KDED4 run all the time?
On 2014-06-28, Ian Wadham wrote: > Hi guys, > > When fixing some bugs in the KCrash-DrKonqi sequence on Apple OS X, > I have come to a point where Dr Konqi attempts to call kded4, using DBus, > and issues a message "Failed to communicate with kded. Make sure it is > running." In the kdelibs4.x-age, yes. kded should be running all the time no matter what. Unfortunately, it isn't refcounting its users so it is running like forever. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Should KDED4 run all the time?
Hi Sune, Thanks for replying, Sune. On 30/06/2014, at 11:37 PM, Sune Vuorela wrote: > On 2014-06-28, Ian Wadham wrote: >> When fixing some bugs in the KCrash-DrKonqi sequence on Apple OS X, >> I have come to a point where Dr Konqi attempts to call kded4, using DBus, >> and issues a message "Failed to communicate with kded. Make sure it is >> running." > > In the kdelibs4.x-age, yes. kded should be running all the time no matter > what. In Linux and a KDE desktop manager, that is fine: kded4 is part of the structure of a KDE desktop manager. But in Apple OS X (or other desktop managers), that should not be a requirement, if KDE is to be truly portable. Other desktop managers have their own ways of handling directory and file changes, battery level updates, device mounts, software update registration or whatever. So maybe kded4 is not really needed at all on such platforms. In particular, the absence of kded4 should not prevent a user from reporting a crash in a KDE application on Apple OS X or any other desktop manager, should it? I don't think *anything* should prevent that… :-) I do not think it is reasonable to ask the MacPorts developers to include kded4 in startup procedures for every user, on the off chance that he or she will use a KDE app sometime and that app will crash. So I will proceed to patch around the requirement for kded4 in Dr Konqi in Apple OS X, unless someone has a better idea or can point out some more frequent and vital need for kded4 in a non-KDE desktop manager. > Unfortunately, it isn't refcounting its users so it is running like forever. Cheers, Ian W. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
