Version: (using Devel) Installed from: Compiled sources Description of problem: Neither the Plasma desktop nor the Plasma panel do enlarge to the right size when the resolution of the monitor is set to higher values on the fly via xrandr or for example nvidia-settings. Windows are however resized to the right, higher resolution. Version-Release number of selected component (if applicable): KDE4Daily svn version 818795 How reproducible: This can be easily reproduced with the KDE4Daily image. Steps to Reproduce: Load the virtual machine (I used VirtualBox), and log into KDE 4. Use xrandr to set the standard resolution to a value smaller then the maximum. IN my case the maximum resolution is 1280x800, and I've set it to 1024x768 (xrandr -s 1024x768). Log out, you will see the login manager at the smaller resolution. Now log in again, KDE4 also appears at the smaller resolution. Next, use xrandr to set the resolution back to the maximum value. The Plasma desktop as well as the panel don't fill the entire screen, but only the smaller area beginning at the top left. The rest of the screen is filled with a gray area with white blocks. However, maximized windows do fill the full new resolution. If you try to resize the panel, it jumps automatically to the bottom and therefore at least to the right place (while still not large enough to fill the full width for example). If I now log out and log in again, and the desktop fits to the high resolution, and also maximized windows fit to the new, high resolution. Only the plasma panel is everything works again. But log out/log in everytime I increase the screen resolution is not an option! Actual results: The panel and the desktop stay in the old resolution beginning in the left upper corner. Expected results: They should enlarge to the new, higher resolution. Additional info: I tested this with nvidia-settings on OpenSuse 11.0RC (with "unstable" packages) as well as with xrandr in KDE4Daily. This bug sounds similar to Bug 154045, but that one is marked as fixed, while the problem described here is certainly still existent.
Created attachment 25233 [details] Image showing the actual result, here shown with KDE4Daily in VirtualBox
> use xrandr to set the resolution back to the maximum value. if you can, please start plasma from a konsole before doing this step. then when you do increase the resolution, look for debug to appear that says "adjust size for screen". can you copy and paste everything that appears from that line down? thanks.
Aaron, there is no output at all like this in the konsole. Is there a specific way to enable such debug information?
I can reproduce this bug: If the panel is maximized and you increase the screen resolution, the panel doesn't adapt to the new resolution, it stays at the same width as before. The output of plasma when increasing the resolution (1280x1024 → 1680x1050) looks like this: ### snip ### plasma(14267) PlasmaApp::adjustSize: adjust size for screen 0 plasma(14267) PlasmaApp::viewForScreen: comparing 0 0 plasma(14267) PlasmaApp::adjustSize: here we go ... adjusting size plasma(14267)/libplasma Plasma::View::Private::updateSceneRect: !!!!!!!!!!!!!!!!! setting the scene rect to QRectF(0,0 1680x1050) associated screen is 0 plasma(14267) PanelView::updateStruts: screen l/r/b/t offsets are: 0 0 0 0 plasma(14267) Panel::constraintsEvent: constraints updated with 4 !!!!!! plasma(14267) Panel::constraintsEvent: constraints updated with 2 !!!!!! ### snap ### The panel should have a 'maximized' property which is applied, no matter which screen resolution is active.
Making the panel to get adjusted by percentage, not absolute number, wouldn't make it?
@Elias: it does as of last week. @Janz: no, that just causes other complications. the bug here, for those who may be reading this and wanting to fix it, is that on *log in* we don't check the resolution we now have. we probably need to save the value of m_lastSeenSize and restore it on creation.
SVN commit 821530 by aseigo: * don't cache the config object in the PanelView class; let Plasma::View decide what the best way to deal with that is * save/restore the last seen size between boots; should allow us to adapt to screen resolution changes between login. can the reporter of BR#163676 test and make sure this fix works for them? if not, we can re-open the bug. thanks. BUG:163676 M +10 -6 panelview.cpp M +0 -2 panelview.h M +1 -1 plasmaapp.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=821530
It still doesn't work for me: I start my kde4daily virtual image (revision 822952) and log into KDE. I switch the resolution from 1280x768 to 1024x768 via xrandr -s, and log out. I log in again and switch the resolution back to via xrandr -s, and the screen looks like the image attached above: the background image is not enlarged to the rest of the screen size, and the panel stays at the old size. Already open windows still maximize to the old screen size. I can indeed enlarge the panel to the full size and move it to the right position just by the panel settings now, and new windows maximize to the full area. Also, the plasma symbol is at the right corner of the new screen size, and I can move Plasma applets to the new screen area. But that is not done automatically: the plasma panel should move to the bottom of the new screen automatically and should also enlarge to the same percentage of the new screen size as it had on the old screen size. Last but not least the background wallpaper should now fill the whole screen, and already opened windows should have no problem to be maximized to the new screen size.
> Already open windows still maximize to the old screen size. this is a good hint that the "screen size has changed" signal is getting sent out. note that window maximizing is handled by kwin, not plasma. so both apps are incorrectly sizing here. however, it works fine here: i saw it several times yesterday as i plugged a machine in/out of a t.v. a couple times to watch some shows. i don't know if the problem is in xrandr, Qt or what not, but i'm highly doubtful it's a plasma codebase issue.
Hm, ok. One question though: did you test it with logging out during the screen size changes? And could it help if I send you my virtualbox image somehow?
> did you test it with logging out during the screen size changes? you mean have i logged in with a smaller screen resolution and then enlarged it? honestly, i haven't. that would require a lot of reconfiguration to fix it here. honestly, it's more telling that it's also affecting *kwin*. > could it help if I send you my virtualbox image somehow? thanks, but i don't think i have the time to install virtualbox, download an image, set it up and then tinker with it. maybe someone else does though?
Created attachment 25579 [details] panel settings after change resolution I have similar problem. I start with resolution 1024x768 and I unlock widget. I change resolution to 1280x1024 and I open panel's setting. You can see result in attachment. Second problem is that widget Application Launcher sometimes stoles
Ladislav: that's not the same bug as this one; what version of plasma are you using?
Created attachment 25600 [details] new resolution and panel
Created attachment 25601 [details] new resolution and panel Hi, I think I get the same bug here. I was using kde4.1 beta2 at home, on my notebook's resolution (1280x800). Today I put the notebook on it's dockstation (that is plugged in a 1920x1200 monitor) and started kde. The panel was on it's "original" size (width 1280). I think it's the same bug... BR,
Artur: can you pose your plasmarc file, please? thanks =)
artur: nevermind. i see you have desktop icons still. that means that the version you took that screenshot of predates the support for screen res changing on log in.
Re #13 From Aaron: libplasma1 - 4.0.4-24.1. I'm feeling it as the same problem. Screenshot shows panel setting and I'm not able to rich full width of my screen.
Can someone please resign this bug to kwin to check if they can do anything about it?
it's not a kwin problem either; the fact that both kwin and plasma are affected says it's something lower in the stack. the culprit could be: Qt, and in particular QDesktopWidget (kwin and plasma both use that) xrandr, or it's interaction with Qt (which probably makes it a Qt issue again) x.org driver (not sure how that could be messing this up, though.. probably a very long shot)
Hi, I have a similar problem to Artur. Using KDE 4.1 beta 2 on Kubuntu 8.04.1. My laptop is attached to a docking station and the external monitor has a bigger resolution (1280x1024) than the internal laptop screen (1024x768). When I login after a reboot the panel and the background just use the laptop screen resolution. After turning manually off (using xrandr) the laptop screen plasma is using the full resolution (1280x1024) but only after I login again. I can provide more information if requested. BR
I am using virutalbox with Kubuntu installed with KDE4.1 RC and can confirm I see this issue also when resizing the screen resolution. -Brad
I have the same kind of problem on my openSUSE 11 64-bit KDE: 4.1.00 (KDE 4.0.99 (4.1 RC1+)) "release 13.7" (repository http://download.opensuse.org/repositories/KDE:/KDE4:/Factory:/Desktop/openSUSE_11.0/)
I have similar problem when changing resolution with Nvidia X server setting. I am using a Thinkpad T61 with an external monitor - HP LP2465. It was when I changed the desktop resolution to 1920x1200 when this occured. The KDE crashhandler supplied this info: Application: Plasma arbetsyta (plasma), signal SIGSEGV [?1034h(no debugging symbols found) ### snip #### [KCrash handler] #6 0xb65a8acd in QGraphicsView::mapFromScene () from /usr/lib/libQtGui.so.4 #7 0xb7eb874c in Plasma::Applet::popupPosition () from /usr/lib/libplasma.so.2 #8 0xb311872a in ClockApplet::showCalendar () from /usr/lib/libplasmaclock.so.4 #9 0xb3118c79 in ClockApplet::mouseReleaseEvent () from /usr/lib/libplasmaclock.so.4 #10 0xb657c400 in QGraphicsItem::sceneEvent () from /usr/lib/libQtGui.so.4 #11 0xb65ba6ef in QGraphicsWidget::sceneEvent () from /usr/lib/libQtGui.so.4 #12 0xb659a5ec in ?? () from /usr/lib/libQtGui.so.4 #13 0xb659b843 in ?? () from /usr/lib/libQtGui.so.4 #14 0xb65a1041 in QGraphicsScene::mouseReleaseEvent () from /usr/lib/libQtGui.so.4 #15 0xb65a135f in QGraphicsScene::event () from /usr/lib/libQtGui.so.4 #16 0xb607fecc in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4 #17 0xb608631e in QApplication::notify () from /usr/lib/libQtGui.so.4 #18 0xb7a00cad in KApplication::notify () from /usr/lib/libkdeui.so.5 #19 0xb6af9bc1 in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4 #20 0xb65b27fb in QGraphicsView::mouseReleaseEvent () from /usr/lib/libQtGui.so.4 #21 0xb60d2176 in QWidget::event () from /usr/lib/libQtGui.so.4 #22 0xb63bbb73 in QFrame::event () from /usr/lib/libQtGui.so.4 #23 0xb64459af in QAbstractScrollArea::viewportEvent () from /usr/lib/libQtGui.so.4 #24 0xb65ae79f in QGraphicsView::viewportEvent () from /usr/lib/libQtGui.so.4 #25 0xb6447db5 in ?? () from /usr/lib/libQtGui.so.4 #26 0xb6af8dba in QCoreApplicationPrivate::sendThroughObjectEventFilters () from /usr/lib/libQtCore.so.4 #27 0xb607feaa in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4 #28 0xb6086ca7 in QApplication::notify () from /usr/lib/libQtGui.so.4 #29 0xb7a00cad in KApplication::notify () from /usr/lib/libkdeui.so.5 #30 0xb6af9bc1 in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4 #31 0xb6087fae in QApplicationPrivate::sendMouseEvent () from /usr/lib/libQtGui.so.4 #32 0xb60e51e8 in ?? () from /usr/lib/libQtGui.so.4 #33 0xb60e45a4 in QApplication::x11ProcessEvent () from /usr/lib/libQtGui.so.4 #34 0xb610a3ae in ?? () from /usr/lib/libQtGui.so.4 #35 0xb6af833a in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 #36 0xb6af84fa in QEventLoop::exec () from /usr/lib/libQtCore.so.4 #37 0xb6afa6dd in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 #38 0xb607fd47 in QApplication::exec () from /usr/lib/libQtGui.so.4 #39 0xb7faa3c1 in kdemain () from /usr/lib/libkdeinit4_plasma.so #40 0x08048802 in _start () #0 0xffffe430 in __kernel_vsyscall () ###### snap #####
Bengt, this bug is not and never was about any crashes. Please reopen a new bug since it is dealing with another issue! As for me I tested again with KDE 4.1.2 on Fedora 10 and this bug seems to be solved almost entirely - only the panel itself doesn't enlarge totally. The desktop now reacts as it should!
On 4.1.2, the black bar extends to full size, but the widgets in it are not moved to their new locations.
I think my issue is the same. After having my resolution changed (via xrandr or through running wine) and then back again when I open my kmenu it opens in the top left corner of the screen even though my kmenu is on a panel on the bottom. Also when I right click the context menu is positioned significantly further to the top-left than where I clicked. After restarting x all these problems go away.
I neglected to mention in my previous comment, I'm using KDE 4.1.2
(In reply to comment #27) > I think my issue is the same. I don't think it's the same, but it might be related. As there is no screenshot of what you describe, can you attach one to this report?
Created attachment 27985 [details] New resolution and k-menu placement As you can see, after using xrandr to reduce and then restore the resolution of my screen, the kmenu appears near the top of the screen (about where the bottom would have been under the old resolution) rather than the proper place. I also see the behaviour reported elsewhere, where if I maximize a window it resizes to the size of the window under the old resolution, but I can drag it bigger if the window isn't maximized.
*** Bug 164543 has been marked as a duplicate of this bug. ***
@Aaron: Does that resolution apply to the bug described by my comments as well? (ie. if I open another bug based on my comments will it be marked as a dupe of this one?)
@Stephen: thanks for bringing that to my attention; no, it's not the same as this bug. it is the same as a different (open) bug, however, so you don't need to go through the effort of creating a different report. =)
(In reply to comment #33) > @Stephen: thanks for bringing that to my attention; no, it's not the same as > this bug. it is the same as a different (open) bug, however, so you don't need > to go through the effort of creating a different report. =) > I haven't been able to find this other bug, do you happen to know its # so I can contribute and read the latest developments?
This bug is resolved but I still have problem with panel (http://www.abclinuxu.cz/images/screenshots/5/3/102535-store-for-snapshots-41639.png) - KDE 4.2.96 (KDE 4.3 RC2). Do you have different experience?