Bugzilla – Full Text Bug Listing
| Summary: | [UI] Discovery view should be able to open the properties view | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Wim Jongman <wim.jongman> | ||||
| Component: | ecf.ui | Assignee: | Wim Jongman <wim.jongman> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | bugs.eclipse.org | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Wim Jongman
We should not clutter the context menu too much. What might work though, is to add a "Show in" context menu (like e.g. the package explorer) that allows to add sub items. Apart from three disabled menu items (Go Home, Go Back and Go Into), the context menu does not show anything when a IServiceInfo object is selected in the Service Discovery view so cluttering is hardly an issue. EMF uses the "Show Properties View" pattern on the top level because, like the Discovery View, it depends heavily on that view. Is it likely that there will be more views where the IServiceInfo object can be viewed in, at least in the short term? If not then the clutter will be just the same and require additional mouseclicks. I like the "Show In" pattern but it is confusing if you see it for the first time. Therefore, I suggest to add the "Show Properties View" on the context menu and move it to the "Show In" if more views can react on the object. (In reply to comment #2) > Apart from three disabled menu items (Go Home, Go Back and Go Into), the > context menu does not show anything when a IServiceInfo object is selected in > the Service Discovery view so cluttering is hardly an issue. We don't know what our consumers add to the context menu. E.g. if a more specific EMF model is registered for a service type, there might be numerous context menu items available. > EMF uses the "Show Properties View" pattern on the top level because, like the > Discovery View, it depends heavily on that view. The discovery view does not depend on the properties view. > Is it likely that there will be more views where the IServiceInfo object can be > viewed in, at least in the short term? If not then the clutter will be just the > same and require additional mouseclicks. I like the "Show In" pattern but it is > confusing if you see it for the first time. > > Therefore, I suggest to add the "Show Properties View" on the context menu and > move it to the "Show In" if more views can react on the object. "Show In" is a known concept in Eclipse-land. Changing to "Show In" later is IMO even more confusing for users. > We don't know what our consumers add to the context menu. E.g. if a more specific EMF > model is registered for a service type, there might be numerous context menu items available. Even if this is the case, IMO the "Show Properties View" is still considered a first class citizen on the context menu. If the users wants to add many items to the context menu, let him sort out cluttering. >The discovery view does not depend on the properties view. That is a discussion on how you define "depends". Yes: the Service Discovery view depends on the Properties view to show detail information. Or is there another way? No: the Service Discovery view can live without the Properties view so it does not depend on it. > "Show In" is a known concept in Eclipse-land. Changing to "Show In" later is IMO even more confusing for users. That's a good point. Still I don't like the idea to make a sub menu only to avoid cluttering on an otherwise empty menu. Implemented "Show In". Pushed to master. Created attachment 185844 [details]
mylyn/context/zip
Fixed. |