Bug 166449 - panel position prevents window maximize
Summary: panel position prevents window maximize
Status: RESOLVED DOWNSTREAM
Alias: None
Product: plasma4
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-13 14:45 UTC by Michal Svoboda
Modified: 2018-06-08 20:36 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Svoboda 2008-07-13 14:45:42 UTC
Version:            (using KDE 4.0.83)
Installed from:    Compiled From Sources
Compiler:          gcc version 4.3.1 
OS:                Linux

positioning a panel prevents any window to be maximized into that area. this is a good thing when the panel occupies a whole strip of screen, but leaves empty space when the panel maximum size is changed. in kde3 one could let maximized windows span over the panel by setting 'let other windows over the panel'.

with vertical panel placed to the right of the screen, the plasma add/lock widgets button is also weirdly moved to the left.

when panel's maximum and minimum sizes differ, the panel prohibits placing shaded window titles into the area that it could possibly occupy at maximum size.
Comment 1 Maciej Pilichowski 2008-11-15 19:25:22 UTC
And the _one_ wish for this report is...?
Comment 2 Michal Svoboda 2008-11-17 06:43:14 UTC
Given the following desktop layout:

  +-----------------+
  |                 |
  |       A         |
  |                 |
  +-----+           |
  |  B  |    C      |
  +-----+-----------+

(A) is normal desktop space, (B) is occupied by a panel and (C) is empty
space where the panel (B) could possibly expand, but does not,

1) let normal windows occupy the space (C)
2) let shaded windows occupy the space (C)
3) let maximized windows occupy spaces (C) and (B) (with the possibility
that panel (B) is always on top or not)
4) when the situation is rotated 90 degrees ccw (ie. (B) and (C) are
along the right edge of the screen), let the kidney-shaped thing reside
in area (C) - currently it it pushed into area (A)

You wanted _one_ wish, so, in short: currently, the area (C) is "dead",
unusable by anything except the expanding panel (B), change it.
Comment 3 Maciej Pilichowski 2008-11-17 08:14:03 UTC
So, this is either WORKFORME (if you allow user to customize panels) or it is INVALID (if you don't; from pure geometric reasons -- windows are rectangles, so window cannot be maximized taking C part without taking B).

So:
* maximization -> covers A, B, C --> WORKSFORME
* maximization -> covers A, C without B --> INVALID

imho.
Comment 4 Michal Svoboda 2008-11-17 10:10:41 UTC
In version 4.0.83 it didn't work (ie. maximize would only maximize to area A, leaving C blank), and I don't have any newer version at hand right now. Might be fixed already, in that case close this request.
Comment 5 mootchie 2008-12-13 20:45:59 UTC
I think this request is valid and I have a similar wish.
Just imagine you have composite enable with some monitoring plasmoid in a panel.

It would be nice to have that panel "always on top" and the remaining windows should be able to be maximized *behind* the panel. With some transparency you could see some of that window content and still watch what the panel has in it.

Something more like using the panel as an overlay or a layer above the whole desktop, visible at all time.

Obviously there are situation where it would conflict with the windows below. 

In those cases, when the mouse enters the conflict area, the panel could then fade into an almost transparent state ("ghost") so that the window would receive the actions. In this situation the panel would behave like a normal auto-hide but instead of completely disappearing it would fade to like 80% transparent. If the user wanted to interact with that panel he would just have to trigger it to appear in the same way as a hidden panel in that position (by placing the cursor at the appropriate border).
Comment 6 Maciej Pilichowski 2008-12-13 21:00:33 UTC
> It would be nice to have that panel "always on top" and the
> remaining windows should be able to be maximized *behind* the
> panel. 

Your wish is granted -- KDE has this feature already.

> With some transparency you could see some of that window 
> content and still watch what the panel has in it.

Open another report for that if the feature is not in KDE already.

> Obviously there are situation where it would conflict with the
> windows below.
> In those cases, when the mouse enters the conflict area, the panel
> could then fade into an almost transparent state ("ghost") so that
> the window would receive the actions.

Open yet another report for this feature.

One issue = one report. One report = one issue.
Comment 7 Maciej Pilichowski 2008-12-13 22:11:06 UTC
PS. You should discuss the last idea at usability ML I think. When you open new reports please add here references, thank you.
Comment 8 Nate Graham 2018-06-08 20:36:10 UTC
Hello!

This feature request was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this feature request is already implemented in Plasma 5, or is no longer applicable.

Accordingly, we hope you understand why we must close this feature request. If the requested feature is still desired but not implemented in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting

If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging

Thanks for your understanding!

Nate Graham