| [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----- > 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 |