Run Configurations API and GUI

[Vladimir Prus]

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:

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'. 

I think this model will work nice for regular things, but might have problems
with "irregular" launches. E.g. you have mentioned starting a webbrowser. It
does not really fit here. But notice how Eclipse does it -- it as an 'external tool'
mechanism. It is completely independent from regular launch framework -- it's just
something that can be executed and has generally custom GUI. I guess we can use
this approach too.

Another example is all the various ways valgrind can be run with. I guess calltree
can be thought of as 'profile' launch. For valgrind, we can introduce generic 'check for bugs'
launch mode. Alternatively, the "Run" menu might have some generic top-level launch
modes followed by "Custom" submenu that has the exact list of all possible launchers,
like "Memcheck", "Massif" and what not.

Hope this makes sense...

- Volodya