In T17408#310026, @ngraham wrote:

I think the solution there is for designers to keep devs in the loop during the design process, to check in and make sure they're not designing something that can't work in practice.

In T17408#309988, @nicolasfella wrote:

You can absolutely design an application layout without knowing how a button looks like. Arguably you even _must_ do that, because how the button is going to look like in the application won't be pixel-for-pixel identical to your design anyway, due to user-specific fonts/font sizes, color schemes, application themes, future design changes etc.

Design needs to accomodate for the fact that our target medium isn't like print where you get to determine 100% how each pixel will look like. There are lots of runtime variables that influence the final result that are out of control for the designer

In T17408#309772, @cullmann wrote:

Does this include the look and feel of applications just on the Plasma desktop or cross platform for stuff using our frameworks? Getting consistent styling over all platforms would be of large interest for me and other application devs.

In T17408#308843, @ngraham wrote:

Ok. So my concern here is that this work will be done to create a visual language and design components for a new, unreleased visual style instead of Breeze.

This would make the work not be actionable for devs until that visual style is actually implemented and rolled out, which will be a multi-year process. But our devs are asking for better visual guidance now, with the current Breeze style that exists today.

How do you feel about making the design components for Breeze in the short term, and then use those to create a mockup toolkit and designs for some of the higher-level components that devs are asking for? You'd gain experience with this process, roll it out to devs, gather feedback, refine your tools and skills. Then later, once the new style gains momentum and the technical underpinning of our new theme engine are in place to make it actionable to implement, you can use what you've learned there to do it again.

What do you think?

In T17408#308833, @ngraham wrote:

Ok, so what I'm hearing is that because you designers don't have a mockup toolkit of basic components that shows their metrics, colors, states, etc, you can't use them to design higher level components. And that creating the former (which is the stated second step of this Goal) is necessary before before we can ask you to do the latter.

Would that be accurate?

In T17408#308811, @ws wrote:

I was specifically thinking about buttons when I said we don't have them in a manner that designers can understand.

We have buttons in "dev space", not in a Designer space. Is there anywhere at all that describe the color, padding, corner radius, effects on interaction states without having to delve into code?

In T17408#308803, @ngraham wrote:

We already have basic components. Maybe they're not ideal, but we have them.

We don't have a lot of high-level components combining those basic components together into complex stuff. That's what we're mostly missing right now.

Maybe this goal isn't about that, and it's about redesigning the basic components as a starting point. That's fine, but then it's targeting a less urgent need.

I'm a bit concerned about this. We cannot afford to spend a year thinking thinking about typography alone. I know I'm oversimplifying your words here, but I hope you understand where I'm coming from.

As an application developer the questions of what font to use or how a button looks like are among the least of my concerns. These are essentially solved problems from an application developer's point of view by using the toolkit's standard components. There's central knobs for VDG developers to tweak those globally. Yes, there's a few more such knobs that need to be in sync than I'd like, but I don't think that's our primary problem.

Your proposal seems to be a bit too "low-level" for my taste. As an application developer I'm usually not worried how a button or slider looks like. What concerns me, and where I need the most input, is how these low-level building blocks are arranged and assembled into an application, i.e. the layout and interaction patterns of our applications. IMO this is our weakest point and where I would like to see the focus of this goal

In T17408#308791, @redstrate wrote:

This all sounds well and good, but how will we get to this point? Aka, I feel like this goal is more pie-in-the-sky then something practical I feel like we can achieve. Like, why/how are we at the point where someone can say something like this:

The same can't be said with KDE, which is a nightmare to propose design changes, mockups are either badly edited screenshots or they are made from scratch and don't really match the real thing

In T17408#307819, @ngraham wrote:

To be even more specific, I feel like one of the most impactful kind of components to create would be pre-made list and grid items apps can implement by plugging their data into.

We already have basic controls like buttons, sliders, etc, but often what we're missing is higher-level, more complex controls. We have some, but there are still a lot of omissions. And list and grid items are things that almost every app will need, but that currently we end up creating by hand almost every single time — especially for grid items. I think it would be hugely valuable to do a study of KDE apps to come up with a list of common types of list and grid items, for example:

