Issue 103410

Summary:	off-screen Drawing tool window
Product:	Impress	Reporter:	matthias.mueller-prove
Component:	ui	Assignee:	AOO issues mailing list <issues>
Status:	CONFIRMED ---	QA Contact:
Severity:	Trivial
Priority:	P3	CC:	frank.loehmann, issues, matthias.mueller-prove, stella.schulze
Version:	OOO310m11	Keywords:	usability
Target Milestone:	---
Hardware:	Mac
OS:	Mac OS X, all
Issue Type:	ENHANCEMENT	Latest Confirmation in:	---
Developer Difficulty:	---

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
/Library/Application
Support/StarOffice/9/user/registry/data/org/openoffice/Office/UI/ImpressWindowState.xcu

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

closing

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

closing

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
-Matthias

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.
cheers
Matthias