Runtime data visualization plugin architecture

[Manoj Rajagopalan]

Hi all,

   Forking this from the thread "FOSDEM Idea: Visualize runtime data (e.g. 
during debugging)"

   I have developed a working visualizer with the 3.5 branch on my personal 
machines and am interested in porting this to 4.x. Aleix Pol mentioned the 
playground and a plugin model. I have a few questions:


1. In KDev 3.5 the code had to be tightly bound to the GDB plugin - it emitted 
GDBMI instructions to extract memory dump information from gdb. Does KDev4 
have a debugger abstraction which hides details like GDBMI and provides 
access through an easier, debugger-independent API abstraction?

2. Qwt and QwtPlot3D are dependencies for plotting graphs. If the plugin is 
tightly bound and invasive, as in 3.5, then these libraries will have to be 
included somehow:
   (a) include their code within the KDev4 source tree someplace and build as 
subproject,
   (b) tear out only the relevant code and create subproject (too much work)
   (c) specify them as explicit KDev4 dependencies (IMHO unacceptable)
   (d) <the ideal, elegant solution, which is ...? >

  2.Q: What would an acceptable alternative be?

3. If the plugin is loosely-bound (can be (un)loaded on demand) then it can be 
shipped separately with explicit external dependences on the Qwt* libs and 
packaging can take care of this.

   3.Q: does the KDev4 architecture permit this?

4. The playgound mentioned above - is it for 3.5 branch or 4.x or both?

5. The 3.5 gdb plugin was specific to cpp. Other language directories like 
fortran, pascal etc. had no debugger subdirs or files so I am guessing no 
debugger existed for them (I see something for ruby). 

   5.Q1: Does the 4.x trunk (intend to) support debuggers for languages other 
than c/c++?

   5.Q2: If so, will a visualization plugin be useful? I know python is used 
for scientific computing - not sure about other languages.

   5.Q3:  If(5.Q2), then how should a visualization plugin be architected so 
that it remains extensible to a variety of languages with minimal extra 
effort?

   5.Q4:  In practice, would it be better to architect the plugin for 
languages supported specifically by GDB, beginning with C/C++, and then get 
to re-engineering much later? What is the expectation of the kdevelop-devel 
community on this? (GDB supports C, C++, Objective-C, Fortran, Java, Pascal, 
assembly, Modula-2, and Ada)

  Replies/comments anyone?


-- Manoj