• List - icon, title
• List - checkbox, icon, title, label on the right
• List - icon, title, subtitle
• List - checkbox, icon, title, subtitle
• List - icon, title, buttons on the right
• List - icon, title, subtitle, buttons on the right
• List - icon, title, subtitle, label on the right
• Grid - image/preview with hover buttons on the bottom and a title below it
• Grid - image/preview with hover buttons on the bottom and a title below it and a subtitle below that
• Grid - Icon on the left, with title, subtitle, and buttons on the right
  
  Etc. If we could have some pre-made components for these things that apps could use and plug their own data into, it would be hugely impactful, and save developers a lot of effort currently spent reinventing very similar components over and over again.
  
  We had one of these before in the form of Kirigami.BasicListItem, but it got deleted in KF6, and I'm still bit sad about that, since what replaced it was DIY components that developers have to put together by hand. I don't feel this is the right approach.

In T17408#307771, @ngraham wrote:

Regardless of whether this goal gets chosen, I think there are a lot of valuable observations in the text, such as:

Developers have to deal with graphical alignment, fonts, colors, button implementation, states, animations, etc. It’s simply a lot to ask for our developers.

It’s no wonder that the majority of our audience in the Visual Design channel are not designers. The barrier to entry for creatives is high and discouraging.

Plasma suffers from constant visual re-development that seems to never end.

These are complaints I hear a lot, and agree with myself.

I feel like #2 in your list is going to be the most impactful: creating more common components that developers can piece together without having to build things from scratch all the time.

This way, developers wouldn't have to make choices about things like icon sizes, colors, paddings, margins, spacings, etc; they would come from the components themselves, with the values determined by the design team. When a visual refresh is needed, we'd change the code of the components or the styling they receive, and devs wouldn't have to port anything. No more constant porting hell.

I think there's another aspect that needs to be considered: a proper mockup toolkit that uses real styling. Recause right now designers have no way of making actionable high def mockups. We don't need low def wireframes or high def fantasy styling; we need a mockup toolkit where the template components match the real ones pixel-for-pixel.

The template components also need to be immutable when using them to put together mockups. No saying, "oh, this component mostly looks good, but now that I'm using it to make this design, I'll nudge that icon over 4px to the right." VERBOTEN! This is important to keep mockups actionable. If a mockup component has issues, designers would improve the template for it, and then devs would make the actual component look like the mockup toolkit template, to maintain visual fidelity. This way, all mockups would be actionable and we'd avoid that thing where everyone ends up disappointed because an implementation fails to live up to its mockup. If the result looks bad, it would be because the mockup looked bad too! 😆

In T4275#298869, @ognarb wrote:

In T4275#298822, @ognarb wrote:

Lays, are there any pages from the web that can help as inspiration for our page?

This one https://kde.org/fundraisers/yearend2022/ which we basically just want to copy past to kde.org/donate. I'll see if I can do that during the promo sprint this weekend

Done https://kde.org/community/donations/ :)

But there are probably some more additional improvements we can do

Lays, are there any pages from the web that can help as inspiration for our page?

I wanted to also mention that whenever infrastructure is added or removed, we should do some change management to prepare the community if there is impact to them. Main aspects of a change include:

If help is needed with the page design, come to the vdg and we can help!

In T16403#294895, @ngraham wrote:

Thanks!

But does the font have to be monospaced? I think a fixed-width font might look better there.

I like it Nate!

In T16403#292367, @ngraham wrote:

Ok, let me play with the wording and propose something.

Still thinking through this, I am asking around to see if we can propose a design that integrates everything properly. Stay tuned.

I think my main thing is I want to simplify a bit.

In T12622#291129, @zamundaaa wrote:

Yes. FYI you can leave out the activities bit, at the sprint we agreed that it would be simpler to make the KCM apply to the current activity only

In T12622#290977, @meven wrote:

