| Re: [cdt-dev] Expression Groups vs Workingsets |
Hi all,
As I've mentioned to Marc at EclipseCon, I've had some customer feedback regarding the proposed _expression_ grouping, and _expression_ workingset features.
In a nutshell,
1. _expression_ Grouping is perceived extremely valuable, to selectively watch subsets of large structures
2. The pattern syntax is preferred over UI for that usecase
a. Ctrl+Space Code Completion in the expressiongroup entryfield would be extremely valuable
3. _expression_ Groups cover a good deal of relevant cases, but are no complete substitute for Workingsets.
Regarding #3, their point is that in one single workspace, they can have very distinct, independent debugging use-cases / scenarios.
For a particular debugging scenario, they would like to import (from another team member) and then activate a respective workingset, which might contain 10 complex expressions for instance.
Such a “scenario workingset” should ideally also include breakpoints (think breakpoint working set, or window working set).
After importing the scenario, it makes sense to keep that imported scenario associated with a name (to delete / deactivate it entirely when needed).
Manually editing / tweaking an _expression_ workingset would mostly be done for the benefit of other team members (when exporting it afterwards), less so for the individual developer’s benefit.
Selecting a couple expressions and groups and then choosing “Save as Workingset” or similar would be a good workflow.
Given that user request, what are your thoughts regarding the workingset patch, https://bugs.eclipse.org/bugs/show_bug.cgi?id=372181 ?
Abeer, have you actually entered feature requests into bugzilla for the items you’ve mentioned on 25-March ?
I’ll try to come to the Multicore Debug call today but can’t promise I’ll make it.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
Sent: Tuesday, March 26, 2013 3:35 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Demo and feedback for _expression_ groups feature
> Hi Marc,
>
> I gave a demo of the _expression_ Groups feature to our team in Pune.
>
> http://wiki.eclipse.org/CDT/User/NewIn82#Enhanced_Expressions
>
> Some feedback and observations are as follows:
Thanks for the feedback. The below points are valuable.
> 1. Allow user to type a tag for the group, e.g:
> "e*x regs" =$e*x
> This tag will be some mnemonic the user understands, and will be helpful to quickly remember what the _expression_ group contains. A tag is useful because the user might group together arbitrary expressions relevant in a particular debugging scenario and then tag the debug scenario.
I agree that having some kind of tag is very valuable here. I'm not sure what is the best way to allow the user to add such a tag though. I like your suggesting of putting the tag directly in-line, since it will require no new UI; however, I am not sure yet how user-friendly this will be.
> 2. On right click popup of a child _expression_ (inside an _expression_ group), disable popup menuitem "Remove" on a child _expression_. This removes the entire group, not the selected child _expression_.
The reason I didn't look into disabling the "Remove" is that it works like that for normal children of expressions. For example, if you create a normal _expression_ that has children (a struct, a class, an array, a ptr), and you right-click on one of the children and choose "Remove", it is the parent that is removed, along with all children. I thought it was more consistent to keep this behavior for _expression_ Groups.
> 3. When the node "Add new _expression_" goes into edit mode, open an infopop which advertises this _expression_ grouping feature.
We definitely need a way to advertise this feature. Are you suggesting a Dialog popup describing this feature and having a "Don't show this message again", when you click on the "Add new _expression_" node? This is an interesting possibility. I think such an approach could even be used for different CDT features. I wonder if there is such a precedent in the CDT.
> 4. On rightclick popup menu of an _expression_, show menuitem "Add to _expression_ Group". This will open a list dialog which lists all existing _expression_ groups + "New". If user selects an existing _expression_ group, edit the group definition string to append "; <_expression_>". If user selects "New", add a new _expression_ group with the definition "<_expression_>;".
This would require new UI. Is having such a dialog much easier to having to manually add the _expression_ to a group? If it makes it clearly more user-friendly, then it makes sense, but if it is just a small improvement for a user, then I we should think about it. Although having this new context menu would be a way to make this grouping feature visible.
With such a context menu entry, I still wonder if having a "New" option makes sense. As you point out, selecting New will create a new _expression_ with definition "<_expression_>;". This is pretty much the same as the previous _expression_, except for the semi-colon. I don't think this adds much value.
> 5. Allow user to drag / drop an _expression_ on a group.
That does sound easier for the user. I'm not sure how hard this would be to implement, but I think it is a good idea.
> 6. To edit an _expression_ group definition which contains multiple complex expressions, it is actually easier to rightclick the group and open Edit Watch _expression_ dialog. Here, it would be great if user can specify expressions one per line, each _expression_ ending in semicolon. If a line ends with semicolon, we should discard the newline char after it and create a single line for the _expression_ group definition.
That sounds great.
Could you open bugs for the features you feel should be pursued?
Thanks for this input.
Marc
_______________________________________________
cdt-dev mailing list