-2

Okular and Dolphin are two applications that have panels. When one clicks on a panel, the window size is preserved, but the displayed content dimensions change to accommodate room for the panel. When viewing a pdf and clicking on "Show navigation panel" in Okular, this is somewhat infuriating. As an alternative, a better option would be to keep the content dimensions fixed (along with the original window) by having the panels slide out and extend beyond the original window size. OS X implements this in places, such as TeXShop's preview window.

Some may not want this implemented across the board, but it would be nice in some applications that would benefit from it, like Okular. (Actually I think all would benefit from it.) I think one shouldn't be worried about consistency here, since good guidelines would make it obvious when an application should or shouldn't implement sliding panels.

Sorry I don't like this idea.

What will happen if window is maximised? Clearly should behave old way and this would look inconsistent to me. What If windows are tiled?

The OSX drawer is a known GUI fail.

See eg. here for a slight rant:
http://www.mcelhearn.com/2006/07/29/the ... e-element/

The major issue about it is the assumption about the remaining space next to the window what will in doubt have to make the window move or shrink/regrow on hiding/showing that thing.

I know that many ppl. feel attracted when first seeing the concept (looks natural and familiar - real life drawers are a success story, but you move the helf into the perfect position and no more around afterwards), but facing real (imperfect) implementation figure that it's just annoying.
Also apple has withdrawn it from a couple of applications for that reason.

As for the docks in Qt, you can completely detach them from the window and KWin (iirc by default) hides them when the application becomes inactive.

The rant you link to gives legitimate reasons for not liking *the way some programs in OS X implement drawers*. It's not a rant against drawers, per se. I still think correctly implemented ones would best the way panels are currently implemented in KDE, but I also see the host of issues surrounding implementation.

If there isn't enough screen space to accommodate a drawer, the window should resize. When the draw is closed, the window should resize back.

The top/bottom of the draw should extend *all the way* to the top/bottom of the window border (unlike in OS X).

Special window settings should also allow toggling between draw/panel behavior. Thus if one wants their windows tiled without panels messing things up, they can set it that way. A toggle button for draw/panel behavior could even be conveniently placed in the window/panel.

It's more along "virtually all" - that exposes a conceptual flaw.
I suggest to get a Mac and actually try this. It is an annoying concept.

Special window settings should also allow toggling between draw/panel behavior.

Not an option, at least not from KWin - "drawer" is not a concept in NETWM (if you want to get it into netwm, just try) so has to be done clientside by override_redirects.
The result will be the arbitrary situation like on MacOS.

If there isn't enough screen space to accommodate a drawer, the window should resize. When the draw is closed, the window should resize back.

You do not feel like this would be tremendously annoying? The local workspace would alter by the temporary presence of some window (and actually that is what you criticize about the present situation)
Rule of thumb is to not add, remove or resize regions inside a window (other than for configurable GUI layout setup of course) and instead use an extra layer ("dialog") for temporary items or such of expectable dynamic size.

So if you wish do dynamically add/remove panels like the file informations in dolphin, the least problematic approach will be an extra window (float the dock) - what implicitly resolves you from size constraints (info panel determining min height of icon view etc.)

I've frankly not seen

When one clicks on a panel, the window size is preserved, but the displayed content dimensions change to accommodate room for the panel.

what could be an i18n bug - in any case this much bug-a-like. This kind of behavior demands an independent window (because unwanted size changing is indeed a GUI bug, here as well as to successfully show/hide a drawer)

Thanks for helpful discussion. I'm less convinced with drawers now, given what you've said. I think a good substitute, for me anyway, is to use floating panels *when available*. Unfortunately not all application panels are floatable (e.g. Okular's navigation panel), which I find annoying.

By the way, I've tried drawers on OS X with pathfinder and texshop's preview, and both seemed usable to me, but perhaps that is only because I have my windows set a certain way. I can see there are lot of problem cases.