In Plasma Sprint 2023 we agreed we want to achieve this (https://invent.kde.org/plasma/plasma-desktop/-/issues/89)

zamundaa suggested design is aligned with the direction we were aiming at
https://phabricator.kde.org/file/data/3ib6sdfnmmw7lh54mbhw/PHID-FILE-ieljnhcfvxlf6wkpmqge/mockup.png

First implementation step would be to separate the Config UI from plasmashell process i.e adding a DBus interface.

What do you want to do exactly?

I am thinking that trademark rules are already decided by law. It would be a matter of developing a process internally of identifying those groups in need of this protection and then running them through the regular trademark registration process in the country of choice.

Just wanted to add a couple of suggestions for features:

I guess something I am missing is the "WHY?" part of the argument. Why should Plasma integrate at a default level with Latte?

I don't think this is a good idea everyone. First, I feel this is basically surrendering our design to the belief that others do better than us. I don't believe that falling into the idea of "the grass is greener on the other side" plays well for an open source project. If there are people who feel inspired by proprietary systems, they have the choice of being able to create their own styles. That's what Plasma enables, but we are not a system copycat. We believe in the power of ingenuity, that means, we believe we propose different ideas for the desktop than others.

Is this being followed up on the KDE Gitlab? I couldn't find it.

Has there been any conclusion here?

My feelings are that we should move to non-hovered controls. Here are some reasons that I find valuable:

I know this is merged now, but I have a bit of a gripe with the interaction. The fact that the global theme becomes part of the toolbar makes it seem like there is no button there. It seems like the global theme button is a header instead. This pseudo header/button also replaces the search button when the syse window is not big enough, leaving the user without the search field. If global theme was "not" a kcm, then it would make sense to have the placement it has. This is the only button that behaves this way. By the same token, you would expect all other headers like Workspace, Personalization, Network to also become header/buttons and have their own kcm, which they don't.

+1

I have a bias for my variation. However, having said that, I really like the differences shown in F8796068. It is soft yet the purple makes things very identifiable. I like it a lot. I personally feel like it's the stronger design. The ocean variation has my vote.

Hey man, can you join our vdg team on Telegram? Here is the link: https://t.me/vdgmainroom

In the current implementation of this, the cursor turns to the selector for the screen. The cursor does not draw a squared selection of screen where there is black outside the selection. The app crashes or closes after the screenshot is taken. This behavior happens on Fedora 32/Plasma 5.18

+1

+1 from me!

+1 from me!

I love this idea. I would request to keep the drag behavior and follow up with a second ticket to propose a change in the drag behavior for the panel.

Could you please try a combination of 2 and 4? I am curious how that would look like.

Look great!

Look cool!

In T13008#227333, @ngraham wrote:

Personally what I think we really need more than this feature is a global "reset everything" button. This is something I hear users asking for all the time, and I think it's a more common use case to want to reset everything to defaults than it is to want to see (and then maybe reset) which individual settings have been changed from their default values. Supporting this was what I thought all the KConfigXT porting was all about. :)

My opinion on this patch from the beginning has been that it really doesn't add much more than was there before. Visually, it clutters the UI. The icon selected for it might also not be visually appealing or meaningful enough. I believe there should be a different approach to this request. However, I am also open to just dropping the idea completely.

Looking at some of the rules, I see that the language seems very high. Surely a user that spends time on this KCM would have some understanding of what they are getting into. I would suggest bringing the language for labels closer to the one used for KCM options, where we make it conversational, inviting action. For example,

If I am understanding correctly, this patch adds icons in the kcm list to indicate changes you can revert by going to the kcm. Basically, default settings have changed and now you have the possibility to see that changes have been made. I am not sure that I like the implementation. I have some questions.

+1

It seems that the most common iteration is using the minus sign when the buttons are outside of the list itself and use some kind of remove button for those items that have things inline
I guess it depends if we are talking about removal from the system versus removal from the list. They are not intrinsically the same thing. However, I tend to favor using a minus sign in most places
I don't think the trashcan icon is probably as appropriate just because we don't always delete.

+1

I would suggest a circular button instead of square.

I love the gear idea. There was a time when KDE had a bouncing cursor that was a gear, but it jumped instead of spin. The spinning seems much better and better branding for the DE. Maybe Plasma 6?

I proposed a change to this structure long ago, I believe it might be good to consider and organize. Maybe also we can offer more than one way to find things as SySe is launched. For reference, here is what I made,

Love it! Move forward!

"To reduce eye strain, Night Color makes the colors on the screen warmer at the time of your choosing"

+1 on visuals!

How does this look?

In T10891#187868, @ngraham wrote:

In T10891#187828, @mglb wrote:

As for colors, making primary/selection color a bit darker would be awesome. White text on plasma blue has low contrast.
Alternatively, the text color can be changed to black, but this doesn't look so cool.

This is probably a pretty easy fix that we could get in very quickly. Personally I'm partial to the more subtle pastel blue used for Plasma selection highlights and as the background for the informational KMessageWidget/Kirigami InlineMessage messages, where the text stays black. As another bonus, adopting this color would reduce the unnecessary visual distinctiveness between Plasma and KDE apps.

In T10201#187910, @alex-l wrote:

@ngraham After thinking better, I think you're right but I also think that such a large title bar contributes a lot to making users hate server-side decorations. I can't think of any solution apart from making it more useful with tabs like in the Plasma Sets mockup.

+1 on visuals

+1 on principle. Many of these color themes are old and unmaintained.

We might need to add some padding so the button frame doesn't overlay content on the background

In D21622#475230, @ngraham wrote:

+1 to what? The patch's current change, or what we're still discussing? :)

