Bug 209962

Never noticed? Maybe fixed in KDE 4.4/4.5?

Still present for me. Using KDE 4.5 on Arch Linux.

When I start KDE the used screen is my laptop LCD, which maximizes the panel at 1366 px, then if I switch to an external LCD the panel does not adapt to the new resolution and I have to manually maximize it.

Cheers,
Alessandro

Also still present for me, and I am also using latest stable KDE 4.5 on Arch.  The problem is exactly as Alessandro describes.  
For me, I boot my laptop with an external LCD monitor connected.  I only want to use the external monitor, and the resolution is too low when logging into KDE.  My laptop has Intel GM45 chipset, and I use the following script to make the resolution available and switch over to the external monitor:

xrandr |grep VGA1 | grep " connected "
if [ $? -eq 0 ]; then
   xrandr --output LVDS1 --off
   xrandr --newmode "1440x900_60.00"  106.47  1440 1520 1672 1904  900 901 904 932  -HSync +Vsync
   xrandr --addmode VGA1 1440x900_60.00
   xrandr --output VGA1 --primary --mode 1440x900_60.00
fi

Regards,
Nick

*** This bug has been confirmed by popular vote. ***

Can‘t be too difficult to implement, can it?
It is really annoying since I have an external kubuntu which is attached to various computers and then often not only is the panel too narrow but often it stays black until I maximize it.
And the panel option strip is always the full screen width and then it gives a really bad transition between the full width strip and the smaller panel since it has now shadow and stuff.
Still in 4.6

The panel does adapt to variing screen sizes but only when they are applied while KDE is running. If the screen size is changed and KDE started then (e.g. KDE started on a different machine) it does not check for resolution changes.

http://kde.org/announcements/announce-4.6-beta2.png Even on official screens you see this uglyness. This is just embarrasing. (And I don‘t believe that the developer did this on purpose and even if he had, it still looks ugly with that activity bar over the full size).

The panel does not adapt even when the screen size changes occur while kde is running. It *sometimes* happens that the size is updated, but most of the time it does not. Is there a way to trigger the update?

Yesterday I had a surprise for my mom, I bought a new 24" monitor and gave her the old 24", run her kubuntu and set auto maximize since I didn't want to leave her with a buggy panel.
But she didn't want the screen, it's too big for her, so I just replaced it with her old one. And today she was arguing where her calendar, clock and volume controle had gone. Right: they were offscreen. And now tell her to right click the panel, (i don't evrn lock wifädgets on her machine anymore since it makes evertäything more complicated) go to the panel settings submenu, choosr panel settings, in the resulting strip go to the other settings menu and choose maximize panel. She eventually figured it out but c'mon this is just bad, don't you think? So is this now a won't fix or does nobody of the plasma developers ever use their computer at differrnt screens?

Yes please, please fix this issue. Even Windows XP can handle that. Just make the panel stretch to the maximum extent, with an additional option if you want.

I can confirm this issue on Ubuntu 10.10 with KDE SC4.6. Running on a notebook with an (optional) display the following situations are given:

1) Laptop only with no external monitor connected: Panel is maximized
1.1) change to lower resolution wit "KDE Configure Display" > panel is still maximized
1.2) change back to original (higher) resolution > panel stays at reduced size

2) Connect external monitor and move over to a xinerama setup via the following batch script:
xrandr --output LVDS1 --mode 1366x768
xrandr --output HDMI1 --mode 1680x1050 --left-of LVDS1

Result: Panel moves over to the primary monitor (wanted) yet stays at the reduced size of. The width is roughly about the size it had on the internal laptop panel. 

In each case and for each of these situations this means unlocking the widgets, maximizing the panel, locking the widgets. Cumbersome and annoying. If you need further information let me know.

I can confirm this issue too but only with KDE 4.6.
With KDE 4.4.4 in openSUSE 11.3 the panel would maximize from 1280 to 1920 and vise versa. I am not sure if it is an openSUSE fix or was really working in vanilla KDE 4.4.4.

Same here, using KDE SC 4.6 vanilla on Arch Linux. Changing the screen from my LVDS (800height) to the DFP (1200 height) doesn't maximize my _vertical_ panel. Changing from DFP to LVDS causes the panel to be "cut" - only a partion of it is visible.

This is really embarrassing for a desktop environment.

I'm spending some of my spare time looking at this. I'm having trouble reproducing some of the reported symptoms. I can reproduce the "large screen panel gets partially obscured on small screen" problem as follows:

- start with external screen at 1440x900
- Add an empty horizontal panel, add some widgets, click the "maximize" button
- change screen to 1280x800
- Observe that a portion to the right of the panel gets cut off due to smaller resolution

But I can't reproduce the vice versa case. If I do

- start with external screen at 1280x800
- Add an empty horizontal panel, add some widgets, click the "maximize" button
- change screen to 1440x900

The panel properly maximizes to fill up the horizontal space. I have tried this on both 4.6.0 and on master. Can someone confirm that this is the current behavior? Or can reporters of the "small screen panel does not enlarge when screen size is increased" case confirm steps to reproduce the problem on 4.6.0 or on master?

Lim, I can still confirm this behaviour in KDE 4.6. See my report above. The problem seems to be the second monitor being added or removed.

On a single monitor I can change resolutions all day long (up or down) via the kde settings, xrandr or whatever.The panel stays maximized..

