Sat, Aug 8
Thu, Aug 6
I'd vote for that, can you create a mockup? Also, is the workspace switcher next to it having any margins applied? Mine is alot more simple, so I don't really know how that would look like. Currently for me it uses almost no margins (and I think I like it).
We can make the plasma icon ignore margins.
Wed, Aug 5
I have two proposals:
- a 44px panel with 22px widgets and 28px task manager
- a 44px panel with 22px widgets and 32px task manager (which would be consistent with applets who extend to panel margins, such as the pager)
I tested out your patches for that and I gotta say, I just think that those 22px Task Manager icons are too small. :( I have to agree with Carl and various other people who have voiced this opinion. Those icons look lost inside their highlight effect backgrounds.
After some discussion with Nate and Noah, these points were agreed upon:
- upstream latte separator
- add separator button
- separator left and right of the tray
- all widgets use 22px icons by default
- 44px panel
- systray stays 22px regardless of the panel size
- option to make systray bigger as well
For me unifying the size of the applets is not something we should strive for. The visual difference in the size of icons allows to communicate a visual hierarchy between elements, e.g. task manager icons are more often used than system trays icons. Maybe as a good compromise, we should try to make the icons have the same height as the clock text, it is still bigger than the previous size but smaller than the current oversized icons and it will make the system trays icon size consistent with the elements near it, that is imho more important than with the rest of the panel.
Tue, Aug 4
Excellent. That looks great.
Agreed. @sandsmark, would you be interested in following up with that?
Thanks for this change !
Can the same be done in the breeze window decoration ? It is strange to have an animation settings there and not in the style.
Mon, Aug 3
Seems like your proposed approach already satisfies 1-3. We'll need to do 5, and maybe discuss whether we should do 4 as well.
All right. To me that suggests a relatively simple implementation:
- Make all widgets/plasmoids use the panel margins and do not add any internal margins of their own
- Increase the default panel margin
- Make the Task Manager ignore panel margins for its highlight effect, but respect them for icons.
- (optional) make the panel margin user-adjustible/overridable somewhere so that people who like bigger icons can get them without breaking size consistency. This could be exposed through a simplified UI expressed in the form of "Panel icons: smaller/bigger" or something like that.
- Make sure the Digital Clock widget still looks readable with bigger panel margins and our default panel size.
I think our goal is to provide a good balance of icon size consistency and panel aesthetic. The idea of making all icon of the same size is - I think - good, as long as those icons are not excessively big nor small, and I'm afraid that neither 32px nor 22px icon visually work on our default 46px panel when icons are all perfectly the same size. So we have to sacrifice a bit of consistency. With my idea (and, now, implementation) - that 100% looks like Manuel mockup - I think we get a good balance of both:
I'd like to step back here and make sure we define the problem space adequately.
Regarding the technical implementation, I'd make Plasma able to selectively add margin or not for each widget separately; this way all widgets are supported. I wouldn't make the user able to toggle those in the UI yet, we could decide if it's appropriate to add that in the future based on user requests. Right now the plasmoid itself could decide whether to have margin (the default) or not. Task manager really *has* to ignore margin to extend to borders, but then the margins are added back through the task manager internal margins defined in the theme.
Sun, Aug 2
Here's my idea for how it could work:
ICON is a placeholder for the icon size in the applet. Also the same size as the general widget contents (icon, text, etc.) in the panel would be.
Silver ICON: Same as ICON, but for unhighlighted items to convey the icon size on those as well as on highlighted items
Dark Grey: Highlighted Widget/Item
White: Unhighlighted Widget/Item
The task manager ignores margin but we can make it apply internal ones as big as the panel ones, so the icon sizes should still be consistent; Manuel was proposing to downscale 64px app icons to a 22px space, which - considering 32px icon sizes - would be as big as the actual launcher icon:
So we would basically have consistency in the left side and right side, with the right side icons being slightly smaller; I think it's a good approach.
Yeah, though it's starting to feel arbitrary again:
The Application Launcher applet icon is okay, it's just that it looks too small next to the task manager. Imagine having this small icon in Manuel's mockup:
It would be visually unbalanced; it makes more sense to use a 32px here, I guess
That seems like a sensible approach overall. I agree that making is user-facing seems like overkill. As the lone large-system-tray-icon lover, I'm willing to give up my 32px icons on a 46px panel. :) If I have to go up to 50px or higher, that's all right.
It was also suggested to make this setting user-facing (by hovering the widget in panel edit mode); I wouldn't do that yet because this is something very technical that the average user shouldn't want to change sizes, plus it could result in inconsistent sizing in the icons that we'd instead like to be consistent (minimize all, tray, clock, etc). This doesn't mean that we couldn't add it in the future if it turns out to be more necessary than we thought.
Fri, Jul 31
Fri, Jul 24
the thing that triggered my attention on it is the desktop context menu entry:
Thu, Jul 23
Should be working on Wayland as of Plasma 5.18 with improvements in 5.19.
Wed, Jul 22
(well, even ksysguard doesn't have to remain named this ugly way, the rewrite could be an occasion to name it less horribly)
There are several arguments against it:
- the thing that triggered my attention on it is the desktop context menu entry: usually context menus should have actions and description of what the action does as text
I think I agree with Nate here, it is a terrible K name and I've always avoided those but it's also an advanced users feature and those advanced users tend to be fine with K names. "KSysGuard" name should die though.
Tue, Jul 21
In my mind, "KRunner" is a brand name, like the name of an app. I see it as closer to "Dolphin" than for example "Purpose framework". My time in the Apple world exposed me to a similar feature called "Spotlight" which is used as a brand name and exposed to users with that name in the UI. KRunner is basically the same feature, so it seemed natural to similarly advertise it by its real name. I don't see this causing any problems for Apple in macOS.
Mon, Jul 20
I would ask to reconsider this.
KRunner is a terrible jargon name, which is perfectly ok for a framework, but that's it.
This was a terrible decision.
KRunner is the worst jargon one can imagine and shouldn't be anywhere in user facing UI
Fri, Jul 17
Pushed here 38ebcf09b1631175d5a1b4d857622c5313146a60
Thu, Jul 16
Go ahead and land this.
Change makes sense to me, IIRC Kai doesn't have much time for KDE anymore
Wed, Jul 15
Mon, Jul 13
This patch has been migrated to https://invent.kde.org/plasma/kscreen/-/merge_requests/1
Sun, Jul 12
Sat, Jul 11
Jul 11 2020
In general I think it's sub-optimal to maintain two different tools that do essentially the same thing, even if both are working fine. It's confusing for users and it generates extra work for developers. If there are desirable things that KHotkeys can do which KGlobalAccel can't, IMO we should add the missing features to KGlobalAccel and continue with the plan to deprecate KHotKeys.