Issue 8095

confirming

Giuseppe, the reason for this is that the stylist/navigator and such
are now system windows (which means that they can be moved outside the
window they belong to). I am not sure if the functionality to reduce
them to the title bar has been removed by intent or by accident (more
concrete, the question is whether it was intentional to _not_
implement this for the new system windows). I suspect the latter (the
accident).

Don't know how to deal with this - would be interesting to hear
opinions of others about this feature ...

Frank

Joost->Giuseppe: as Frank already said ... we changed these toolboxes
in that way that they now use system windows. As this is an important
system integration feature and a very important accessibility feature
to have system windows here it won't be fixed. On the other hand not
every window manager has support for this (regarding Linux, Solaris,
Windows, +++ platforms). 

This is somewhat annoying, I must say ... the ability to shadow them 
was of great comfort for keeping them open without too much clutter 
... couldn't pseudo-shawoding be implemented by reducing window height 
to the minimum (0?) on platform that don't support it natively?

As mentioned on the qa dev list on March 5th I will close all resolved duplicate
issues. Please see this posting for details. First step in IssueZilla is
unfortunately to set them to verified.

As mentioned on the qa dev list on March 5th I will close all resolved
<wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details. 

I'm reopening the Issue as a follow-up to a discussion on discuss@; it 
would be nice if shadowing could be (re)implemented (independently 
from the window manager) for platforms that support it (like Windows).

YEs. It would be nice to re-implement this on Windows. IT seems never 
to have gone away on Linux version, so the present state represents 
both a loss of funcitonality (on Windows) and a loss of cross-platform 
consistency. 

The general idea of reimplementing these things as system windows is 
great, though.

Hi,

I liked this feature too.  I call them roll ups.

It makes it easier to work with Styles and the Navigator.

Makes it much easier to work on Forms where is is possible to have 
four of these rollups open.

I was recently surprised to see another person using this feature 
that they stumbled across themselves so it does come in handy.

Just adding my voice to the issue.

SBA: I consider this inconsistency (works on some platforms only, used
to work before) a bug. This is must-feature in my opinion as it eases
the effective work in large amounts. Whatever can be done in this case
should be provided to the user.

I agree that having this on windows also would be a nice move. IMHO it
shouldn't be too hard to implement. Stefan, is this correct?

Correct. On UNIX we only have this feature if the window manager
supports it. If not, we have no chance to detect a double-click on the
title bar. On Windows, we can easily detect the double-click and react
accordingly.

*** Issue 12338 has been marked as a duplicate of this issue. ***

I too like to have this feature back, even a more advanced version, 
see issue 8647.

Navigator is really useful (particularly if extended as suggested in 
issue 6736, issue 6741, issue 7085, issue 7047, issue 7049) and if in 
window mode, its titlebar is faster to move the mouse pointer to than 
to the main windows side and it also takes away less space and 
doesn't block the view or interrupts the normal view to the positions 
of elements in / to the document when unrolled in window mode than / 
as in docked mode. And when having the window rolled up, it gives 
space back to see and work on the complete document wiothout moving 
the window around. So window mode + (auto-)roll-up is VERY 
conevenient and comfortable!

As requested, I changed the O/S to "All". The patch should only be 
developed for the O/Ses which allow it to be developed (i.e. Windows), 
since the other O/Ses (i.e. UNIX-like systems) usually allow shadowing 
by themselves (with the appropriate windows manager) or don't allow 
appropriate tracking of the mouse pointer.

*** Issue 17055 has been marked as a duplicate of this issue. ***

Please! I got very used to double-clicking the title bars!

Furthermore, in OOo 1.0 nothing happened when the esc key was pressed,
while in OOo 1.1 the window is closed entirely. Would it cause much
afford to collapse these windows to their title bars for the Esc key,
too? (issue 13430)

*** Issue 13269 has been marked as a duplicate of this issue. ***

for completion, since I don't want to add this to every issue :-)

Maybe it's sufficient for your needs to "dock" these windows:
Drag them to the side of the window while pressing <ctrl>.
You can then toggle the behaviour (autohide or stay on screen, stick
or float):
The window now has a pin and an arrow. Use the arrow to make it
autohide/stay and the pin to change whether the window should just be
on top of the document or whether it should be placed next to the
document (cannot explain it in english, just try it out).
If you klick the arrow to open the navigator, it will stay on screen
even when you leave the navigator window. If you klick below the pin
instead (just klick the bar) the window will hide when leaving.

