Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Removing "Connect" from the Debug view's toolbar

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
> Sent: Thursday, August 30, 2012 2:05 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Removing "Connect" from the Debug 
> view's toolbar
> 
> On 30/08/2012 1:47 PM, Marc Khouzam wrote:
> > I think it would be nice to have a cleaner handling of these
> > different debugging situations.  I'm not sure adding yet another
> > launch configuration type is the best way though.
> 
> This is a special case, the set of the launch configuration tabs is 
> different, no "Main" tab, for instance.

It would be a simpler launch you are right.  Simpler is better,
although adding a new launch itself is not simpler.
Maybe it is time to discuss a new approach and see if it is
more user friendly.

With GDB we can now do many more things in the same
debug session: e.g., starting one or more processes, 
attaching to one or more processes, detaching, terminating.
And we support all this _during_ a session using prompts.

Imagine, and I'm just writing as I'm thinking, 
a "Debug >" menu with submenus "Local session" and "Remote session".
If the user chooses "Debug->Remote Session" we prompt for IP and port
and then launch a remote-attach session.  The user can then
attach or start a process, as well as examine the target.
Similarly "Debug->Local Session" would immediately launch a GDB 
without a process being debugged.  The user can then start or
attach to processes using our buttons.

This would be a very simple layer on top of the launch layer but
it would allow users to be able to avoid the entire launch UI.
No need to specify a project, a binary or anything of the sort.
Just two-click and debugging starts, followed by choosing what
to debug.

WDYT?

> > But I've never had feedback about that so I don't know how 
> users perceive this case.
> 
> I suspect most of the users simply don't know about this 
> functionality :-) .

There isn't much you can do without a process at this time,
so I'm sure you are right.  If the OSResources view proves
useful, they may notice this functionality more.

Marc

Back to the top