In D26379#586767, @ngraham wrote:

Would it make more sense if it was like this?

Popup: (o) Show near notification icon
       ( ) [Choose custom Position...]
       Hide after: [5 seconds ^v]

Within that context, I see why it makes sense to indent "Toggle with", but I still don't think it makes sense to indent "Hide after"/"Hide popup after". The label above is "Popup position" and "Hide popup after" is not related to the popup position.

Is it intentional that "Hide after" is aligned with the checkboxes above? I'm not convinced this part is an improvement. Same with the indented "Toggle with" although that was there to begin with.

Apparently there were prior discussions that I forgot about because they weren't written down. The consensus seems to be that the font size and scaling should be set by default based on the physical DPI.

In D26304#585525, @ouwerkerk wrote:

This completely alters one of the core propositions of how a Kirigami UX works. I may be mistaken, but if I understand it correctly drawers are supposed to be accessible via buttons. If gestures conflict, why remove page row navigation by gesture rather than drawer gestures?

For the Inkscape optimized svg gradient problem: https://gitlab.com/inkscape/inbox/issues/1121

Just needs some optimization and copy the files to icons-dark, then it'll be good to go

Yet another thing to consider:
Where should the hot corner for Present Windows go if we put the panel on the left?

• If we keep it on the top left, it'll get in the way when people want to use the menu.
• If we move it to the top right, it'll get in the way when people want to close a window.
  • We'll have to move the window buttons to the left if we do this, just like Unity and my screenshot.
• If we move it to the bottom left, it's mostly out of the way, but it could get in the way when people go to minimize all windows. It's also a change just to accommodate another change.
• If we move it to the bottom right, it's also mostly out of the way, but I would not be surprised if many people (besides myself) put their mouse cursor there as a resting place. It's the only place on the screen where the mouse cursor is almost completely hidden.

Here's how it looks on my system:

We should also consider how well increasing the panel thickness will work for 1366x768 displays since those are extremely common. I had a display with that resolution on my last laptop and I know I used a side panel because the vertical space was always very limited. I don't remember if I increased the thickness of my panel, but I think I did so that the systray would switch to using 2 columns and give me more space for apps.

What would really determine whether or not this is a good idea would be some usability testing, but I'm not sure how we would test something like this. It's a rather small difference that seems to be more a matter of preference and what one is used to. I'll try to see if I can get some people I know to switch to having the panel on the side and report back in a week, then maybe again after another week.

I know all this is very off-topic, but I'll answer anyway. Just please don't add more off-topic questions to the task discussion. This isn't a forum for posting rants.

Nice work!

In D26234#584620, @meven wrote:

I feel the "raise maximum volume" button does not need to be always visible as most users won't ever use it, instead the mute toggle could use the space.

Visually, LGTM

I'm a fan of the Unity layout and I like using a side panel. That's not a good justification for giving this a +1, but Unity was very well optimized for laptops (in UI design) and laptops are the most common type of PC these days.

• use frameRadiusForNewPenWidth

In D26267#584396, @hpereiradacosta wrote:

-1:
if QWeakPointer::data() is obsoleted, (while needed in the code), I would object to adding toStrongRef, in between, since as pointed out by Antony, calling data immediately after brings no further security, and just results in some overhead (Weak to shared pointer). It means that either

• weakPointer::data should not be obsoleted
• the kdecoration api should be changed (to return shared pointers, or provide direct access to the data).

Thank you for pointing those out. I don't have a lot of experience, so this helps a lot.

Review summary area:

In D25889#584040, @apol wrote:

I'm not convinced about using emoji in place of icons. Are we sure about that?

I like ndavis's suggestion, but as a delegate, having so many lines could look cluttered.

Should we consider using cards?

• Change newPenWidthFrameRadius to frameRadiusNewPenWidth

Change comment formatting

• Change newFrameRadius to newPenWidthFrameRadius

Change symbol pen width back to 1.1

In T12192#215384, @hein wrote:

In T12192#215248, @ndavis wrote:

Should it be possible to configure the icon size for grid view?

Let's not go crazy and try to do the 3.0 before the 1.0 :). These mockups were a lot simpler a few weeks ago, and I'm already a bit unsure if the increase in complexity was warranted. Let's start with something lean and make very careful adjustments thereafter, or we'll end up with a kitchen sink menu again.

Another thing to consider is whether or not the review section in Discover should be kept consistent with the reviews/comments in the new GHNS UI.

In D25889#577558, @ngraham wrote:

I find that the current one takes up too much vertical space and the top line of text blends too much into the review itself. I feel like those issues should be addressed somehow. Maybe this isn't the right way, so suggestions would be appreciated.

In D26238#583390, @trmdi wrote:

In D26238#583389, @ndavis wrote:

In the plasma panel context menu, add widgets and edit panel are below the separator

Maybe I need to create a new separator at the line 126 instead of reusing it. Is it ok if there are 2 separators in a context menu?

In the plasma panel context menu, add widgets and edit panel are below the separator

This seems inconsistent with the Plasma panel context menu:

Should it be possible to configure the icon size for grid view?

Change comment formatting

Add default value to frameRadius penWidth

In T12192#214869, @ngraham wrote:

In T12192#214863, @hein wrote:

• I kind of still like the pagination that the original Simple Menu does. I'm considering having lists be vertically scrollable, but use the pages for the icon views.

Maybe I'm fighting the tide here bug I really hate pagination vs scrolling. Are there any concrete advantages to pagination or is it just a stylistic judgment call?

In T12192#214863, @hein wrote:

Some notes while I start working on implementation:

• Currently I'm planning to have a "Recent" section on both the Apps and Files tabs, though it's not included in the mockups.

Those are pretty slick. What do the overflow menus contain?

@manueljlin yes, that'll work nicely

In T12412#214711, @manueljlin wrote:

In T12412#214707, @ndavis wrote:

What's in the popover's overflow menu?

A list that displays HSL, RGB and Hex

Question to other designers:
Do you like the multi-dimentional colorpickers? Not sure what to call them, but I mean stuff like the color picking box seen in this mockup, in KColorChooser and the triangle+wheel you see in Krita.

BTW, you accidentally used the HiDPI version for both versions

What's in the popover's overflow menu?

In T11713#214694, @davidre wrote:

But it's not only about Plasma right? KColorScheme can also be used by applications. For example the complementary colors are especially targeted at applications if you read the documentation.

Complementary: I don't think any of these are used.

Quick lxr search, for example:
kdeconnect uses Kirigami.Theme.complementaryTextColor
ktouch uses it
as does kdenlive

When you think about reorganizing please note that all these enums are part of the public API of a frameworks library.

In T12372#214462, @pedrogomes1698 wrote:

We can always not having anything on top.

It's not that the mockup is bad, it's that the current design isn't bad either. If the current design needs to be improved, it can be improved without throwing it away.

I still think a redesign is completely unnecessary.