To be honest it still seems too general for me, without a clear enough unifying goal. "Users" and "features" kind of encompass everything, right? So this is phrased a bit like "make everything better", and, OK yeah, we all want that and are already working towards it!

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.

I think the bottom line is that designers need an understanding of how the designed components and the ecosystem around them can be altered by the user, and how this will affect the final visuals. So basically, you can't design in a way that ends up visually or functionally incompatible if the user changes the font size, color scheme, icon theme, or fills it up with more or different content than what you were expecting.

+100, That sounds fantastic. If that were the text, I would sign up to put work into this and could even be convinced to be a co-champion, perhaps on the communication side.

I'm deliberately not proposing or championing any goals this round, but if there's anyone else who would be willing to champion a revival of this one, I'll happily help to put work into it.

I agree, it would be amazing to revive this goal for 2024. I thought it was a great idea at the time it was proposed, and it's scoped appropriately for being a KDE-wide goal, not just something for e.g. Plasma.

I saw all sorts of things in the repo, but reached out to the maintainer and he says it's mostly small bug fixed. So I think we can remove KCalc from here. I shall do so momentarily.

This deserves a blog post with screenshots!

To be honest, the description is way too long. It's a wall of text that doesn't quickly help me understand what the main thrust of the goal is. It seems like it's basically an idea for how to better integrate activities and virtual desktops, and that's something I'd like to see too, but isn't this rather small for a KDE-wide goal?

This was @cullmann's work to make our apps use Breeze theming, color schemes, and icons when run outside of Plasma — including on Windows. Basically they won't try to integrate with the look and feel of other platforms that don't care about theming, with the result being that they'll look KDE-themed on those platforms, rather than being ugly and likely missing icons everywhere.

Would it be accurate to say that the thrust of this Goal is to listen more to feedback our users, and use that information to prioritize changes? If so, how would that differ from what we're already doing?

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.

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.

When I say "basic components" I mean things like buttons, sliders, text fields, headings, and the like. We have these. We use them all over the place in every app. When we want one, we don't ask for X corner radius, Y padding, and the like; the component takes care of all that stuff internally. This saves time and achieves consistency.

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

In T17408#308800, @ws wrote:

To make a vast oversimplification of everything to the point of uselessness:

Buttons, typography and basic stuff are the things that are the most painful to do in a mockup as a designer, because there is no really easy to find way to even know how they are made without delving into code.

Layout is relatively simple to mockup because it doesn't *need* something that *exists*. It should have guidelines, but in lack of guidelines, it is easy to deal with that alone.

Trying to mockup something without knowing the typography or how a button *actually works* feels like drawing blindfolded, while drunk and with the arms broken.

I agree with Nicolas, which is why I brought up the topic of re-usable high level components specifically between the levels of basic controls and whole windows. Things that consist of multiple combined basic controls like toolbars, list items, grid items, sidebars, etc. Right now many of these are hand-made, and that's a major problem. They take forever to make, invite bikeshedding over spacings and font styling, and require too much maintenance and porting over time.

Great stuff. I like how this ties everything together into an overarching theme. Well done.

The new HIG is merged and live, JFYI.

Can you try to come up with a catchier title? The current one is so generic it could encompass anything, and it's too long too. Finally, it only mentions Plasma, but the KDE community is much larger than just Plasma. It needs to be relevant to everyone, not just Plasma devs.

I'd say at least a 5 hours a week if you want to be effective, but it probably also depends on on what role you want. As Lydia's blog post said, there are three champion positions:

• Vision/leadership
• Technical lead
• Promotion/communication

Maybe that's getting a bit too micro at this point, but needless to say, I'm excited about this goal. :)

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.

I was the sole goal champion for the Usability & Productivity goal when I had only been an infrequent contributor to KDE for fewer than 6 months; it's more feasible than you might think!

Heh ok. Well if you change the goal description accordingly, I'd be happy to help out on the team with communications, design, and some technical stuff. But I can't commit to being a primary goal champion this time around.

Yeah, though that's still pretty broad. I feel like we need to articulate the specific principle that guides these strands of work. I'm not trying to hijack your proposal, but in everything I read, the underlying current is "turn promising technologies and nerdy features into products suitable for normal people". Or, like, "focus on real-world use cases and workflows", maybe? Just brainstorming.

Do we not already have this? Welcome Center more or less offers exactly what you're asking for.

I'm not going to disagree that it's is a nice thing in general, but I'm skeptical that normal people actually read technical documentation. In my time before KDE, I supplemented my income by providing paid support for Mac users for 14 years, and worked as an engineer at Apple itself for 7. I also had various roles in helpdesk support. In all these years, I never once encountered a person who had read any of Apple's formal documentation. Frankly, if they had, they wouldn't have needed to pay me $40 an hour to fix their computers and educate them about how they worked. It just didn't seem to occur to anyone, for whatever reason.

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

Porting towards portal-friendly APIs would be a part of this, right? For example moving away from constructing manual file dialogs using KFileWidget in favor of the Qt APIs that go through the portal.

Multiprocess Plasma is something I could get behind. There are multiple areas that this would improve: not only security via sandboxing, but also reliability and debuggability. If a widget hung or crashed, not only would it not affect the whole shell, but it would be obvious even to the user which widget was at fault, so they could remove it and complain at the developer rather than losing some regard for Plasma and then submitting an un-actionable bug report on bugs.kde.org.

In T17396#307735, @nicolasfella wrote:

The important (and more actionable for us) thing would be to make sure our application development story is as good as possible. An uptick in third-party applications would be a sing of us doing something right there.

I'd rephrase the goal around that and then I'd be happy to support it

I have to agree with Nicolas on that. For really basic stuff, it has to be dead simple in the UI itself, and if it's not, that's what we need to fix. This just got added to the new HIG as a principle: https://develop.kde.org/hig/displaying_content/#inline-help-and-tooltips

This reminds me of my Usability & Productivity goal, which to a certain extent was also a random grab bag of bug reports and feature requests. What really helped was to gather them around one or two core principles; in that case "Usability" and "Productivity".

This sounds a lot like changing Plasma's Activities feature to what I proposed in https://invent.kde.org/plasma/kactivitymanagerd/-/issues/6#note_507027. Obviously I'm in agreement about this, but It might be too narrow a scope to be a good KDE Goal.

Is this about AI, or voice control? Because I had voice control on my Macintosh LC III In 1993. So clearly you don't need AI for voice control, and AI is not a magic bullet that gives you whatever feature you happen to want. :)

Duplicate of https://phabricator.kde.org/T7280

This was done in https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2078!

Moved to https://invent.kde.org/teams/vdg/issues/-/issues/43, where I've summarized the rough conclusion here, and we can work on turning it into something actionable quickly.

Moved to https://invent.kde.org/teams/vdg/issues/-/issues/12

This is done now for Plasma 6!

Those knitted Konquis are so great I might suggest charging more, too. 15€ for something unique and handmade is a steal compared to a 25€ for a mass-produced print-on-demand T-shirt.

This is done in Plasma 6.