Re: Run/Debug profiles

Petr Jiricka wrote:
> Team,
> 
> I would like to ask a question about Run/Debug profiles and perhaps 
> request a change.
> 
> Why are there two groups of profiles - one for Running and one for 
> Debugging ? It seems that in many cases having the same profile for both 
> actions would be sufficient (although I acknowledge that in other cases 
> they may be different - Svata would give me good use cases, I am sure). 

Bad luck :-) However I swallowed the bait and I looked into some other 
IDEs (btw you SHOULD download Eclipse 2.1, their UI matures blazingly 
fast) and found that both IntelliJ and Eclipse 2.1 treat "Run Profiles" 
as things, which can be either run or debugged.

I, too, think (I hope that Hanz forgives me) that "debugging" is a
special kind of "execution". In addition, in the real world, when an
application does not work for particular startup parameters (a.k.a. Run
profile), the developer usually goes to debugger to find why it is so.

So IMHO most straightforward - for the user - would be to either allow
the debugger to "parasite" on profiles it knows or at least to derive
(copy or inherit, I am not clear about consequences here) settings for
debugging from an execution profile. The first option would allow to run
a debugger using Execution profile settings, the other option allows to 
alter settings for debugging purposes specifically.

IntelliJ & Eclipse allow "only" the hooking approach.

> So instead of having two groups, could we just have one group, and each 
> profile could be used either for running or for debugging ?
> 
See above, +1.

> There are cases when a given profile type can be only used for execution 
> or debugging, but not both - this could be solved if we added 
> 'properties" (methods, cookies, whatever...) to the profile, called 
> canUseForRunning() and canUseForDebugging().
> 
Erm - right now a Run profile typically has an ExecCookie implemented on
it. So if I suppose that Java Debugger will hook onto external java exec
profiles, it can - through ProjectEnvironmentProvider interface - add
some DebugCookie to them.
The corresponding UI then may operate on one repository of profiles,
only filtering for the relevant cookies.

This has an advantages of not defining another interface (one is needed
to start the exec/debug process anyway) and does not limit the types of
startup to two (debug/exec) [I still anticipate that profiler plugin
module will be written at some time].

> - The Run menu would only have one item called Run/Debug Profiles
> - The "Profile details" subpanel in the Edit Profiles... panel would 
> have two checkboxes at the bottom: 'Set As Active Profile for Running' 
> and 'Set As Active Profile for Debugging' (instead of just one checkbox, 
> as is currently the case). One of these checkboxes could be disabled if 
> the profile does not support running or debugging.

Best,
-Svata