Summary: | [Perspectives] Allow More Programmer Control over Perspective Layout | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Gordon Hirsch <gordon.hirsch> |
Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P5 | CC: | bokowski, frydzewski, gunnar, heath.borders, Kevin_McGuire, kris.klindworth, l2gv15b02, mkwhitacre, rich.main, tom.schindl, tonny.madsen, valere.fedronic |
Version: | 3.2 | Keywords: | helpwanted |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Gordon Hirsch
2006-07-25 11:46:08 EDT
After reading some about the presentations API, I think that item 4 on my list above could be addressed by creating our own presentation factory. Still, it would be nice if there was a simpler way. I noticed that the 3.3 plan included a proposed item for improving workbench usability (bug 154120). I hope the items in this request will be considered. >>1) Prevent the resizing of views. We are creating simple, "selector" views Q: By "selector", do you mean that the view contains a fixed list of items? >>2) Set boundaries on the size of views. Q: For min size, do you mean that there'd be a minimum size that the view could be resized down to, but not further? Q: For max size, what would happen, would you just end up with empty space in the workbench? If yes, why is this better than allowing the view to take up this extra space (seems wasted space in the view is no worse than wasted space in the workbench). >>3) Suppress the ability to minimize and/or maximize a view. See bug I just entered, https://bugs.eclipse.org/bugs/show_bug.cgi?id=154311 [Perspectives][ViewMgmt] Need smarter Min/Max view behaviour >>5) Lock a view to one edge of the page. Can you elaborate why this is required? (I can imagine reasons, just want to hear real usage cases). (In reply to comment #2) > >>1) Prevent the resizing of views. We are creating simple, "selector" views > Q: By "selector", do you mean that the view contains a fixed list of items? > Selector is not the greatest name. Yes, the item count would be fixed. The space required to show the items would not change. > >>2) Set boundaries on the size of views. > Q: For min size, do you mean that there'd be a minimum size that the view could > be resized down to, but not further? Right. > > Q: For max size, what would happen, would you just end up with empty space in > the workbench? If yes, why is this better than allowing the view to take up > this extra space (seems wasted space in the view is no worse than wasted space > in the workbench). Let's say I have a perspective that is laid out for two side-by-side views. Double clicking on an item in the left hand view brings up a view on the right. Double clicking on another item replaces the existing right-hand view with another. The user may also manually close the right hand view. It's disconcerting to watch the left hand view redraw itself as it expands and contracts for no real reason as views are opened and closed on the right. The view's toolbar and menus also move. Having said this, I'll concede that a max size is less important than a min size. > > >>3) Suppress the ability to minimize and/or maximize a view. > See bug I just entered, https://bugs.eclipse.org/bugs/show_bug.cgi?id=154311 > [Perspectives][ViewMgmt] Need smarter Min/Max view behaviour It sounds like a useful alternative to min/max. > > >>5) Lock a view to one edge of the page. > Can you elaborate why this is required? (I can imagine reasons, just want to > hear real usage cases). > In our case it's just a matter of keeping things relatively simple for users. There are two important, standalone, navigational views that we want our users to always find in the same place, on the left and right edges of the perspective. We want other views in the perspective to be movable and dockable, but they should always stay between the two standalone views. There are currently no plans to work on this feature. PW Changes requested on bug 193523 Just fyi: As of 3.4, views may optionally adapt to (or implement) ISizeProvider if they have a preferred size. The default presentation will make a best effort to allocate the preferred size to a view if it is the only part in a stack. If there is more than one part in the stack, the constraints will be disabled for that stack. The size constraints are adjusted for the size of the tab and border trim. Note that this is considered to be a hint to the presentation, and not all presentations may honor size constraints. 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. |