Thanks a lot. I submitted the merge request: https://invent.kde.org/plasma/systemsettings/-/merge_requests/67

Understood. In this case, I want to propose a merge request to rename "System administration" to "System" because viewing system information isn't actually administrating the system, unlike the Updates section. Can I submit the merge request with just the "name" variable changed and leave the rest (name[ar], name[ast], etc.) unchanged?

Understood. In this case, I want to propose a merge request to rename "System administration" to "System" because viewing system information isn't actually administrating the system, unlike the Updates section. Can I submit the merge request with just the "name" variable changed and leave the rest (name[ar], name[ast], etc.) unchanged?

KDE has its own translation teams who translate the strings from English into other languages automatically.

Thanks! What about the other languages? I think it wouldn't be appropriate to use Google translator. Some translation might be wrong.

But that's what I'm actually telling about, this header line:

No, the Breeze Evolution task is about making the whole header area visually distinct from the rest of the window. We moved *away* from the "unibody" look. See T10201.

Ok, thanks!

Ah, I didn't know D: Is that slated for Breeze Evolution?

That could work. Changing text is super simple; here's where it lives: https://invent.kde.org/plasma/systemsettings/-/blob/master/categories/settings-system-administration.desktop#L9

Maybe System Administration could be renamed to System. It would fit better for the " System Information" issue.

Boot Splash Screen is already in Appearance in Plasma 5.22.

This is a bug only in the GHNS dialog; please use Bugzilla and file a bug on it: https://bugs.kde.org/enter_bug.cgi?product=frameworks-knewstuff&component=general

The titlebar and toolbar could have the same background as the rest of the window (as it is in Arc KDE):

I come a bit late in the discussion, sorry about that :/
@manueljlin I kindly disagree with the proposed UI for words because it reproduces the same mistake as every other word processor (MS Word, LibreOffice Writer, probably Corel WordPerfect).
There is a very deep flaw in the WISIWYG world. When you set a piece of text in bold, this is 99% of the time not what you want to do. What you wanted to do is an emphasis of this text. The difference is subtle but major in user interface. I think there is a place in the word processor landscape for a style first word processor. No bold button, but emphasis style. Numbered list being harder to reach than a title style…
I'm not good at UX and UI design, but do you think there is a way to do that? Getting out of the Word box most UIs are in?

In T14431#256691, @endlesswaterfall wrote:

Could this be possible?

Could this be possible?

I know very little programming and nothing about QML or Kirigami D:

Yeah, I mean you can fix it. :) Would you like to? I can show you how.

ahhn, oops? I understood the meaning of merge request wrongly...

OK! Check out https://community.kde.org/Get_Involved/development. Let me know in #plasma-devel if yo need a hand.

oops, thanks for the tip.

Edit: done https://bugs.kde.org/show_bug.cgi?id=437581

Would you like to submit merge requests to fix them?

It seems that we have basically decided to use trash icons in the actual list items themselves. No consensus was reached in this task, but since then, people have been organically using the trash icon, and porting list item removal buttons to use it. So I guess we can consider that the de facto standard. See for example https://invent.kde.org/plasma/kwin/-/merge_requests/995.

See also T10384.

This is really a simple feature bug report and should be reported using https://bugs.kde.org. Phabricator is really more intended for large-scale task tracking/discussion.

This is really a simple bug and should be reported using https://bugs.kde.org. Phabricator is really more intended for large-scale task tracking/discussion. Can you please re-file this at https://bugs.kde.org? Thanks!

Has there been any conclusion here?

In T12433#256169, @davidedmundson wrote:

Can you please provide a bit more feedback to what aspects you found impressing?

I think the most impressive was the detail on the task manager activation, with animations that worked properly and the little indicators.

Can you please provide a bit more feedback to what aspects you found impressing?

FWIW if we can spare 5x5 pixels rather than 4x4 pixels for icon emblems, I think it's possible to make a legible trashcan:

The new tooltip isn't merged yet. Once it is, it will be safe to remove the window decoration button. Until then, the button has to remain, because some people might still be using it.

The What's This titlebar button is not available in other desktops and made obsolete by the new tooltip implementation. The new implementation should work everywhere, the button definitively doesn't.

In addition:

• I only see said button when using KWin
• KWin allows me to configure which titlebar buttons I want to see (and where).

In T9986#255915, @cullmann wrote:

[...]

for Qt 6 the ? button will automatically disappear, if we don't actively enable it ourself.

If I don't misunderstand the Qt docs:

Adding to what @dfaure said, I think the button is useful, and it should be opt-out, not opt-in; the former is simple using systemsettings, the latter is impossible to discover, because how would a new user find out there is actually a question mark button that can be used to show extra info about some GUI element.

"Who cares" (which really means "I don't care", since clearly there are people who do care), and "stupid" are not constructive feedback nor acceptable language in this community.
Here's a constructive suggestion for how your feedback should have looked like:

Who cares what you use the strings for, this request is about removing the stupid button on the title bar and that's more than before a valid request.

We decided to go in entirely the opposite direction and use the "What's This" strings for expanded tooltips. See https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/45

Implemented that with https://invent.kde.org/frameworks/kirigami/-/merge_requests/296.

BasicListitem now has the reserveSpaceForSubtitle property, which reserve space for a subtitle even when there is no subtitle, which you can use to give some list item subtitles but preserve all the list items having the same height.

We have generally settled on bold text for the current/selected list item at this point. I guess we need a HIG entry about it now. See https://invent.kde.org/documentation/develop-kde-org/-/issues/50

This is fixed now with all panel applets following the same margins, and those margins being partially user-selectable through the use of a Margins Separator applet.

Tracking there and closing this one.

These are nice mockups, but I think they're largely duplicative of other ones at this point, and we've even moved in the direction of implement a lot of this stuff. No need to keep the task open. Thanks for the nice mockups!