[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Hiding the 'gdb traces' by default?
|
Ok, so let's start off with just the preference, by default not showing the 'gdb traces', but having them recording all the time.
We'll adapt if we find it is insufficient.
Thanks for the input.
________________________________________
From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
Sent: October 21, 2016 11:30
To: CDT General developers list.
Subject: Re: [cdt-dev] Hiding the 'gdb traces' by default?
On further contemplation, not having better discoverability is fine for this. The power users will find it anyway, and they are the only ones that understand what gdbtraces means.
Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com<http://www.kichwacoders.com>
On 21 October 2016 at 13:18, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx<mailto:marc.khouzam@xxxxxxxxxxxx>> wrote:
I guess what I'm saying is that putting the menu even in the debugger console is not that great. That menu would show the gdb traces in another view (the platform console view) which seems like an unrelated area compared to where the menu is placed.
Is that still better than not having a menu at all and relying on the preferences page only?
Marc
________________________________
From: Doug Schaefer <dschaefer@xxxxxxxxxxxxxx<mailto:dschaefer@xxxxxxxxxxxxxx>>
Sent: Oct 19, 2016 21:45
To: CDT General developers list.
Subject: Re: [cdt-dev] Hiding the 'gdb traces' by default?
IMHO, having it in the context menu for the Debugger Console is pretty hidden since people won’t expect a menu to be there. What else is in it?
I’m not sure there is a place where it makes more sense. Again, think of the user, just don’t put it in a random spot. Very few people are going to invoke it, but make sure few people outside that group have to try and understand what it means.
Doug.
From: <cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>> on behalf of Marc Khouzam <marc.khouzam@xxxxxxxxxxxx<mailto:marc.khouzam@xxxxxxxxxxxx>>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>>
Date: Wednesday, October 19, 2016 at 9:24 PM
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>>
Subject: Re: [cdt-dev] Hiding the 'gdb traces' by default?
Agreed that a button would be too much.
But I'm now worried about a context-menu in the Debugger Console view. Such a menu would open the gdb traces in the platform console view, and it seems confusing to me that a menu in one console view would require the user to look for traces in another console view.
There is no real reason the menu must be in the Debugger Console. We actually could add it elsewhere if we feel it's important. For example it could be an advanced menu in the Debug view.
But the other point is that such a menu is not about quick access, as someone will either not turn the gdb traces on, or will turn them on once and leave them on. So it's only about discoverability and I'm thinking we are falling back to a context-menu in such cases simply because we don't have a more adequate solution for discoverability.
So I'm leaning towards not putting the menu. But I'd like to see what others think.
Marc
________________________________
From: Doug Schaefer <dschaefer@xxxxxxxxxxxxxx<mailto:dschaefer@xxxxxxxxxxxxxx>>
Sent: Oct 19, 2016 10:58
To: CDT General developers list.
Subject: Re: [cdt-dev] Hiding the 'gdb traces' by default?
I’m glad you guys brought this up. I don’t think any user would ever want to see the gdb traces.
At the very least it rounds to zero versus the number of users we have. So making this hidden by default seems to me to be the right thing to do.
IMHO, adding a button actually makes it more visible than it is now (did I ever mention I hate toolbar buttons :), this is one example why, it makes things always visible). A menu on the debugger console would be fine.
Doug.
From: <cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>> on behalf of Marc Khouzam <marc.khouzam@xxxxxxxxxxxx<mailto:marc.khouzam@xxxxxxxxxxxx>>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>>
Date: Wednesday, October 19, 2016 at 10:03 AM
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>>
Subject: 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<mailto:cdt-dev-bounces@xxxxxxxxxxx> <cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>> on behalf of Jonah Graham <jonah@xxxxxxxxxxxxxxxx<mailto: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<http://www.kichwacoders.com>
[X]<http://www.kichwacoders.com/>
Eclipse for Embedded and Scientific Tools<http://www.kichwacoders.com/>
www.kichwacoders.com<http://www.kichwacoders.com>
Software Consultancy Services
On 18 October 2016 at 21:44, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx<mailto: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<mailto:cdt-dev-bounces@xxxxxxxxxxx> <cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>> on behalf of Marc Khouzam <marc.khouzam@xxxxxxxxxxxx<mailto: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<mailto:cdt-dev-bounces@xxxxxxxxxxx> <cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>> on behalf of Jonah Graham <jonah@xxxxxxxxxxxxxxxx<mailto: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<http://www.kichwacoders.com>
On 18 October 2016 at 19:28, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx<mailto: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<mailto: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
cdt-dev Mailing List Info Page<https://dev.eclipse.org/mailman/listinfo/cdt-dev>
dev.eclipse.org<http://dev.eclipse.org>
Mailing list: cdt-dev CDT General developers list. About cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx<mailto: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
cdt-dev Mailing List Info Page<https://dev.eclipse.org/mailman/listinfo/cdt-dev>
dev.eclipse.org<http://dev.eclipse.org>
Mailing list: cdt-dev CDT General developers list. About cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx<mailto: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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx<mailto: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
