[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Support for "target-detach" and "target-disconnect"
|
At 11:00 AM 4/15/2010, Marc Khouzam wrote:
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
> Sent: April-15-10 11:55 AM
> To: CDT General developers list.; CDT General developers list.
> Subject: RE: [cdt-dev] Support for "target-detach" and
> "target-disconnect"
>
>
> >I might be confused about the final proposal, so let's recap.
> >You suggest
> >1- make the disconnect button actually call 'disconnect' in GDB
> > for any debug context selected
> >2- add a view menu called 'detach' which calls GDB's 'detach'
> >
> >If that is the case, for multi-process, we'll have the DSF-GDB
> >'connect' button on the toolbar which will be used to attach to
> >a new process, but the user will need to go to the view menu
> >to 'detach', and if they press the 'disconnect', (which they
> will :-))
> >they would disconnect the entire debug session.
> >
> >I would think we need a better solution.
> >
> >But maybe I mis-understood?
>
> Marc, your choice of words might have revealed a possible
> improvement. What if the DSF-GDB button currently called 'connect'
> were to be renamed to 'attach'?
At a minimum.
But having 'attach' in the toolbar but not 'detach' (anymore),
doesn't seem right.
If the current 'disconnect' button stops calling 'detach' for
processes/threads/frames, then we should move 'connect' to
the view menu as well.
But I would find it limiting for the user not to have the ability
to attach/detach from processes using the toolbar. I think
(although I could be wrong) that for multi-process, it can be
an operation that should be easily available.
That is a long-standing issue with the Debug view--one we've
struggled with, too. Our commercial has all sorts of multi-core
variants of the standard run control actions, and there's just no way
to house it all in the toolbar. So we've made some difficult
decisions on what makes the cut and what doesn't. But of course it's
all based on assuming what customers are going to do often vs what
they do infrequently, and that can vary widely from one customer to another.
BTW, did you meant the context menu? That's where the overflow of
actions that operate on a selection in the view should go, not the view menu.
John
