new Run-API

Vladimir Prus ghost at cs.msu.su
Wed Apr 15 19:03:40 UTC 2009


On Wednesday 15 April 2009 01:39:25 Andreas Pakulat wrote:
> Hi,
> 
> finally I've found the time to sit down, think this through and at least
> write up the API for the improved run support.
> 
> The runcontroller will provide a way for any plugin to setup its own run
> configuration type. It currently also provides access to the actual run
> configs, but I'm not yet sure wether thats really needed for plugins
> (don't have a usecase atm).
> 
> Each run config type has a list of associated configuration pages, where
> a config page is just a bit of additional API for loading/storing the
> config on top of QWidget (so it can easily be put into any kind of GUI).
> 
> There's also different run modes, currently one for run, debug and
> profile. Those will be associated to the toolbar actions.
> 
> A config type also has a list of "starters" classes, each of which can
> execute a configuration of the given type. Each starter can have one or
> more run modes it supports. This allows a plugin to provide a starter
> that can do normal execution as well as debugging, but also allows for
> plugins to supply additional tools for an existing config type.
> 
> Please have a look at the diff and let me know your opinions, one thing
> I'd like to get some info about: Should IRunConfiguration be really
> exposed to plugins, or should it be internal to shell/ and the pages
> get just a KConfigGroup to read/write their settings.

I'll try to provide more high-level comments tomorrow, but here are some
low-level ones:

1. There's no way to create new launch mode from a plugin.

2. IRunConfigurationStarter.start does not take mode.

3. I think we have established before that list of starters is a property
of launch configuration. That is 'launch configuration type' is *object*
you want to debug -- say, C++ Application. While different ways to start
it can be configured -- if I have C++ Application, then I should be able
to use either GDB, or Intel debugger to debug it. It would be not cool
to introduce separate

	- C++ Application (GDB)
    - C++ Application (IDB)

launch config types. Consequently, the list of starters should be a properly
of launch config, not launch config type. Furthermore, the list of UI pages
also depends on starters, and therefore should be a property of launch
config. 

Now, if the list of starters and UI pages are associated with launch config,
then what does launch config type do? I think it should serve two purposes:

     - Provide a list of starters that in theory can be used with this
       config type. E.g. C++ Application can use GDB and IDB, but cannot
       use PDB (Python debugger)
     - Provide the default list of starters.
	 - Provide some generic pages. Say for C++ Application, we might want
       to specify application name and whether we want console. For PHP
       application we might want to specify some URLs.

How does that sound?

4. You have typo in removeRunConfiugrationStarter

5. Can we use Launch as opposed to Run everywhere, as it's more generic?
And maybe use ILauncher as opposed to IRunConfigurationStarter?

- Volodya








More information about the KDevelop-devel mailing list