Bug 466566

Created attachment 156809 [details]
Kicker button - Proper size

This has the proper button size
PLEASE do not change all buttons to be square, that takes up too much space

> PLEASE do not change all buttons to be square, that takes up too much space
Sorry, this is the new design goal, as making some buttons mysteriously remain rectangles for no clear reason confused the heck out of a lot of people and we go no end of bug reports about it.

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

(In reply to Nate Graham from comment #2)
> Sorry, this is the new design goal, as making some buttons mysteriously
> remain rectangles for no clear reason confused the heck out of a lot of
> people and we go no end of bug reports about it.

I suspect the new behaviour is also going to confuse the heck out of a similar number of people, and you'll get no end of bug reports about it (as evidenced by my own duplicate Bug 467004).  If there are legitimate use cases for both sizing policies, why not make the sizing policy user-configurable in the Appearance module of the Application Launcher Settings dialog?

Fortunately most people don't use enormously thick panels so hopefully the impact will be limited. But yet, if this is wrong and a lot of people have this configuration and complain about it, we can consider making the new sizing optional.

Relatedly, this is the downside of our data-poor and off-by-default telemetry; we don't know this kind of thing until people complain about it!

> Sorry, this is the new design goal, as making some buttons mysteriously remain rectangles for no clear reason confused the heck out of a lot of people and we go no end of bug reports about it.

Well I hope this doesn't affect the icons-only task manager as reported in Bug 460877.

And while I understand the design goal, I personally haven't seen any buttons that 'mysteriously remain rectangles for no clear reason.'
The same argument could be easily applied to the 'Minimize all Windows' / 'Peek at Desktop' button, but it is still a rectangle.

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

Sorry for the duplicate, for some reason my search did not turn up with this one. I was probably searching for open issues.

(In reply to Nate Graham from comment #2)
> Sorry, this is the new design goal, as making some buttons mysteriously
> remain rectangles for no clear reason confused the heck out of a lot of
> people and we go no end of bug reports about it.

I would really like you to reconsider this new design goal. As it confused the heck out of me why that button became so large. 

(In reply to Nate Graham from comment #5)
> Fortunately most people don't use enormously thick panels so hopefully the
> impact will be limited. But yet, if this is wrong and a lot of people have
> this configuration and complain about it, we can consider making the new
> sizing optional.
> 

There are several of us out there that use vertical panels, at least 3.

If we're talking user expectations, users would expect one of the following, in order of most likely behavior:

1. The same height as Task Manager (icons). This is the behavior users are used to in a variety of desktop environments.
2. Some arbitrary height that looks good.
3. The height of the icon that is used for that widget. (I know, good luck with vectors, but hey, it is user expectation) 
4. I don't think there is a 4th expectation for this particular widget. Just kidding, I guess it actually makes a lot of sense for horizontal panels. However, I suspect the widget would become rather small on slim horizontal panels. 

For me any default behavior chosen is a not really an issue, as long as I can change it. So a toggle would be nice, a toggle and an input where I can specify the desired size (width for horizontal, height for vertical) or scale would be better.

> Relatedly, this is the downside of our data-poor and off-by-default
> telemetry; we don't know this kind of thing until people complain about it!

Never change. The least we as users can do is give some constructive feedback.

So basically the issue here is that when you're using a super thick panel (let's say 100px or thicker), widget icons can become "too large" and hence take up to much space, for some definition of "too large." This definition will change depending on the person and their design goals for their panel. People are more likely to have super thick vertical panels than super thick horizontal panels, so the issue is seen more often with super thick vertical panels.

Let's start with a little history:

In the past, there was a setting to control the maximum size that panel widget icons could grow to; this was the "Panel" icon size exposed in the System Settings icons KCM. Unfortunately it suffered from several issues:
1. The UI did not do a good job of explaining that this is what the setting was for, so people didn't understand that it was a *maximum* size.
2. The setting defaulted to too small a size, so people had the experience of making their panels thicker but not *that* much thicker, then icons wouldn't grow appropriately, and they would complain and submit bug reports.
3. The setting lived in System Settings rather than somewhere in Plasma, so it was quite disconnected from the thing it controlled and almost no one ever actually found it unless directed to it by a bug triager after submitting a bug report about icons not growing as they expected.
4. Not all Panel widgets respected the setting in the first place; so adjusting it produced random-seeming results.

For these reasons, we decided to remove the setting and just make all Panel icons grow with the panel thickness. Less code, easier to understand, fewer bugs. Job's done!

But now we have people with super thick vertical panels complaining, and that setting we've removed would have given them a knob to turn to self-satisfy. The panel thicknesses in question are thick enough that a huge icon looks awkward, but not so thick that the entire widget's FullRepresentation can be substituted.


We have a few options:
1. Bring back the "Maximum panel icon size" setting, but fix the issues that caused us to remove it: clarify in the UI what it does, default to "unlimited/scale with panel" size, put it on the Panel settings menu rather than in System Settings, and make it universally applicable to all 1st party widgets at least. Cons: a lot of work; universality would still be elusive since 3rd-party widgets wouldn't necessarily respect it.

2. Add per-widget settings for 1st-party widgets to control the maximum icon size as needed. For some reason people only ever seem to complain about this issue as it applies to their launcher menu widgets, so maybe it will be enough to do this for Kickoff, Kicker, and Application Dashboard. Cons: lots of code duplication if we end up implementing it for multiple widgets; worse UX if you want to make this change for all the affected widgets on your panel; universality would still be elusive since 3rd-party widgets have to implement the same code.

3. Internally hardcode a maximum icon size for all affected panel widgets to try to fix this use case without the need for explicit configurability. Cons: undocumented magical sizing behavior; *someone* will always find something that doesn't work for them personally; universality would still be elusive since 3rd-party widgets would have to implement the same code.

4. Do nothing, and accept that super thick panels will suffer from this UI papercut.

> 2. Add per-widget settings for 1st-party widgets to control the maximum icon
> size as needed. For some reason people only ever seem to complain about this
> issue as it applies to their launcher menu widgets, so maybe it will be
> enough to do this for Kickoff, Kicker, and Application Dashboard. Cons: lots
> of code duplication if we end up implementing it for multiple widgets; worse
> UX if you want to make this change for all the affected widgets on your
> panel; universality would still be elusive since 3rd-party widgets have to
> implement the same code.

We might explore this solution, a "per-applet size setting", but implemented as a sizing handle on the panel edit mode (not as a specific configuration the applet has to provide).  If only, some properties or hints would be required for the applets to "opt-in". That would be similar to what we do now with applet pop-ups resizing. 

It would act as a Layout.Preferred/Maximum size, and potentially also solve the sizing problem with two full-width competing widgets on the same panel (ex. Menubar + Taskmanager).

Ideally it should be useful but not overwhelming, that is, defaults should still suffice for the majority of the cases.

(In reply to Ismael Asensio from comment #10)
> > 2. Add per-widget settings for 1st-party widgets to control the maximum icon
> > size as needed. For some reason people only ever seem to complain about this
> > issue as it applies to their launcher menu widgets, so maybe it will be
> > enough to do this for Kickoff, Kicker, and Application Dashboard. Cons: lots
> > of code duplication if we end up implementing it for multiple widgets; worse
> > UX if you want to make this change for all the affected widgets on your
> > panel; universality would still be elusive since 3rd-party widgets have to
> > implement the same code.
> 
> We might explore this solution, a "per-applet size setting", but implemented
> as a sizing handle on the panel edit mode (not as a specific configuration
> the applet has to provide).  If only, some properties or hints would be
> required for the applets to "opt-in". That would be similar to what we do
> now with applet pop-ups resizing. 
> 
> It would act as a Layout.Preferred/Maximum size, and potentially also solve
> the sizing problem with two full-width competing widgets on the same panel
> (ex. Menubar + Taskmanager).
> 
> Ideally it should be useful but not overwhelming, that is, defaults should
> still suffice for the majority of the cases.

This solution would be the Rolls Royce in my opinion. Actually, one of the first things I checked for when I was confronted with my new Kickoff button was whether I was allowed to resize it in edit mode by dragging its edge. So there is at least some intuitivity with this.

Implementing this could also benefit other widgets. For me it would be a "nice to have" if I could increase the size of "Pager" as an example. (don't consider this a feature request, I'm just brainstorming)

While consistency is important, it might be worth considering this as a preferred size instead of a maximum. If we look at the "System Tray" for example, it would be a "nice to have" if it could be set as a minimum size. Here's why: it has happened several times to me that my Task Manger is "pixels away" from scaling down. Then I'm in a browser tab that starts playing media and the System Tray expands its size because of that extra icon. This causes the Task Manager to scale down and up again. Since the number of System Tray items is rather constant for me, just reserving space for those one or two extra icons would be nice. (again, not a feature request, just brainstorming)

In the end I think everyone would benefit, if I were to put my launcher on a horizontal panel again I would appreciate that I could make the "clickable surface" wider than my panel height.

Yes, that does sound like a good solution that would solve other problems as well. Re-opening.

(In reply to Nate Graham from comment #12)
> Yes, that does sound like a good solution that would solve other problems as
> well. Re-opening.

I'm very glad to hear that. I've been thinking about how this feature could work. I don't use a lot of different widgets so I may be overlooking some use cases but I have a suggestion on how this could work, generalized:

1. There must be some sane minimum size (width for horizontal panels, height for vertical panels) so you can't make a widget disappear.
2. Widgets should probably be able to specify their own minimum size, I guess based on some scale against the other axis.
3. Widgets might want to specify a default size, again based on some scale, larger than their minimum, but some "sane" size to match user expectation/design goals.
4. Widgets might want to specify a maximum size if scaling beyond a certain ratio doesn't make sense or isn't supported.
5. Widgets should be allowed to grow beyond their minimum size (either their advertised minimum size or the user specified minimum size), see my System Tray example above.
6. Depending on how well this all works in general (how well do most widgets handle/scale with the extra surface area) widgets should be able to either opt-in or opt-out of this feature.

To me it seems a minimum size is the way to go, but maybe someone else could come up with an example where a "user specified maximum" size would be preferred.

(In reply to Nate Graham from comment #12)
> Yes, that does sound like a good solution that would solve other problems as
> well. Re-opening.

I'm really glad you reopened this. I also reported this problem a while back here: https://bugs.kde.org/show_bug.cgi?id=465099

It is not just the Application Launcher that is affected but also other widgets like the Clock, System Monitor and the Workrave Applet. The vertical size of these widgets is far too big for a wide vertical panel (my panel is 200 pixels wide). I really look forward to a solution to this.

(In reply to mcarans from comment #14)
> (In reply to Nate Graham from comment #12)
> > Yes, that does sound like a good solution that would solve other problems as
> > well. Re-opening.
> 
> I'm really glad you reopened this. I also reported this problem a while back
> here: https://bugs.kde.org/show_bug.cgi?id=465099
> 
> It is not just the Application Launcher that is affected but also other
> widgets like the Clock, System Monitor and the Workrave Applet. The vertical
> size of these widgets is far too big for a wide vertical panel (my panel is
> 200 pixels wide). I really look forward to a solution to this.

I facing same situation, even with my vertical panel being just 78 pixels wide. This logo is just too big and grabs space, which I otherwise would be utilizing to fit more tasks in task manager.

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

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

Coming here from https://bugs.kde.org/show_bug.cgi?id=477813 and after upgrading to the 6.0.1 release

Operating System: Arch Linux rolling
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.7.8-arch1-1 (64-bit)
Graphics Platform: Wayland

In plasma 5 it was fine to use a vertical panel without having a huge button.  My button is now huge like in the before/after here: https://bugsfiles.kde.org/attachment.cgi?id=163684 (pic from earlier beta, the rest of the panel is better now).

>  most people don't use enormously thick panels 
:(  I don't see how 200-250 pixel wide is enormous at all. This is basically on par to the experience of vertical tabs in Vivaldi, edge, or firefox with Sidebery, or any browser using tree-style-tabs. I've been using this with plasma for years. 

From the linked screenshot above, note how the desktop pager widget with 3 desktops can be both wide and not tall. Since the desktop pager is a non-square rectangular widget in a vertical panel, can't other widgets be that shape too?

Various things tried:
- I tried creating a custom thin icon but it still pads it out square.
- I spent 5 mins trying to shrink the vertical panel so that there is a gap between the top of the screen where I could add a tiny horizontal panel. Somehow I can shrink the panel only on the bottom part, and no matter what I try with Panel settings > custom height and alignment > top/center/bottom, I can't get it to move down. It's super un-intuitive.

Ideas:
- if a custom rectangular icon is provided, don't force it to take a square shape
- a checkbox in the application menu (or alternatives) setting to enable/disable whatever changed in the square design goal...
- option in the application menu (or alternatives) to explicitly set max width or height for the square icon. Keep it a square, but just don't fill the whole available space
- a new kind of widget that is like a vbox/hbox container that is almost like a panel. Something that would be like being able to put 3 widgets in a rectangular layout just like the 3 small rectangles in the desktop pager. Like a panel you can put in a panel.  Then that gives a constrained container to make a small button menu. You can add widgets or stretch or spacers

Meh I'll just go see if I can find the thing to revert in the qml files and make it a post-install patch need be.

For my vertical panel homies, the quick hack to fix this is to edit 
/usr/share/plasma/plasmoids/org.kde.plasma.kicker/contents/ui/CompactRepresentation.qml

in function updateSizeHints() after it says 
            root.Layout.minimumWidth = -1;
            root.Layout.minimumHeight = -1;
add
            root.Layout.maximumHeight = 30;
            root.Layout.maximumWidth = 30;

Or even make it 1x1. Who needs the icon wasting space anyways? I just want to press Super and get the menu.


For full context, this is what the key change was in plasma 5 to 6 in CompactRepresentation.qml

                 const scaledHeight = Math.floor(parent.width * (buttonIcon.implicitHeight / buttonIcon.implicitWidth));
                 root.Layout.minimumHeight = scaledHeight;
                 root.Layout.maximumHeight = scaledHeight;
-                root.Layout.minimumWidth = PlasmaCore.Units.iconSizes.small;
-                root.Layout.maximumWidth = inPanel ? PlasmaCore.Units.iconSizeHints.panel : -1;
+                root.Layout.minimumWidth = -1;
             } else {
                 const scaledWidth = Math.floor(parent.height * (buttonIcon.implicitWidth / buttonIcon.implicitHeight));
                 root.Layout.minimumWidth = scaledWidth;
                 root.Layout.maximumWidth = scaledWidth;
-                root.Layout.minimumHeight = PlasmaCore.Units.iconSizes.small;
-                root.Layout.maximumHeight = inPanel ? PlasmaCore.Units.iconSizeHints.panel : -1;
+                root.Layout.minimumHeight = -1;
             }
         } else {
-            root.Layout.minimumWidth = PlasmaCore.Units.iconSizes.small;
-            root.Layout.maximumWidth = inPanel ? PlasmaCore.Units.iconSizeHints.panel : -1;
-            root.Layout.minimumHeight = PlasmaCore.Units.iconSizes.small;
-            root.Layout.maximumHeight = inPanel ? PlasmaCore.Units.iconSizeHints.panel : -1;
+            root.Layout.minimumWidth = -1;
+            root.Layout.minimumHeight = -1;
         }
     }

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