Bug 321849

Summary: "Force row settings" does not work anymore for small panel heights
Product: [Plasma] plasma4 Reporter: Kåre Särs <kare.sars>
Component: widget-taskbarAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: dweeble01103, hein, m.wege
Priority: NOR    
Version: 4.10.90   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:

Description Kåre Särs 2013-07-02 04:08:14 UTC
"Force row settings" used to force the selected max row amount regardless of the height of the taskbar. In the new QML version the force row settings does not force the row count if the height is lower than two times the default minimum height.

Reproducible: Always

Steps to Reproduce:
1. Check the Force row setting
2. Reduce the taskbar height
3.
Actual Results:  
The row count goes down to 1

Expected Results:  
The "Force row setting" should allow the user to have selected number of rows even if it looks ugly. It is a conscious choice ;)
Comment 1 Eike Hein 2013-07-02 04:13:38 UTC
The rewrite intentionally does not allow row configurations for which insufficient space is available. I don't intend to offer and support "break the product" configuration options, so no, ugly is not a choice, sorry ...
Comment 2 Kåre Särs 2013-07-02 05:19:14 UTC
OK,

What is that option supposed to do if it is not forcing the row settings?

With my current setup the only time the option has an efect is when I have less than 9 windows open. And the panel is now ~30% higer than what I have been used to.

What can I do to workaround my +30% size problem?

Regards,
  Kåre
Comment 3 Eike Hein 2013-07-02 05:34:15 UTC
There's two settings that act in concert: A number-of-rows setting, and the force rows setting. The former is effectively a cap: By default, the Task Manager will try to use the minimum number of rows, making tasks smaller to fit more of them into a row, unless the tasks narrow below a certain threshold, then it will overflow them into additional rows, as space and the number-of-rows setting permit. Enabling the force rows setting changes the behavior to try to always distribute tasks over the specified number-of-rows, as space permits.

In other words, if you have nine tasks and configure the Task Manager to use three rows and there is sufficient vertical and horizontal space available, it would normally still use only one row - but when you enable force rows, it will instead always distribute them over three rows, at three tasks each. This has consequences for the sizing behavior of the tasks, and also the size hints generated for the Task Manager as a whole (i.e. when putting it into an opportunistically growing panel).

The reason I don't want to budge on the "as space permits" requirement are the following:
- It simplifies the code, reducing the number of behave-differently-depending-on-setting codepaths in the layout code. The old layout code was very buggy partly due to its overboarding complexity, and I'd prefer to keep it simpler and less error-prone this time around.
- I really don't see a point in supporting config options that lead to broken-looking appearance.

Now, as for your situation: There's another difference between the old and the new applet, namely that the new code is much stricter about correct behavior when it comes to applying the theme. In the new code, the icon and the text label are placed within the theme's frame decoration, and the sizes of that frame decoration are respected as margins in the overall task button. In turn, the minimum height for a row is derived from the font metrics for the text label, the icon size, and those margins. The old code OTOH did not respect the frame decoration sizes, both in calculating the minimum row height and in icon and text scaling. That's why the minimum row height in the new applet is a bit larger.

I'm still considering making the minimum height as well as the scaling code a bit more complex again to serve very small panel sizes better. The current code has the benefit of being correct and simple and making things predictable and easy for theme authors, but I also don't want to force people to change their panel setups too much upgrading from 4.10 to 4.11, so a little compromising probably has to be done. Things like that are best done only after a need has been identified though - as perhaps it has now, here - otherwise it's premature optimization :).
Comment 4 Kåre Särs 2013-07-02 05:58:34 UTC
Thank you for your response!

I think users have worked around unnecessarily large margins in themes by fording the rows.

I think it is very hard to make a theme that looks good both on high and low taskbars. With high taskbars you need more margins around the text but on low ones you usually want less.

In the mean time I have searched for a minimalistic theme and now I'm using Aya as base and the task items from Plateau.

Thanks,
  Kåre

PS. Now with the QML implementation is it also much easier to modify things locally :)
Comment 5 Eike Hein 2013-07-27 17:14:36 UTC
*** Bug 321257 has been marked as a duplicate of this bug. ***
Comment 6 Eike Hein 2013-07-29 07:39:37 UTC
Git commit b2708f218a54573bed501f57f812f4630d4bde8e by Eike Hein.
Committed on 29/07/2013 at 07:25.
Pushed by hein into branch 'master'.

Sizing threshold tweaks.

This reduces the preferred minimum height of items to barely above
the font's M size, allowing layout to break into additional rows
far sooner. Additionally, the scaling curve for icons is fudged to
allow the icon to overrun a bit into the frame margins at very low
item heights. Together this answers the clamor for supporting very
space-constrained forced multi-row configurations similar to the
old applet's behavior, while still trying to look not quite as bad
in the process.

Not very happy about introducing some fixed pixel values into the
calculations, but between the poor support for font metrics in QML
and tweaking things for scenarios in which single pixels matter,
it's inevitable for now.

M  +2    -1    plasma/desktop/applets/tasks/package/contents/code/layout.js
M  +1    -1    plasma/desktop/applets/tasks/package/contents/ui/GroupDialog.qml
M  +3    -2    plasma/desktop/applets/tasks/package/contents/ui/Task.qml

http://commits.kde.org/kde-workspace/b2708f218a54573bed501f57f812f4630d4bde8e
Comment 7 Eike Hein 2013-07-29 07:47:20 UTC
Git commit 546b8fce0278f3046eb26df2c03d75fdf6f9f035 by Eike Hein.
Committed on 29/07/2013 at 07:25.
Pushed by hein into branch 'KDE/4.11'.

Sizing threshold tweaks.

This reduces the preferred minimum height of items to barely above
the font's M size, allowing layout to break into additional rows
far sooner. Additionally, the scaling curve for icons is fudged to
allow the icon to overrun a bit into the frame margins at very low
item heights. Together this answers the clamor for supporting very
space-constrained forced multi-row configurations similar to the
old applet's behavior, while still trying to look not quite as bad
in the process.

Not very happy about introducing some fixed pixel values into the
calculations, but between the poor support for font metrics in QML
and tweaking things for scenarios in which single pixels matter,
it's inevitable for now.

M  +2    -1    plasma/desktop/applets/tasks/package/contents/code/layout.js
M  +1    -1    plasma/desktop/applets/tasks/package/contents/ui/GroupDialog.qml
M  +3    -2    plasma/desktop/applets/tasks/package/contents/ui/Task.qml

http://commits.kde.org/kde-workspace/546b8fce0278f3046eb26df2c03d75fdf6f9f035
Comment 8 YAFU 2013-08-17 19:10:37 UTC
>>but I also don't want to force people to change their panel setups too much upgrading from 4.10 to 4.11

I'll have to change my settings because I do not really like the look of the size of the panel in KDE 4.11:
http://forum.kde.org/viewtopic.php?f=67&t=117046
@Eike Hein, anyway thanks for working on the new task manager to try to fix the bugs in old task manager. If you can make the panel may have a smaller height with two rows without compromising other aspects, it would be very good.
Thank you!

Kubuntu 12.04 64 bits - KDE 4.11.00
Comment 9 Eike Hein 2014-02-06 16:48:51 UTC
*** Bug 330842 has been marked as a duplicate of this bug. ***