Issue 39281 - "Jumping" workspace size between Normal, Outline, Notes view etc.
Summary: "Jumping" workspace size between Normal, Outline, Notes view etc.
Alias: None
Product: Impress
Classification: Application
Component: ui (show other issues)
Version: 680m65
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 39637 (view as issue list)
Depends on:
Reported: 2004-12-19 15:50 UTC by bryancole
Modified: 2013-08-07 15:21 UTC (History)
3 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description bryancole 2004-12-19 15:50:53 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

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.
Comment 1 nagashree 2004-12-20 12:18:51 UTC
Confirming the issue
Comment 2 wolframgarten 2005-01-04 08:59:59 UTC
Comment 3 wolframgarten 2005-01-04 09:00:18 UTC
Reassigned to Andre.
Comment 4 Frank Schönheit 2005-01-07 16:11:48 UTC
*** Issue 39637 has been marked as a duplicate of this issue. ***
Comment 5 groucho266 2005-01-11 14:05:10 UTC
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) ?
Comment 6 christian.jansen 2005-01-11 17:02:56 UTC
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.
Comment 7 groucho266 2005-01-12 15:57:54 UTC
See below for explanation.
Comment 8 groucho266 2005-01-12 16:00:31 UTC
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.
Comment 9 groucho266 2005-01-12 16:10:10 UTC
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.
Comment 10 wolframgarten 2005-01-13 08:08:56 UTC
Ok, closed. Thanks for the explanation.
Comment 11 bryancole 2005-03-02 10:20:54 UTC
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
Comment 12 wolframgarten 2005-03-02 10:30:53 UTC
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.
Comment 13 thorsten.ziehm 2005-03-04 13:46:31 UTC
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.
Comment 14 sauron11 2005-07-06 15:47:01 UTC
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.
Comment 15 bettina.haberer 2005-08-15 10:40:04 UTC
We should implement a solution at least for OOo 2.0.2.
Comment 16 bettina.haberer 2005-12-02 15:08:45 UTC
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.