Bug 191051 - Increasing maximum panel size does not cause panel to resize
Summary: Increasing maximum panel size does not cause panel to resize
Status: RESOLVED UNMAINTAINED
Alias: None
Product: plasma4
Classification: Plasma
Component: panel (show other bugs)
Version: 4.8.2
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 207306 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-04-29 17:44 UTC by Alan Jenkins
Modified: 2018-06-08 19:04 UTC (History)
18 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot (16.24 KB, image/png)
2009-04-29 17:47 UTC, Alan Jenkins
Details
4.4b2 screenshot (140.07 KB, image/png)
2009-12-29 03:30 UTC, Jacob Welsh
Details
Screenshot 4.8.2 (41.83 KB, image/jpeg)
2012-04-14 20:28 UTC, Alex
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Jenkins 2009-04-29 17:44:56 UTC
Version:            (using KDE 4.2.2)
OS:                Linux
Installed from:    Ubuntu Packages

Decreasing the maximum panel size to smaller than it's current size will cause it to resize appropriately. However, it will not resize if you increase the maximum panel size back to where it was.
Comment 1 Alan Jenkins 2009-04-29 17:47:00 UTC
Created attachment 33213 [details]
Screenshot

Here's a screenshot of my panel after reproducing this.

Observe that the panel is "squashed" to the smallest size allowed; the caret is overlapping the Kickoff icon, which it would prefer not to do, and of course there is lots of hidden panel content which you can't see because it's too small.

If you look at the maximum size indicator, "->|", there's plenty of space for the panel to expand into. But it doesn't :-).
Comment 2 charly ghislain 2009-05-27 03:51:22 UTC
On kde 4.2.87, panel don't try to get a decent size in either direction. You have to play around with the minimum caret to make it grow and the maximum one to make it shrink.
Comment 3 Alan Jenkins 2009-05-27 09:51:25 UTC
Thanks for confirmation.  That's exactly what I meant, but I think you've explained it much better :-).
Comment 4 Leonidas Arvanitis 2009-05-27 11:24:49 UTC
I can confirm this with KDE 4.2.3. Very annoying.
Comment 5 Paschalis Veskos 2009-07-01 19:14:26 UTC
still there in 4.3RC1, especially annoying for a vertical panel that auto hides whose only purpose is to have a few application icons.
Comment 6 Alberto Villa 2009-07-16 05:26:42 UTC
still there in 4.3-rc2
but, when i added the first custom panel, it was working correctly... then, the second one broke it
Comment 7 Ryan Rix 2009-09-14 03:39:29 UTC
Downstream Fedora11 bug report for kde4.3.0: https://bugzilla.redhat.com/show_bug.cgi?id=520666
Comment 8 jb benoit 2009-12-18 22:43:09 UTC
I just tried on kde SC 4.4 beta1, and i don't see the bad behavior. It expanded and became smaller after closing the window, just as i expected.
Comment 9 Alan Jenkins 2009-12-19 15:29:32 UTC
Seems to be fixed in Ubuntu 9.10 (kdebase-plasma 4:4.3.2-0ubuntu3).
Comment 10 Jacob Welsh 2009-12-29 03:30:26 UTC
Created attachment 39420 [details]
4.4b2 screenshot

Not fixed as of 4.4 beta 2 (built from trunk yesterday). It's better than it was - the panel expands when the max handle is increased - but not always to the full "preferred" size, leaving some of the widgets squished or cut off. The size it expands to seems to change every time I fiddle with the handles.
Comment 11 Lasse Liehu 2010-01-02 14:31:44 UTC
Confirmed. Not completely fixed in KDE 4.4 beta 2, Qt 4.6.0.
Comment 12 charly ghislain 2010-01-29 14:30:04 UTC
I can't reproduce this on recent svn versions, the restricitions imposed by the handlers seems to work fine.
Comment 13 charly ghislain 2010-01-29 15:06:19 UTC
Ignore my previous comment, I ran into this bug again after doing strange stuff with the panel and systray.
Comment 14 disabled account 2010-01-29 20:34:39 UTC
*** Bug 207306 has been marked as a duplicate of this bug. ***
Comment 15 disabled account 2010-05-23 03:25:33 UTC
Still present in KDE SC 4.4.2.
Comment 16 disabled account 2010-06-08 04:10:37 UTC
And also still present in 4.5 Beta 1, although it seems to have slightly improved.
Comment 17 Marco Martin 2010-06-12 11:12:50 UTC
a possible fix for this was put in -post- beta2 please check when there will be at least rc1
Comment 18 Alex 2011-02-10 20:12:19 UTC
This is still a problem with 4.6.0.
Comment 19 Gregor Tätzner 2012-04-14 12:58:38 UTC
I have played a litte bit around on kde 4.8.2 and it seems fine. Do you still have this issue?
Comment 20 Alex 2012-04-14 19:09:22 UTC
The issue is only half solved for me.  The icon DOES reflects the correct mute state, however the check box in the right click context menu of the icon does NOT reflect the correct mute state.

