Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Hiding the 'gdb traces' by default?

I like your idea of providing a context-menu or a button in the Debugger Console (GDB instance of it) to make the gdb traces visible.

I'll code something up.


Thanks



From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
Sent: October 19, 2016 8:57 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Hiding the 'gdb traces' by default?
 
OK, I get what you mean now. Yes it is a better user experience, especially if the user does not use "Allocate console". 

I too have not expressed myself properly. What I was recommending for the "Debugger Console" was that be the entry point for making the gdb traces visible or not (i.e. a button/menu item right in that view). At the moment the preference is not very discoverable.

Jonah



~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com
www.kichwacoders.com
Software Consultancy Services



On 18 October 2016 at 21:44, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:

I just pushed a patch you can try:

https://git.eclipse.org/r/83471 

(BTW, you can paste the link directly into the EGerrit dashboard).



From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
Sent: October 18, 2016 4:27 PM

To: CDT General developers list.
Subject: Re: [cdt-dev] Hiding the 'gdb traces' by default?
 

Hi Jonah,


I think I didn't express myself well :-)

My idea was to leave the 'gdb traces' in the platform Console

view, but keep them hidden using a preference.

The current reason I think it is better to have the 'gdb traces'

in the Console view and not the Debugger Console view is

that it allows to look at both 'gdb traces' and GDB Console

at the same time.  If we put the 'gdb traces' in the Debugger

Console, we could only see the 'gdb traces' or the GDB

Console but not both.


So the suggestion I'm making today is to hide the 'gdb traces'

by default, and when the user wants to, they would be shown

in the Console view, as they are today.  But they would be

collecting the traces even when hidden (that's the improvement).


Do you feel hiding them is a better user experience?


P.S. IOConsole.seWaterMarks() can still be used in this scheme.




From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
Sent: October 18, 2016 3:57 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Hiding the 'gdb traces' by default?
 
Hi Marc,

I think that with the new debugger console view you have created, you
have opened up a whole new avenue of improving usability. The gdb
traces is a perfect example. What you suggest is good, and tying the
gdb traces into the new debugger console view is a logical place entry
point to access them.

As for not being able to turn them off, I suspect you are right that
there is no issue in practice. However, changing their visibility
seems orthogonal to whether they are collected. I personally would not
make that part of the change, unless there is a compelling
simplification to the implementation in doing so.

As a footnote, at the moment I believe we rely on the platform console
(via IOConsole.setWaterMarks) functionality to limit the memory usage
of the gdb traces, if we are going to be storing traces more
internally to cdt, we need to ensure we have some limit in place.

HTH
Jonah

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com


On 18 October 2016 at 19:28, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
> Hi,
>
>
> A few years ago it was asked why we enable the 'gdb traces' console by
> default.
>
> https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg24297.html
>
> The discussion ended with the idea that when a problem happens, it is better
> to
>
> have the traces running, instead of having to try to reproduce the problem a
>
> second time, after having enabled the traces.
>
>
> Now that we moved the actual GDB console into its own Debugger Console view,
>
> I started thinking about those 'gdb traces' again.  I do agree that for a
> non-advanced
>
> user, they don't mean anything and just add to the complexity of the Console
> view.
>
>
> One approach that was not explored is to have the 'gdb traces' running all
> the time,
>
> but not _show_ them by default.  So normal users would not see them in the
> Console
>
> view, but if a problem happened, they could be made visible with all the
> traces
>
> already collected.
>
>
> I think that would address both requirements (having the traces as soon as a
> problem
>
> happens, while not showing them by default).
>
>
> Do others agree this would be an improvement?
>
>
> If we go with such a solution, it is important to note that it implies that
> 'gdb traces'
>
> will be collected all the time, with no option to turn them off.  I
> personally don't see
>
> that as a problem.  They have be on by default for many years without any
> issues.
>
>
> Thanks for your input.
>
>
> Marc
>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
Mailing list: cdt-dev CDT General developers list. About cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Mailing list: cdt-dev CDT General developers list. About cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top