Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Support for "target-detach" and "target-disconnect"

How hard would it be to have the platform allow use to override the tooltip
text?  We could then call the button 'detach' for CDT (based on the 
current debug context). 

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pedro Alves
> Sent: April-15-10 2:14 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] Support for "target-detach" and 
> "target-disconnect"
> IMO, we shouldn't worry that much about users getting confused
> by the action getting a new name/string in the IDE to match
> the debug engine.  We're dealing with developers, which one
> assumes to be at least a little bit flexible people.
> In fact, IMO abstracting away too much the debugger below
> instead of exposing it in full power is a step in the
> wrong direction.
> Doesn't the IDE support a console to GDB's command line
> interface?  It's also confusing for an icon not match the
> command one types there, and warnings, errors, notices the
> debugger prints there.  If I click "disconnect" and see
> some warning about "... can't detach foo ... " " .. detaching ..", 
> etc., then that's also not good for consistency.
> Doesn't the IDE forward GDB errors and/or warnings to
> message boxes?  It's also more likely to be more
> confusing to users to have the warnings/errors not
> match the action names than the confusion changing
> the action name would generate.
> What about settings/configuration pages?  For example, 
> GDB has a setting called "set detach-on-fork".  If you expose
> that in the IDE, are you going to rename it to "Disconnect On Fork"?
> Also, user manual for a full product (compile/debug/IDE) whose debug
> solution is built around GDB, is more likely to call "detach" to
> the detach action everywhere, not disconnect.
> Consistency overall, I'd say.
> -- 
> Pedro Alves
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx

Back to the top