Community
Participate
Working Groups
Created attachment 204781 [details] Screenshot of Wind River's breakpoint properties. CDT uses the standard properties dialog for editing breakpoints. This is nice for compatibility and UI consistency, but has some drawbacks with respect to user experience: 1) The property pages contributed to the dialog are shown in alphabetical order. The "Actions" page is usually shown first due to its alphabetical superiority. Ideally, the "Common" page should be shown by default as it's the one that users are most likely to use. 2) There is no place to paste an icon that would visually indicate to the user what kind of breakpoint he's editing. 3) There is no place to give user feedback as to any issues or validity of the user-specified breakpoint property values. 4) The categories tree selection area is an overkill for breakpoints and makes the dialog unnecessarily large and cluttered. A tabbed dialog may be more appropriate. I'm attaching a screenshot of Wind River's line breakpoint properties dialog. I'd like to see if the CDT community would be interested in adopting some of the above features.
(In reply to comment #0) > Created attachment 204781 [details] > Screenshot of Wind River's breakpoint properties. > > CDT uses the standard properties dialog for editing breakpoints. This is nice > for compatibility and UI consistency, but has some drawbacks with respect to > user experience: > > 1) The property pages contributed to the dialog are shown in alphabetical > order. The "Actions" page is usually shown first due to its alphabetical > superiority. Ideally, the "Common" page should be shown by default as it's the > one that users are most likely to use. +1 > 2) There is no place to paste an icon that would visually indicate to the user > what kind of breakpoint he's editing. What do you have in mind for this? > 3) There is no place to give user feedback as to any issues or validity of the > user-specified breakpoint property values. +1 > 4) The categories tree selection area is an overkill for breakpoints and makes > the dialog unnecessarily large and cluttered. A tabbed dialog may be more > appropriate. I like that too. +1
(In reply to comment #1) Thanks for the positive reply :-) I'm so used to the endless second-guessing that goes on in the platform project that I've grown very conservative in proposing major UI changes. > What do you have in mind for this? I think just a high-res rendering of the breakpoint icon plus overlays would be best. It would be both familiar and educational as to what those overlays are supposed to represent. We may have to pass the hat around to get funding for decent art work though. I'll attach the banner icons I drew for our product, but they could definitely be improved upon.
Created attachment 204965 [details] Line breakpoint banner icon.
Created attachment 204966 [details] Data breakpoint dialog banner icon.
Created attachment 204967 [details] Expression breakpoint dialog banner icon.
Created attachment 204968 [details] Tracepoint dialog banner icon.
(In reply to comment #2) > I'll attach the banner icons I drew for our product, but they could definitely > be improved upon. Very impressive and very imaginative! Much better than what I would have come up with. My only concern is that they are quite different than the little icon used in the other views, which may confuse the user. But this is a minor point that we can discuss once the property page is available for CDT committers to try out.
My major concern is people using this and extending this already using property pages extensions, see comments inline > 1) The property pages contributed to the dialog are shown in alphabetical > order. The "Actions" page is usually shown first due to its alphabetical > superiority. Ideally, the "Common" page should be shown by default as it's the > one that users are most likely to use. Is there a way to change platform to be able to order items? I would assume it would be useful feature > > 2) There is no place to paste an icon that would visually indicate to the user > what kind of breakpoint he's editing. Every property page can have header which can display this information, just make all debug property pages inherit it > > 3) There is no place to give user feedback as to any issues or validity of the > user-specified breakpoint property values. What do you mean? Other property page have validation area, in the header as well > > 4) The categories tree selection area is an overkill for breakpoints and makes > the dialog unnecessarily large and cluttered. A tabbed dialog may be more > appropriate. Personally I don't see much difference, but we can replace property pages dialog itself, by implementing same pages but presented with tab. Would it solve your problems?
(In reply to comment #8) > My major concern is people using this and extending this already using property > pages extensions, see comments inline Thank you Elena for the healthy dose of skepticism :-) Your concern makes perfect sense to me. I should have stated up front that whatever changes we make we'll keep backward API compatibility. Not all CDT APIs are obvious so this may require a lot of polling of the community, but in spirit we should be able to pull it off. This way any extensions contributed through the property page mechanism would still work. > Is there a way to change platform to be able to order items? I would assume > it would be useful feature I'm sure there is, but the UI team is very under-staffed and i've had a very difficult time getting their attention to consider simple fixes, much less features that involve new client APIs. > Every property page can have header which can display this information, just > make all debug property pages inherit it Sure, this could be one way to do it. It'd be more work than having the dialog handle it. It may also seem like a petty feature, but we're looking at polishing a workflow and small things like this can make a difference. > > 3) There is no place to give user feedback as to any issues or validity of the > > user-specified breakpoint property values. > What do you mean? Other property page have validation area, in the header as > well That's true, I should have double checked before I wrote this. In our product we've taken the feedback approach akin to the Launch config dialog, where the tab is decorated with an icon if attention is needed on a given tab. Also we use it to provide informational feedback such as "this breakpoint has been moved". I welcome a debate whether this would actually be better or not, but if we open the possibility to customize the dialog, at least we have the > Personally I don't see much difference, but we can replace property pages > dialog itself, by implementing same pages but presented with tab. Would it > solve your problems? I should have also clarified that this is what we intended. The property-page approach is fine, except I think the standard properties dialog is limiting. Especially as we look to implement the feature to allow user to create a breakpoint using this dialog, in addition to editing an existing breakpoint (as per bug 360588.
I think I need to backpedal a bit on this bug. After some investigation I think the standard breakpoint dialog could satisfy all our requirements, though there's still a question of look and feel. We should implement the following features and gather feedback as we go: 1) The dialog should always open with the "Common" page selected. This can be achieved by using the PreferencesUtil class. 2) Add a graphic corresponding to the breakpoint type to the various Common pages. 3) Add an API for the most pertinent breakpoint status information to be shown in the common page (e.g. error text, etc.).
Somewhat related to this feature is the idea of supported target-specific, and target-specified properties. I thought this was mentioned in these discussions, but I can find where, so at the risk of repeating something that was already said, here it is. Some targets can support breakpoint features that other targets cannot. It would be nice to have a somewhat generic property page that could be changed depending on the target support for breakpoint. In fact, to make this future-proof, the idea is to have the target specify the breakpoint properties it supports and how to set each property. CDT would then simply display the entry for the property and allow the user to set it, forwarding the info to the target. For example, if the target supports a large number of hardware breakpoints, it could have a property tuple ("Use hardware breakpoint", boolean, false) that it would send to the frontend. CDT would then show that to the user and send back to the target any change from the default value. Of course this requires debugger support and target support, but having the generic property page is worth mentioning early. There is an example of this in the EclipseCon presentation below, where TI uses a tree for such an advanced properties page, at slide 18: http://wiki.eclipse.org/images/6/69/MultiCoreDebugEclipseCon11.pdf
(In reply to comment #11) > Some targets can support breakpoint features that other targets cannot. It > would be nice to have a somewhat generic property page that could be changed > depending on the target support for breakpoint. We completely agree. One existing API we could leverage for this is the org.eclipse.cdt.debug.ui.BreakpointUIContribution extension point. It's not currently capable of being target-specific, but we could make it so. Of course there are also target-specific breakpoint properties pages (e.g. Filters), there a target could have any UI it'd like, but from your comments I assume you'd like to have target-spcific settings in the common page, correct?
(In reply to comment #12) > (In reply to comment #11) > > Some targets can support breakpoint features that other targets cannot. It > > would be nice to have a somewhat generic property page that could be changed > > depending on the target support for breakpoint. > > We completely agree. One existing API we could leverage for this is the > org.eclipse.cdt.debug.ui.BreakpointUIContribution extension point. It's not > currently capable of being target-specific, but we could make it so. > > Of course there are also target-specific breakpoint properties pages (e.g. > Filters), there a target could have any UI it'd like, but from your comments I > assume you'd like to have target-spcific settings in the common page, correct? Not necessarily. I was hoping for a way to open the properties page of a breakpoint, and have access to all properties supported by the current target. When there are multiple targets active, I hadn't thought about what to do... This may fit better if we have target-specific breakpoints. Until then, maybe only show the properties that affect the currently selected target? Or gray out properties that were set but that are not supported by the current target? Probably not a trivial feature :-)