Simply left click on the icon, mute via the volume popup, then right click the icon and observe the wrong value for mute in the context menu.
Comment 21 Gregor Tätzner 2012-04-14 20:03:26 UTC
what are you talking about? Sry, but I can't follow you.
Comment 22 Alex 2012-04-14 20:07:37 UTC
Wrong bug ;) sorry
Comment 23 Alex 2012-04-14 20:28:06 UTC
This bug is still a problem for me with the re sizing.  Its better than it use to be at 4.8.2 but it still cuts stuff off when it is sized to smaller than the panel needs to be.  Screen shot attached shows the trash can disappearing off the edge.
Comment 24 Alex 2012-04-14 20:28:39 UTC
Created attachment 70383 [details]
Screenshot 4.8.2
Comment 25 Andreas Sturmlechner 2013-06-30 20:13:11 UTC
This seems to be exactly the same as in bug 248186 except the latter has gotten more attention (but is still not solved)
Comment 26 Wolfgang Bauer 2013-07-05 12:26:16 UTC
The resize code does have some strange behaviour indeed.
Create an empty panel to check.

- Make it smaller with the maximum size slider and enlarge it again, the panel (and the minimum size slider) stays at the smaller size (well, that may be intended, but there should be a way to move both sliders at once), this is what this bug report is about originally IIUIC. And this is still reproducible in 4.10.5 and 4.11 Beta2.

- With just a systray plasmoid, the minimum slider doesn't have any effect anymore except to make it bigger again. The systray happily stays with a size somewhere between the minimum and maximum size sliders without apparent reason. It seems the systray applet sets its minimum size to big (maybe it also accounts for the hidden icons?)
But I will file a new bug report for this...
Comment 27 Wolfgang Bauer 2013-07-05 12:30:50 UTC
(In reply to comment #26)
> but there should be a way to move both sliders at once),
Oh wait, there is!

Just enlarge the size using the minimum slider instead of the maximum slider. The latter one then moves as well.

It's just a bit unexpected that if you keep dragging around the maximum size slider the panel gets smaller but not bigger again.
Comment 28 Wolfgang Bauer 2013-07-05 13:06:21 UTC
(In reply to comment #26)
> - With just a systray plasmoid, the minimum slider doesn't have any effect
> anymore except to make it bigger again. The systray happily stays with a
> size somewhere between the minimum and maximum size sliders without 
I just want to add that after REMOVING that systemtray widget again, the panel still remembers that minimum size. So you can't resize it smaller than that with the minimum size slider, although you could before adding that plasmoid.
Comment 29 Jacob Welsh 2013-07-05 18:41:07 UTC
> - Make it smaller with the maximum size slider and enlarge it again, the
> panel (and the minimum size slider) stays at the smaller size (well, that
> may be intended, but there should be a way to move both sliders at once),
> this is what this bug report is about originally IIUIC.

No. Look at any of the attached screenshots. The panel should pick a size between the min and max sliders such that all widgets are displayed at their "ideal" sizes with neither clipping nor empty space. This is clearly what it's trying to do, but often fails, seemingly at random. It's unrelated to systray: on a panel without systray or task switcher, I can still get it to cut off the clock, even though it has room to grow, just by jiggling the min slider.

IMO the sliders are not the greatest UI concept in the first place. Anyone using a non-maximized panel is likely going for the behavior of XFCE or OS X Dock, where the panel picks the ideal width without user intervention. But if we're going to have resizable panels, they should at least work predictably.
Comment 30 Leonidas Arvanitis 2013-07-05 19:31:15 UTC
(In reply to comment #29)
> IMO the sliders are not the greatest UI concept in the first place. Anyone
> using a non-maximized panel is likely going for the behavior of XFCE or OS X
> Dock, where the panel picks the ideal width without user intervention.

+5 ... not just +1
I have no hard numbers but I bet the vast majority of users expect a non-maximized panel to be auto-sized optimally without further fiddling.

> But if we're going to have resizable panels, they should at least work
> predictably.

Of course the option to manually tweak it (in a way that works predictably) would still be useful.
Comment 31 Nate Graham 2018-06-08 19:04:03 UTC
Hello!

This bug report 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 bug is already resolved in Plasma 5.

Accordingly, we hope you understand why we must close this bug report. If the issue described  here is still present 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