Bugzilla – Full Text Bug Listing
| Summary: | [perspectives] [viewmgmt] Add a sticky perspectives preference. | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Pawel Piech <pawel.1.piech> | ||||||||
| Component: | Debug | Assignee: | Platform-Debug-Inbox <platform-debug-inbox> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | daniel_megert, fchouinard, marc.khouzam, Michael_Rennie, mober.at+eclipse | ||||||||
| Version: | 3.7 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | stalebug | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 192332 [details]
Prototype patch.
We have an issue that this proposal could maybe help with. In the LinuxTools project, there is a Tracing perspective. When in this perspective, the user can start visualizing GDB traces. All the parsing of these traces is done by GDB, and to do that easily, CDT is used to launch a debug session which starts GDB. The problem is that this would automatically cause a switch to the Debug perspective, which we don't want. It seems that by making the Tracing perspective 'sticky', we could solve this issue. Created attachment 192379 [details]
Polished patch.
I cleaned up the patch and added doc changes.
Dani, do you have any objections to adding this feature? Is it too late in 3.7? Thanks, Pawel I'm not quite sure how I feel about this feature. One the one hand it takes an already complex pref page and makes it (arguably) harder to understand, and on the other allows some more flexibility in how perspectives are opened/closed for you without the addition of new launch delegates / modes. Maybe it is just the presentation of the preference that is throwing me off. Had you thought of making this a per launcher / type setting? (In reply to comment #5) > I'm not quite sure how I feel about this feature. One the one hand it takes an > already complex pref page and makes it (arguably) harder to understand, and on > the other allows some more flexibility in how perspectives are opened/closed > for you without the addition of new launch delegates / modes. > Maybe it is just the presentation of the preference that is throwing me off. I agree that the view/perspective activation preferences are a nightmare. I tried to simplify the wording on the page to make it more clear but it's just a lot of concepts. Honestly, we don't see our users venturing into the preference page itself, but rather we want to be able to customize the behavior in our product for the ideal experience. Towards this goal, would an an extension point mechanism be better suited than a preference page? > Had you thought of making this a per launcher / type setting? The use case is that if the user goes to the Debug perspective, he's implicitly choosing the appropriate perspective for debugging. And in this perspective, we will use activities and view auto-open to progressively reveal the features he needs for the type of debugging he's doing. This goes across all launch types. OTOH, we have users who are used to the highly-customized perspectives we've created in the past and they want to keep using them. So getting rid of the existing perspective switch behavior would be detrimental. All in all I'm rather torn about this as well, but it still seems to me like a net positive. (In reply to comment #6) > All in all I'm rather torn about this as well, but it still seems to me like a > net positive. I agree, it sounds like a positive idea, but perhaps we should hold off on adding it until we all agree that 'yes this is what we want it to do'? (In reply to comment #7) > I agree, it sounds like a positive idea, but perhaps we should hold off on > adding it until we all agree that 'yes this is what we want it to do'? Maybe we could try to revamp all the related settings early in 3.8. Then we'd have time to deal with the fallout from the confused users. (In reply to comment #8) > (In reply to comment #7) > > I agree, it sounds like a positive idea, but perhaps we should hold off on > > adding it until we all agree that 'yes this is what we want it to do'? > > Maybe we could try to revamp all the related settings early in 3.8. Then we'd > have time to deal with the fallout from the confused users. Agreed, see also e.g. bug 46336. It seems that the main goal is to allow the product to configure the behavior and not the user, hence it might make more sense to add API and/or an extension point for it as mentioned before. On the other hand, if the goal is to give the power to the user then it might be interesting to introduce the concept of pinning a perspective at the Platform UI level, since perspective switches also happen at other places, e.g. when comparing or synchronizing. NOTE: The UI says "... one of the following sticky perspectives". However, the list contains all perspectives and only the checked ones are considered "stick". Also, I don't like the term "stick" too much as it is too general. Seems that progress stalled. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag. |
Created attachment 192331 [details] Screenshot of the presepctives preference page. I have a request in our product to improve the co-existence of perspective switching debugging worfklow with the view management workflow. In perspective switching workflow, users are moved from their current perspective to the perspective associated with their launch type. In our product we have a couple different debug perspectives defined for differenet types of debugging and some users don't like switching between them. Instead we are trying to define a new simplified perspective where view management is used to reveal controls based on the type of debugging that the user is doing. However, to be backward compatible we still want to users to be switched to the associated perspectives when transitioning from edit/compile activity. Only when user explicitly opens the simplified debug perspective we want the perspective switch to be suppressed. To enable this I would like to define a new preference, which would be a list of sticky perspectives. When user is in one of these perspectives, the perspective manager would NOT switch to the associated perspective. Would anyone else benefit from this? I've prototyped this and it works pretty well. I'm attaching a screenshot of the modified preference page and patch.