Issue 103410 - off-screen Drawing tool window
Summary: off-screen Drawing tool window
Alias: None
Product: Impress
Classification: Application
Component: ui (show other issues)
Version: OOO310m11
Hardware: Mac Mac OS X, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: usability
Depends on:
Reported: 2009-07-08 10:31 UTC by matthias.mueller-prove
Modified: 2013-08-07 15:20 UTC (History)
4 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 matthias.mueller-prove 2009-07-08 10:31:23 UTC
- Undock the Drawing palette from the Impress window
- Move the main Impress window
=> and the Drawing palette will move as well -- even beyond the edge of the screen!!

If this is not notices in time by the user she has no clue how to move the tool
window back to the visible are on screen. (At least I had no clue I had to edit
the file
Comment 1 matthias.mueller-prove 2009-07-08 10:33:19 UTC
Desired behavior: tool windows should keep their position when the main window
is moved.
Comment 2 wolframgarten 2009-07-08 11:04:12 UTC
Reproducible. Works under windows. Reassigned.
Comment 3 philipp.lohmann 2009-07-08 11:54:41 UTC
Your desire is wrong then as it is the standard mac behavior that child windows
move with the parent - this is done by the mac itself not us. Effectively you're
talking heresy against the church of Apple :-)
Comment 4 philipp.lohmann 2009-07-08 11:55:11 UTC
Comment 5 matthias.mueller-prove 2010-04-14 16:01:58 UTC
Just show me one Mac application where this is the case. Tool windows stay where
they are. Child windows move with the main window, but they are only used for
drawers that are in a defined spatial relation to the parent window.
Once you detach a toolbar from the window it should be treated as a tool window.

As a minimum requirement you have to prevent that the detached toolbar moves out
of bounds and cannot be reached anymore.
Comment 6 philipp.lohmann 2010-04-14 16:25:39 UTC
That is because tool windows in other applications are once per app, whereas in
OOo they are once per document. That is also, why they need to be child windows
in OOo,  because else you could raise the document (= parent) over them like you
can do with most tool windows in other applications.

As long as toolbars are conceptionally child windows of the document in OOo,
they should behave as such.
Comment 7 philipp.lohmann 2010-04-14 16:26:58 UTC
Comment 8 matthias.mueller-prove 2010-04-14 16:51:49 UTC
Hi Philipp,
the resolution WORKSFORME is nice, but it does not work for the user. So please
consider at least a check that OOo's child windows cannot move completely
outside the visible screen area.

The users and I will thank you
Comment 9 philipp.lohmann 2010-04-14 17:02:17 UTC
When all other child windows on MacOS can ? Why would this not be a problem for
all other mac applications but for us ? Someone at Apple decided that this is a
good thing to do. 

But since it bothers you so much, let's give this issue as an enhancement to UX.
The "correct" solution would be anyway to have the toolbars not per document. So
maybe within renaissance the toolbars get an overhaul to make them such.
Comment 10 matthias.mueller-prove 2010-04-14 17:09:33 UTC
Hi Philipp,
"all other child windows" are to the best of my knowledge drawers. There is a
control on the main window to open and close them. And they cannot be moved by
the users... away from their parent window. That is the main difference to OOo's
tool windows.

Hi Frank,
I guess you can spot the usability issue easily.
Now just find a smart and simple solution.