Run Configurations API and GUI

[Andreas Pakulat]

On 04.04.09 17:29:39, Vladimir Prus wrote:
> On Saturday 04 April 2009 17:05:21 Andreas Pakulat wrote:
> > Hi,
> > 
> > as I said I'm starting on run configs (unfortunately slower than I
> > expected) framework. Right now I'm a little stuck as to how to best
> > integrate support for debuggers/memory-checkers/profiling tools into all
> > this.
> > 
> > My current API allows to register a config-type with the platform, the
> > type has exactly 1 method (well also a name) which creates a kjob that
> > will execute a given run config (see the attached headers). A run
> > configuration will reference its type and basically contains a
> > kconfiggroup which can be used by the GUI widgets to store settings and
> > which is used then by the type's createRunJob method to read out the
> > settings needed.
> > 
> > The gui part is currently a list of factories, that can create special
> > QWidget subclasses, associated to a config type.
> > 
> > This works perfectly to supply a custom method of running something (say
> > starting a webbrowser on a remote url). However it completely breaks
> > down when one wants to use the same configuration, but for a
> > debugger/memchecker/... 
> > 
> > The problem is that those would need to supply their own config type to
> > be able to override the createRunJob method. That in turn means that
> > you'd possibly have two configs in the GUI, one for running and another
> > for debugging.
> 
> Well, why two configs? I think the design model should be something like this:

Hmm, I guess half-finished mail or not, we can still discuss it :)
 
> 1. Launch configuration is basically the *object* you might want to launch.
> There are several types of launch configuration -- for example, native C/C++
> application, or native Python application, or embedded C/C++ application.
> And there are a bunch of specific launch configurations -- with details
> such as binary filled it.
> 
> 2. There's a number of launch modes -- e.g. run, debug,
> profile. There are better be exposed in "Run" menu. 
> 
> 3. Given each launch configuration, all of launch modes can be implemented
> differently. E.g. you'd use gdb to debug C++ program, and you'd use pdb to
> debug python. And say for embedded application, you might want to run it
> either by QEMU simulator, or by downloading to target. So, probably there should
> be abstract 'launchers' that support N launch modes and can be picked for
> a launch configuration.
> 
> 4. There's UI to edit launch configuration. It should have a page to
> select the object been launched, and presumably N tabs as appropriate for
> selected launchers. 
> 
> So, to answer your question above -- I think the UI editing should be done at
> the level of launch configuration, whilst actual running and your createRunJob
> method should be inside 'launcher'. 

Then how do I specify which debugger arguments should be used for a
given launch config. In particular I don't think we should enforce to
always use a certain debugger for a certain config type (i.e. always use
gdb for native compiled apps, or pdb for all python scripts).

At first I actually wanted to avoid the "run modes" that Eclipse has, as
I don't really like them that much. But currently I don't see a way
around them.

So what might work regarding debug/profile would be a way for each
debug/profile plugin to register for X config-types as possible
debugger/profile and the user then gets to choose the debugger and
profiler this way. And obviously the plugin in question will provide
1..n widgets to configure it...

And we probably also want to support extension of run-modes by
plugins...

Andreas

-- 
You have the body of a 19 year old.  Please return it before it gets wrinkled.