+1

+1

+1 on visuals

+1

+1

+1

+1

Would it be "too" crazy to want the checkboxes background to be white? I think they bring nice contrast to the page and sets the checkbox apart.

I don't see a huge visual difference, so it seems good. Do we know if this would look bad in any other apps or situations?

In T10891#185961, @onvitaik wrote:

Since I saw those crude mockups, I've been changing it with the suggestions I wanted to make plus others. It takes some pages taken from how other DEs do their things and some of my own preferences, while at least still trying to not deviate too wildly from the Plasma look. I've also combined it with some suggested changes to the current system settings application.

{F6844666}

(Text is a bit cut off at the end. It meant to say "as changes would be applied immediately")

Most of the reasons for the changes are to the side of the mockup. I wanted to include some other comments, like how child areas need to look more distinct from their parents (It was one of the linked reddit post's complaints: https://i.imgur.com/sJ0zE6b.png), but for now...

+1

In D21312#467791, @lavender wrote:

In D21312#467698, @ngraham wrote:

+1 for restoring the feature, which is very useful! I've wanted this myself many times, so thanks for submitting this! However I'll admit I'm not super thrilled about having the capacity indicator bar always visible. I can't quite put my finger on why, but something about it feels a bit off. Maybe that's why the original only appeared on hover? But that's problematic in an era where we need to be designing for touch-friendliness. Maybe it could be a pie chart to the right of the icon but left of the text? Or maybe it's fine as-is and I'm just being a stick-in-the-mud.

Either way, adding VDG for comment.

I agree that there's something off about it - to me it is the fact that it's a lot of visual clutter that does not give actionable information. It relies on the user knowing how big the volumes are because for example a 90% filled bar is very different to someone with a 100 GiB volume than someone with a 1TiB volume. I don't have any data on this but I have a feeling most people don't care about how full all their volumes are until it hinders them so how I suggest we do it is for it to stay out of the user's way until the volumes are almost full, when there is a reason to present the information and possible actions the user can take.

Or at least vastly reduce how much attention it grabs because it could just be me but it distracts from reading the volume labels, I imagine it can get draining if you have to scan through a lot to find the one you want.

+1

I love this idea visually. I would even say that if you enable this on the sidebar, that maybe it should not repeat itself on the bottom bar on the same window.

Would it be possible in this evolution to explore more streamlined spin boxes? I have always felt, our current version mixes the control with the content and it would probably be cooler to have them look separate. Maybe more like this:

+1

+1