To 'undock' the window, press <ctrl> and double-click in some
white-space in the navigator-window.

*** Issue 17491 has been marked as a duplicate of this issue. ***

Hi,

Thanks Christian for the suggestion on docking. I've looked at 
docking.  Both sides and bottom, multiple windows to a side.  These 
are worthwhile options, but nowhere near as good as the rollups IMHO.

Thought I would increase my vote on the issue, as this is one of 
those nice to have features.

Thanks

Kelvin

*** Issue 16016 has been marked as a duplicate of this issue. ***

*** Issue 18839 has been marked as a duplicate of this issue. ***

I just voted for this. I agree with Kelvin.

Thanks to Christian for his suggestions. 

Jaime

*** Issue 19552 has been marked as a duplicate of this issue. ***

Hi All,

I am also voting for being able to roll up/down the Stylist box 
to/from it's titlebar.  
Also if possible, I'd like the little roll up/down button back as 
well, that way it's only one click to roll either up or down.

I won't comment on the auto rolling or docking as I've no experience 
with either, and also only just started using navigator.

Regards,
Andrew Kovacs

*** Issue 19553 has been marked as a duplicate of this issue. ***

*** Issue 14884 has been marked as a duplicate of this issue. ***

*** Issue 17814 has been marked as a duplicate of this issue. ***

*** Issue 25263 has been marked as a duplicate of this issue. ***

I vote for this issue as well. I relied heavily on this feature when it was
available. I'm not much for docking things, I tried it, and I just prefer being
able to roll up the window. It also keeps the linux and windows version consistent.

Because of limited resource for OOo2.0, it was decided to shift this tasks to
the next milestone. If somebody will be found, who can implement this until
OOo2.0, then this tasks will be re-targeted.

since this issue is about the stylist window being a system window, i'd like to
make an additional request.
i'm working under suse 9.1 with kde 3.2 on two 19" monitors, with a "maxed" OO
window in one of them.
The stylist window should stay put whereever (e.g. on what monitor) it is moved
(visible or not).
instead of this, it does jump right INTO the activated OO window, taking up
valuable workspace.

SSA: reassign to HDU

HDU->PL: reassigning as discussed

*** Issue 25906 has been marked as a duplicate of this issue. ***

Tested using Writer OOo 2.0.1 on PC WinXP SP2.

I would suggest the discussed functionality is present (to an extent) in the
current UI. Although a 'minimise' function doesn't exist on the window title
bar, it can be achieved using a single mouse click by two methods:

1) On the 'Formatting' tool bar, click on 'Styles and formatting' icon to make
the Stylist visible (=maximised) or invisible (=minimized). Equally for
Navigator, on the 'Standard' toolbar, clicking the 'Navigator' icon has the same
effect.
or...
2) First dock the stylist / navigator window, then click on the controller (part
of the docked frame) for 'Hide' (=minimized) and 'Show' (=maximized).
Finally, a 'bonus' 3rd method using a single key press:
3) Pressing F5 (Navigator) or F11 (Stylist), will show / hide the respective window.

These functions seem to satisfy the requirements of this issue. I feel a more
worth while enhancement was that suggested in Issue 8647, however, this wont be
fixed.

Regards,
Andrew

*** Issue 14382 has been marked as a duplicate of this issue. ***

setting target

target

pl->cd: as once discussed this would be a hassle to do with system decorated
windows (though on Unix you can already do this if the window manager supports
this). However there was discussion anyway to change stylist/navigator and such
to the same type of docking window as our toolbars; in this case you can simply
set WB_ROLLABLE and this works out of the box (I checked with the toolbars).

However This will probably bring up focus issues we need to solve. So perhaps
you could start by changing the window type and then get back to me when you
have a CWS where we can further develop this.

cd: Accepted. Currently we try to move the docking windows from the old sfx2
implementation to work with the framework based layout manager. I hope we are
able to support this feature after this move.

Hooray!  
It would be nice to see this return after all these years.

It was very useful in 1.0.1

target 3.0

The work on the docking window implementation won't be finished in 3.0. Thus
moving this issue to 3.1 also. But it's still on the list. :-)

As the rework still isn't finished: sorry, no 3.1