Issue 23953 - Behaviour of Floating Windows and Docked Windows should be more intuitive
Summary: Behaviour of Floating Windows and Docked Windows should be more intuitive
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: ui (show other issues)
Version: OOo 1.1 RC5
Hardware: All Linux, all
: P3 Trivial with 6 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-12-29 22:06 UTC by carstenklein
Modified: 2013-02-07 22:38 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description carstenklein 2003-12-29 22:06:31 UTC
A more intuitive drag+drop mechanism instead of STRG+DblClick would be nice to
attach floating windows to the “desktop”, dragging them (making them floating
again or moving them on the desktop) by drag and drop (without STRG+Click+hold)
would be nice, too.
Comment 1 h.ilter 2004-01-05 16:25:36 UTC
Reassigned to BH
Comment 2 mwaeckerlin 2005-05-27 12:55:51 UTC
Ctrl+Double-Click is absolutely not intuitive to "free" a docked window. I only
found the solution because of this Issue when I was looking for "dock",
otherwise I would have had no chance to undock it!

A GUI that need help or explanations is a bad GUI!
Comment 3 carstenklein 2005-08-15 13:24:08 UTC
Behaviour of floating windows in respect to attaching and detaching has
absolutely  become better. However, there are still those floating windows
created by detaching any of the toolbar drop-down windows, for example zoom etc.

Their positions will not be stored and will be repositioned or re-attached at
will of the application, for example OOo draw, and not by will of the user.

Additionally, the new pages overview with zoomable thumbnails of pages has a
really bad behaviour and sometimes cannot be re-attached to the application
window, for example by dragging and dropping it to the right of the
application's main window.

I am surely impressed by the already established improvements on this part of
the ui, however above behaviours still cause some frustration when operating the
user interface, losing both valuable time and ideas still in mind over the task
of having to deal with problems imposed by the user interface.

Comment 4 fkbreitl 2008-09-14 22:39:09 UTC
It is poor gui design if the user has to read the help to learn how to dock a panel.
I propose to add a "Dock pane" menu to each pane as it already exists in the
"task pane" to avoid any further irritation of users.
Otherwise this issue will be come up again and again.
See e.g. issue 34373 and 93886.
Comment 5 durtreg74 2009-04-03 10:00:28 UTC
Showing / Hiding of dockable menus:

1) If I close a toolbar (like "bullets and numbering"). Then click on normal
text, and then again on a bulleted text/list the dock reappears.

Could there be a way to make these things possible:
- permanently hide some not used toolbars (for me: bullets and table toolbars,
as they take up space (on a netbook) and I have most functionality mapped to keys)
- permanently show some toolbars

2) remember percentage of space used by toolbars
I usually have Stylist docked under Navigator on the left of my screen. As this
is a netbook I sometimes need to see all of the Stylist or all of the Navigator.
However, if I press F11 (to hide the Stylist if both were shown before), and
then press F11 again, then the Stylist takes up nearly all of the space
available, not half of it like it used to. 
The same happens vice-versa with F5 and the Navigator.

Would it be possible to let the toolbars remember the percentage of space they
use up?

Apart from this Enhancement request: You do a great job, I love openoffice and
use it everywhere. At work I much prefer it to MS Office and wherever I can I
advertise its use. 
So, THANK YOU 
Comment 6 bettina.haberer 2010-05-21 14:46:45 UTC
To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements".