Run Configurations API and GUI

[Vladimir Prus]

On Saturday 04 April 2009 18:17:00 Andreas Pakulat wrote:
> 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).

Right. It becomes even more important for unusual cases -- say, there's
10 different ways to debug an embedded program. So I think that

- There should be a way for user to select which launchers a given
configuration uses for any mode.
- UI pages are specific for launchers
- Said UI pages try to reuse information. So, if you have there are
two launchers that use GDB internally but differ in something else,
then they probably should store GDB binary name in one place.

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

Well, Eclipse launch framework has major design issue in that it mixes launch
mode and configuration types. Say, I have C++ native program. I can reasonably
want to

   - run it
   - debug it
   - attach to an already running copy of it
   - examine core file

In Eclipse, run and debug are launch modes, in the Run menu, while
attach and examine core file are configuration launch types. Furthermore,
Eclipse UI is structured in such a way that if you add 3 mode launch modes
(and items in Run menu), then you'll run out of space in Run menu.

This reminds me that I don't really know how implement 'just open this
core' functionality -- should we require that a launch config be created
for this?

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

Yes, something like that.

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

Well, maybe putting new top-level run modes into Run menu is a recipe
for explosion, but putting new run modes somewhere, say a submenu,
is probably needed.

- Volodya