Version: KDE kderuntime/workspace (using KDE 4.3.4) Compiler: Gcc 4.4.1 PCLinuxOS KDE 4.3.4 OS: Linux Installed from: Unlisted Binary Package If you switch to a lower desktop resolution the taskbar resizes to fit the lower resolution. If you switch back to a higher resolution the taskbar remains at the size of the lower resolution, doesn't expand back and requires manual adjustment.
do you mean the taskbar or the whole panel? if unsure, please provide a screenshot.
I'm sorry I should have been more clear. I switched to a lower video resolution (1024x768)), logged into KDE 4 and the panel width adjusted to the lower resolution. I did this to prove to a forum member that a program worked independent of screen resolution. Later I changed my video resolution back to 1680x1050. When I logged back into KDE 4 the panel remained at the width of the 1024x768 resolution being somewhat squashed requiring manual adjust back to full width. Maybe it is not a bug but just the way it works?
I have the same problem since I upgraded from KDE 4.4.2 to 4.4.3, so it seems to be a regression. I have a notebook with a resolution of 1280x800. At work, I connect a 1920x1200 display and only use that. I configured my plasma panel in the Panel Settings > More Settings to "Maximize Panel" so that it occupies all the horizontal space at the bottom of my screen. With KDE 4.4.0 to 4.4.2, no matter if I used the big external monitor or the laptop display, the panel was always maximized. Since KDE 4.4.3, when I use only the external one, the panel is justified left and is only 1280 pixel wide, so that I have to configure "Maximize Panel" every time I start the computer at work.
*** Bug 241396 has been marked as a duplicate of this bug. ***
*** Bug 241524 has been marked as a duplicate of this bug. ***
I saw this a week or two ago. .. actually, I'm not certain whether I was using trunk, 4.3 or 4.4 at the time :/ I'll play with it tomorrow.
I can confirm this bug and yes it is a regression. Testcase: - Make sure you set panelsize to Maximum - Change to a lower resolution (if you can't go higher then the one you have as default) - Change to a higher resolution Result: - Screen goes to a higher resolution - Panel remains the width of the lower resolution Expected result: - Screen goes to a higher resolution - Panel maximizes width
Seems like this one is not been seen by KDE-folks so I took the liberty to add Aaron -Head of state- Seigo. @Aaron: I am busy to keep KDE Netherlands alive, making some plasmoids with Plasmate and developing a Dutch Live-CD for 'the average user' so I hope you don't mind that I don't have enough energy to learn how to bugtrace ;-)
I have the same bug. When I switch from my 1280x800 laptop screen to my 1920x1080 desktop screen. To resolve this issue, I've been playing around with plasma scripting. http://aseigo.blogspot.com/2009/09/scripting-plasma-desktop.html Plasma is aware of the resolution change, because: print(screenGeometry(0).width); gives as result 1920. In order to maximize the panel, I have to manually change the length. panelById(panelIds[0]).length = 1920; Or use a script found in a comment on the blog. http://aseigo.blogspot.com/2009/09/scripting-plasma-desktop.html?showComment=1273231334121#c2503521660720057071 replacing height with width.
A small addition to my previous post. When I change from 1280x800 to 1920x1080, I have to manually maximize the panel. When I change back to 1280x800 and than change to 1920x1080, the panel is maximized automatically (like it should). But after a restart off my computer, and switching to 1920x800. I have to manually resize the panel again.
*** Bug 244614 has been marked as a duplicate of this bug. ***
*** Bug 233542 has been marked as a duplicate of this bug. ***
Please find the bug instead of duplicates ;-)
"Please find the bug instead of duplicates" i'm sure you were attempting humor, but from the other side it comes off as a smart ass remark. anyways, nailed the root cause of this last week and it's fixed in 4.6. unfortunately, systems affected by the bug may need to reset the size at each resolution or just remove plasma-desktoprc (NOT plasma-desktop-appletsrc!)
Not knowing that it was my comment you quoted I laughed my ass off. So yeah, I think it is humor. I know everybody out there is working hard so I did not mean to offend someone. Thanks for fixing the bug. Things like this make a desktop feel polished :-D
I'm still experiencing this problem in 4.5.90 (4.6 RC1). It does not automatically resize the panel even though I've changed it a few times after upgrading. I daily switch between 2 resolutions. I did not delete plasma-desktoprc
Aaron: It works, just remove plasma-desktoprc Pascal: It does not work, I did not delete plasma-desktoprc Find the differences
Well, I just reinstalled and updated to KDE 4.6 Beta and still no auto-resize. I didn't copy over the .kde folder so I ahve a new plasma-desktoprc
@BartOtten Aaron wrote "reset the size at each resolution OR just remove plasma-desktoprc" I consider removing plasma-desktoprc a magic-trick that regular users should not be aware of - therefore am I testing that it works with the solution that I find acceptable. Until now it doesn't work - but I'm thinking that it might be fixed after RC1 was tagged. ??
@aseigo I've tried to delete my plasma-desktoprc. Now I'm experiencing something worse - the panel does not shrink when I lower the resolution, which results in me not being able to reach the cashew to change it. We need to reopen the bug - the solution is not working as it should. Using RC1
note for people with the too large panel issue: It is possible to get the settings dialog (aka what the panel-cashew normally triggers)by right clicking (almost anywhere on) the panel -> panel settings -> panel settings. Clicking "More settings" -> "Maximize panel" will restore the panel to screen-size.
It's annoying to click on "Maximize panel" everytime y dock/undock my laptop when I arrive/leave home.
It's not fixed on kde 4.6 rc2
I as well confirm that it is not fixed in 4.6 RC2 (Kubuntu packages)
Not fixed in Final 4.6. Please re-open.
*** This bug has been marked as a duplicate of bug 265051 ***