Bug 186267 - Taskbar does not adapt to changing screen size
Summary: Taskbar does not adapt to changing screen size
Status: RESOLVED DUPLICATE of bug 188728
Alias: None
Product: plasma4
Classification: Plasma
Component: widget-taskbar (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-05 21:34 UTC by hub
Modified: 2009-08-06 00:13 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot depicting the problem. (20.40 KB, image/png)
2009-05-30 16:43 UTC, Kai Wb.
Details

Note You need to log in before you can comment on or make changes to this bug.
Description hub 2009-03-05 21:34:14 UTC
Version:            (using KDE 4.2.0)
OS:                Linux
Installed from:    SuSE RPMs

It seems that since KDE version 4.1 the taskbar does not resize automatically anymore when the screen size changes.

I use KDE on a laptop with a bigscreen at work and just the laptop screen at home.

If the taskbar fills out the bottom of the laptop screen, if only fills it partly on the big screen. I have to manually adjust the size so that the taskbar fills the width of the screen. If I move from the big screen to the small screen, plasma crashes on startup (starting with KDE 4.2).

This behaviour seems to have been introduced in KDE 4.1. The taskbar resized automatically on KDE 3 and KDE 4.0.

% kde4-config --version
Qt: 4.5.0
KDE: 4.2.00 (KDE 4.2.0) "release 102"
kde4-config: 1.0
Comment 1 Aaron J. Seigo 2009-03-05 22:35:58 UTC
the crash, reported elsewhere by you, is fixed.

and it does change size, but requires a working notification system (e.g. xrandr) and in 4.2 kephal working properly.
Comment 2 hub 2009-03-06 01:22:40 UTC
Xrandr works also in my configuration. That is, when I change the screen size with xrandr, the taskbar shrinks and grows accordingly. But dynamically changing screen sizes is not my problem. 

Consider the following situation: being at home and using the small laptop screen. Then shutting down the computer, going to work and starting the laptop with the big screen attached. X immediately recognizes the bigger screen and I don't have to call a special program to use the bigger screen resolution. But the taskbar does not adjust its size.

It seems that the first time the taskbar is started, the code, that is run when xrandr notifies about a screen resolution change, is not executed.
Comment 3 Kai Wb. 2009-05-24 16:23:52 UTC
Hello,
I've got the very same problem:
I'm running KDE 4.2 as provided by Debian Squeeze (testing) and my KDM runs at the resolution preferred by my display (1280x1024). My desktop in my login is set to 1600x1200 though. Everything resizes just fine (wallpaper, plasmoids, etc.) except the taskbar which stays at a width of 1280 px so I have to manually maximize it after every login.

XRandR is working, my X.org server reports protocol version 1.2 with the R300 ATI GPU.

Kind regards,
Kai Wasserbäch
Comment 4 Kai Wb. 2009-05-24 16:27:21 UTC
Just forgot to mention that: Plasmoids and other mini programs can't be moved over the 1280 px barrier after the resize to 1600x1200, they'll just jump back within that imaginary border. I'm not sure if this is related or something different, but it sounds like some virtual framebuffer/screen doesn't get resized properly. Full-screen applications like a maximized browser window are working though.
Comment 5 Dario Andres 2009-05-29 19:47:47 UTC
Does the reporter mean "panel" when saying "taskbar" ? 
Is this related to bug 188728 ?
Thanks
Comment 6 Kai Wb. 2009-05-30 16:43:38 UTC
Created attachment 34127 [details]
Screenshot depicting the problem.

I think that other bug is related/these are duplicates. The attached image shows the problem as I'm seeing it before manually maximizing the taskbar again.

Kind regards,
Kai Wasserbäch
Comment 7 Dario Andres 2009-05-30 16:49:21 UTC
So.. you mean the whole Plasma panel (not only the taskbar). Thanks for the screenshot.
Comment 8 Aaron J. Seigo 2009-08-06 00:13:09 UTC

*** This bug has been marked as a duplicate of bug 188728 ***