new Run-API

[Andreas Pakulat]

On 15.04.09 23:03:40, Vladimir Prus wrote:
> 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.

Well, thats easy, there's a UserRunMode enum value and the methods taking a
run mode will use int instead of the enum. I just left it out for now
because I was sooo tired :)
 
> 2. IRunConfigurationStarter.start does not take mode.

ooops, obviously not intended.

> 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

Yes, I don't see how this relates to the current API. The launch config
type dictates which starters can be used for the type. So you'd have launch
config type "C++ App" and it has 1 starter for "Run" which simply runs
KProcess and 2 starters for "Debug" one is "GDB" the other is "IDB". I
haven't thought about the GUI parts very much yet, I wanted to get the API
straight first.

In the launch config itself the actual starter to be used would be stored,
along with any starter specific options.

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

Well, no IMHO. The "launch config" is an actual instance, i.e. it has a
name for showing in the gui, an associated type and couple of stored
informations (like the actual application, the to-be-used starter, the
starter options, environment variables etc). Due to the starter thats to be
used being a property  of the launch config you can immediately provide the
right list of config pages, the base ones + the ones this starter provides.

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

I thought thats exactly what the API tells you? No? Hmm, I guess I
should've added 
 
> 4. You have typo in removeRunConfiugrationStarter

Ooops.

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

Well, I mostly used "Run" as we already have IRunController and I actually
wanted to avoid the eclipse lingo, but I don't really mind :) Will change
that on the weekend.

I'll try to think a bit how to best show these gui-wise, especially how to
visualize different modes and choosing the starter for a launch config..

Andreas

-- 
Communicate!  It can't make things any worse.