Plug in a second monitor (and redirect the panel to this monitor) and you are in for trouble as described multiple times above. The panel does not adapt to the size of the newly connected external screen.

Thanks for looking into it.

(In reply to comment #15)
> Thanks for looking into it.

Oh yes, very much so :) This is a long standing issue which has been ignored for the past years! I very much appreciate that this finanlly changes! Thanks a lot!

I can confirm that automatic maximizing of the panel seems to work now most of the time but the minimizing doesn't.

So, also I think the option is not applied when the computer starts with another screen? So I replaced my mom‘s 1200x1024 screen with a 1920x1200 and then I started and the panel was still at the old width, then I maximized it to give her a nice look and she didn‘t want the screen and I just replaced it. When she came home she was asking where here calendar (clock widget) was and it was out of screen since the panel was still at 1920 width…
I also noticed, when I attached this screen to my notebook and moved the panel over, sometimes it did adapt to the new size and sometimes it didn‘t.
Isn‘t there a flag like “panel maximized” for the panel? It doesn‘t seem so since the button also has no checked sate but is just a button to maximize the panel and that‘s it.

mz, I've tried switching monitors too:

- maximized panel on 1360x768 laptop screen
- attached external monitor, move screen from laptop screen to external monitor, which is at 1400x900
- panel properly maximizes

However, I noticed that there is an occassional visual glitch that obscures part of the panel with a patch of black when it moves to a larger resolution. Mouse-over-ing the black region shows that the panel and its widgets are underneath and had in fact maximized to fit the screen. Is this what you are observing? I'm focusing on making sure the panel itself properly resizes now, so that visual glitch would be a different problem.

I can reproduce the issue here on my laptop

1. maximized panels (on top and bottom) on 1680x1050. No external screen.
2. switch to external screen with nvidia-settings on 1920x1200. Screen on laptop is off

result : width of both pannels are still 1680px.

And I have to maximize both pannels manually every day. I use the external screen at work and the built in screen at home.

With KDE 4.4 it worked fine. It doesnt work since 4.5.0

Lim,

I do get the obscured black area next to the panel occasionally. For me - as you also see it - this seems to be a graphics bug not related to the panel resize problem. So, no, this I do not mean.

In my case changing over to the external monitor using the xrandr commands from above the panel stays at a width of 1376 px and needs to be maximized via -> unlock -> panel -> maximize or so. Each and every time I use the panel.

Git commit 181c58c354f15fb1bda91ea6582f2baf3975c7f2 by Lim Yuen Hoe.
Committed on 05/03/2011 at 09:35.
Pushed by yuenlim into branch 'KDE/4.6'.

Make panel properly resize to fit in screen when reducing screen resolution.

CCBUG: 209962

M  +32   -2    plasma/desktop/shell/panelview.cpp     

http://commits.kde.org/kde-workspace/181c58c354f15fb1bda91ea6582f2baf3975c7f2

In KDE 4.6.1 I still have this odd behaviour. I will wait to get 4.6.2 in my distro, to check if it's fixed.

Thanks a lot for your work!

I am also still seeing this bug in 4.6.2.

1) When I log in on smaller screen, the desktop is aware of the proper screen size -- except for the panel, which extends off the screen to the right. I have to select "maximize panel" to have it fit on the screen.

2) When I log in on a larger screen, the panel only covers part of the screen.

I have deleted the appropriate settings files as suggested elsewhere several times; this does not help.

One way to reproduce this bug without actually changing the screen resolution is to log in using NX, with different window sizes.

Since this bug is unfixed since years, please consider making the "maximize" choice a setting (checkbox) rather than an action, if that would make things simpler. That is probably what 95% of the users who have this problem want anyway.

I see this problem a lot on 4.6.3 when using VNC or vmplayer where the display geometry may often vary.

I see this problem a lot on 4.6.3 when using VNC or vmplayer where the display geometry may often vary.

Still there in 4.6.4.

*** Bug 181229 has been marked as a duplicate of this bug. ***

Still in current trunk.
I Never experienced this on my notebook even when having used other resolutions but now I just started it and the panel was 1024 pixels in width instead of 1366

I think a nice way of approaching this:
When changing panel extent save the values in percentage relative to the current screen resolution and apply them on startup again so if you have a 1024x768 resolution and maximize the panel, plasma would know „from 0% to 100%“ and when you start on another machine it knows the screen is 1920x1080 and will scale the panel to the 100% which will then be the entire 1920 width.
This will also somehow improve panels that are not spanning across the entire width, they are resized relatively to the screen resolution, so your “dock” is always 50% of the screen width.

It seems there’s hope :)
Be sure that Panel is resized when needed (XRandR events)

Whoops, sorry for the noise: I meant to copy this thing in: https://git.reviewboard.kde.org/r/101968/

This bug is fixed in 4.7, it works fine for me. Thanks to afiestas.

*** Bug 275892 has been marked as a duplicate of this bug. ***

*** Bug 189883 has been marked as a duplicate of this bug. ***

*** Bug 283901 has been marked as a duplicate of this bug. ***

In 4.7.2 the panel maximises here correctly when switching screen with krandrtray.

What's left is that the 'maximise panel' button should be a  'maximise' option next
to left, right, center options.   As it's now it's IMHO inconsistant and a bit confusing.

Thx,
Achim

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