Apache OpenOffice (AOO) Bugzilla – Issue 39281
"Jumping" workspace size between Normal, Outline, Notes view etc.
Last modified: 2013-08-07 15:21:02 UTC
When the user has Navigator, Stylist, Slides Panel and/or TaskPanel docked, the UI behaviour on changing views (i.e. between Normal, Outline, Notes, Handout, SlideSorter) is bad: the work-space "jumps around" as it gets resized each time a docked panel is hidden/revealed. E.g. in Normal view, I have Stylist and Slides Panel docked on the left, TaskPanel docked on the right. When I change to Outline view, TaskPanel is hidden. When I change to the Slider Sorter view, the Stylist & Slides panels are hidden. In each case, this results in a *large* change in size of the main workspace, with the view-tabs shifting to a new position. This makes changing quickly between views impossible (as the tabs move in an unpredictable way). Some toolbars also contribute to this problem, as some are hidden/revealed acording to context. The issue is a bit less severe with toolbars, as they are smaller. A better behaviour would be to "disable" (i.e. grey out, instead of hiding) any docked items that do not apply to a particular view context. Floating items may hidden as normal, of course. This way, the physical layout of the workspace does not change which switching between views.
Confirming the issue
Reproducible.
Reassigned to Andre.
*** Issue 39637 has been marked as a duplicate of this issue. ***
Please have a look at this one. Does this make sense (when we assume that we can soon solve the problem with toolbar and menubar resizing while switching the views) ?
CJ -> AF: I can understand that this UI behaviour is bad. I think it would make most sense to leave the windows untouched. The only exception is the Slide Sorter, because it would really make no sense to display the Slide Sorter & the Slides Panel at the same time.
See below for explanation.
The proposed changes do not conform to the spec and will at the current time not be implemented. We can, however, think about proposing this change for the next version.
I personally a) do not see the problem with the current behaviour and b) do not think that disabling panes instead of hiding them is a good solution. a) At the moment only the slide sorter panel and the task panel are hidden or shown when the view is switched. I do not believe that this is such a frequent operation that the moderate size change of the center pane is so very annoying. b) The problem with disabling panes instead of hiding them is that we than have large gray areas on the screen that are a complete waste of space: they are completely inoperable and do not show any usefull information. Additionally, it would not be clear to the user what to do in order to enable these areas again.
Ok, closed. Thanks for the explanation.
I'm re-opening this because a) "I don't see this as a problem" is not a good reason for closing an issue. It's a problem for me; it may be a problem for others. By closing the issue, you remove the opportunity for others to vote or comment on this. b) I'd like to propose an alternative solution: Move the docked windows _inside_ the tabbed notebook pages. This way, if docked windows vanish (because they are no longer relevent), at least the tabs themselves do not move (this is the correct behaviour for a notebook UI anyway - tab selection should *not* affect elements outside the notebook page). If all windows are floating there would be no change in behaviour from the current one. As a heavy Impress user, I've found that "chasing" the tabs across the top of the page according to context (Normal or Slide-sorter view) is very fatiguing. I'm sure the current behaviour meets the spec, but what if the spec is wrong? I accept there are no resources to address this in the short term, but please don't brush the issue aside. This is my last word on the subject. If you still feel the issue should be closed I'll leave it at that. PS. Sorry for pestering you on this. Great work on OOo-2; it's looking great overall!
I can understand that you are not satisfied with the solution. Because of the fact that the current solution is how it is wanted from the specs side I can set this from defect to enhancement and reasssing it. That will leave the possiblity to vote and that in the future the behaviour will be reworked. Thanks for your help.
It isn#t possible in OOo 2.0 timeline to change something. I reset this issue to OOo 2.0.1, perhaps until then the requirements team will find a solution.
I can also reproduce this issue, running OpenOffice 1.9m109 on Windows XP Pro, SP2. This is problematic for users who are traveling with a presentation, as it's most likely they'll get a computer with PowerPoint on at their destination, and being unable to see any of their slides will cause grief.
We should implement a solution at least for OOo 2.0.2.
Currently we have no resource to implement a final solution for avoiding the 'jumping' views, but I consider this issue as important to rethink about.