Bug 191051

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 :-).

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.

Thanks for confirmation.  That's exactly what I meant, but I think you've explained it much better :-).

I can confirm this with KDE 4.2.3. Very annoying.

still there in 4.3RC1, especially annoying for a vertical panel that auto hides whose only purpose is to have a few application icons.

still there in 4.3-rc2
but, when i added the first custom panel, it was working correctly... then, the second one broke it

Downstream Fedora11 bug report for kde4.3.0: https://bugzilla.redhat.com/show_bug.cgi?id=520666

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.

Seems to be fixed in Ubuntu 9.10 (kdebase-plasma 4:4.3.2-0ubuntu3).

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.

Confirmed. Not completely fixed in KDE 4.4 beta 2, Qt 4.6.0.

I can't reproduce this on recent svn versions, the restricitions imposed by the handlers seems to work fine.

Ignore my previous comment, I ran into this bug again after doing strange stuff with the panel and systray.

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

Still present in KDE SC 4.4.2.

And also still present in 4.5 Beta 1, although it seems to have slightly improved.

a possible fix for this was put in -post- beta2 please check when there will be at least rc1

This is still a problem with 4.6.0.

I have played a litte bit around on kde 4.8.2 and it seems fine. Do you still have this issue?

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.

what are you talking about? Sry, but I can't follow you.

Wrong bug ;) sorry

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.

Created attachment 70383 [details]
Screenshot 4.8.2

This seems to be exactly the same as in bug 248186 except the latter has gotten more attention (but is still not solved)

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...

(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.

(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.

> - 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.

(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.

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