From kde-core-devel  Wed Nov 02 20:05:17 2011
From: Volker Krause <vkrause () kde ! org>
Date: Wed, 02 Nov 2011 20:05:17 +0000
To: kde-core-devel
Subject: Re: GammaRay - Introspection/Debugging Tool for Qt Applications
Message-Id: <4911893.BZ8ygj8Ma5 () vkpc9>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=132026439318760
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart2284097.6PvoxrIHfm"


--nextPart2284097.6PvoxrIHfm
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On Tuesday 01 November 2011 21:56:53 Peter K=FCmmel wrote:
> On 01.11.2011 08:58, Volker Krause wrote:
> >> I've also tried to attach to console apps without success.
> >> Then I realized that you use the hijacked process to show
> >> the GammaRay mainwindow which is not possible in a
> >> QCoreApplication executable.
> >>=20
> >> So I wonder how difficult it would be to run GammaRay in a
> >> different process? Then an IPC mechanism is needed for all
> >> the information. Would this be fast enough? Do you plan
> >> to add this in future?
> >=20
> > I'd love to have that, for console apps, remote debugging on an emb=
edded
> > system, and for less interference with the debugged process :)
>=20
> Couldn't you reuse some IPC parts from KDAB's canceled test tool ;)

I'd actually need to check how that worked ;)

Two other tools to look at would be the Qt Creator QML debugger and Qt=20=

Inspector (both use custom protocols with QDataStream-based serializati=
on=20
AFAIK).

Another idea that came up for dealing with anything QObject based was t=
o just=20
export those objects to D-Bus. That automatically gives you cross-proce=
ss=20
property/signal/slot introspection (even remotely, the Akonadi remote=20=

debugging server has a D-Bus TCP bridge built in that is also usable st=
and-
alone). Doesn't really help with things like QAbstractItemModel though.=


> > You can probably get a large amount of the features by having some =
kind of
> > network transparent QAbstractItemModel adapter. But some feature ne=
ed
> > direct memory access, like rendering of a second QGraphicsScene vie=
w,
> > unless you want to send pixmaps over IPC.
>=20
> Sounds manageable.
>=20
> >> Is there a single point where all the information of
> >> the target process goes through or is it all over the place?
> >> I assume at least each plugin pulls information by itself.
> >=20
> > Most of it goes through probe.cpp and the object models provided by=
 it,
> > however all the plug-ins access raw QObject pointers they retrieve =
from
> > those models (and thus are bound to the same process).
>=20
> OK, but when the plugins also support ipc, it should be possible to r=
emote
> debug/monitor for instance a state machine.

right, I think it's definitely doable, it's just quite a bit of work :)=


regards
Volker

--nextPart2284097.6PvoxrIHfm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iD8DBQBOsaKAf5bM1k0S0kcRAgOdAJ4hWemHNDzEr6n5oP0QwfRqhX44sQCfVIup
3BF3bpQEMzO7MoYfLthi6Fs=
=niU1
-----END PGP SIGNATURE-----

--nextPart2284097.6PvoxrIHfm--