In case I am allowed to participate in this voting:

Just adding two things I noticed some time ago, but did not get around to adding here:

For reference, this is the task about improving single click which also contains the ideas for selection control: https://phabricator.kde.org/T9895

I just had another look at index and I have to say their solution is probably the better orientation guide than my mockups, as it is much more mature with some nice UX solutions (like the x for "clear selection"):

Then it might be sensible to update the mocks to better reflect how the final product will look like? Or is it planned to change the colorscheme in the future to fit the one in the mockups?

Alright! (I also was not entirely sure before whether you planned on implementing this)

Nice! Just a short heads up to a bug I had with the previous wallpaper, as I think it might be caused by the image files themselve and not some code: https://bugs.kde.org/show_bug.cgi?id=427803. If that is correct, hopefully this time it can be ensured that this bug does not happen.

I guess it comes down to personal weighting of the different aspects, then. Also thanks for mentioning some downsides, as I have not thought about some of them.

In T11070#247390, @ltoscano wrote:

Translations in the repositories would make the life of people who touches several repositories almost impossible, so it's out of the question.
The solution is to make weblate work with a structure which fits us (either svn or per-language git repositories).

@cblack Thanks for mentioning that. No, it was not directly taken from it. In fact I never heard of index before and I just found it googling around, so linking a medium post for reference (guessing this is the one you meant): https://medium.com/@temisclopeolimac/index-overview-b2ddcb16534f. The images in that post show even some more interesting concepts for overlays, though.

Although maybe not needed, I will cast my votes based on the old scheme. I have to say though that I in principle agree with this comment from @niccolove that basically suggests staying somewhat "consistent" ;)

Created https://phabricator.kde.org/M179 now.

In T9895#246968, @felixernst wrote:

Action buttons are in close proximity to unrelated info text there

Not really: The status bar text states the selected items, the actions below that text act on these selected items.

Agreed to your first two points.

That is a nice UI to make the user aware of what applying does and at the same time offering fine grained control over what will get changed / inherited from a global theme. +1 from my side!

Just adding a few thoughts of mine:

I just had some thought about this again. I still feel neither current approach is "right" in every aspect.

Judging from how other menu entries behave (not speaking about the technical workings) both the currently implemented and the suggested idea here are not really consistent afaict, although this is a somewhat special case probably.

I guess that integration into a yet to come first run wizard will be the best in the future.

I created https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/236 now (currently making the identical change as @The-Feren-OS-Dev). So this probably needs some work, help is very welcome as after reading some documentation I still don't know how to achieve this :)

Hm. I think that currently we are at a state where probably most arguments have been brought up, but still the views (most likely the weighting of the individual arguments) are still different on this whole topic (meaning there is no consensus currently).

You mean another https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/121? :)

I finally got around adding a summary of most arguments brought up in the discussion now. Please update it when things change, in case I have forgotten things or when I misrepresented comments. That way people can easily see the current status and ideally don't bring up similar arguments again in the discussion which only makes it harder to follow.

I fully agree that the current solution of having the header as some kind of button is not really what one expects and will propably confuse users (or that option will be completely unnoticed by them).

When it comes to the normal cursor I still prefer it to have a "tail". That would also play more nicely with the rather conservative overall design decisions made in Breeze evolution, I think. I wonder how that shape looks with some short tail applied.

For consistency see the categories listed at https://phabricator.kde.org/T13690.

In T8187#243465, @ognarb wrote:

I use single click and I like it, but I wouldn't mind changing the default to double click if and only if we don't change the behavior for existing users. People currently using single click shouldn't need to change their behavior again. This was something that I didn't like with the move from Alt to Meta shortcut for Kwin. Let's not break the workflow from our existing users.

In T8187#243464, @davidre wrote:

Finally:

If we believe single click is better than we should keep it as default. It makes no sense to have the better option off and the worse option on by default. Otherwise only people who already used single click because it was the default in the past will enable the thing we believe to better and everybody else will stay on what we think is the inferior setting.

In T8187#243457, @davidre wrote:

In T8187#243302, @clel wrote:

Regarding consistency with touch devices: There has been made the point that mice (or touchpads) make the user aware that interactions are different from using a touch interface. I guess some years in the future the preferred default might acutally change. It is just that currently I don't think enough time has passed that consistency with touch can count as an argument for the majority. To me it looks like KDE was (and still is) ahead of its time. The situation probably will change, but for now I tend to double click as default.

For me that is an argument to not switch because in $timeframe you likely want to switch the default again. Also debatable when the time will have come or maybe if it even has already come.

In T8187#243395, @mart wrote:

To me, "others do this way" is *never* a valid argument.

In T8187#243308, @broulik wrote:

Just because they're "used to it" doesn't make it better. In fact, double clicking is widely inconsistent, based on whether an item is selectable or not. I've observed people double clicking basically anything that looks like a file even though it's not necessary because they don't know and, frankly, shouldn't know the logic behind what determines that. Whereas our approach is simple: click once, it opens.

Despite me never really having used single click, I can see that it might actually be the better concept. However, from the GitLab discussion I have picked up two (I think) good points for double click as default:

That will probably add another piece to the puzzle, although telemetry is also biased and to a certain degree one probably has to go against user preferences if one wants to move forward ;)

Nice approach, I always thought the app looked pretty outdated (although I never actually used it). Added two small remarks.

In T11153#242842, @ognarb wrote:

I would recommend to either make the line lighter or remove it completely. Not making it not touching the edges. I'm personally would be happy if we could embrace some 'modern' web design tricks of using different background colors and shadows to separate sections instead of lines. This would also make it easier to remove the frames from all the QWidgets :)

There has been a short discussion in the VDG group chat room about those separator lines in the past. If I remember correctly, the consensus was that they might benefit of some improvements. There were some people preferring to have them, I guess to have more clearly visual separation while maintaining low spacing between items (which is also requested by some of KDE's users).

I like the direction the theme heads towards.

In T10891#242055, @debnath wrote:

@clel The example images all seem to have scrollable sidebar. But the UI element in question doesn't seem to have scrollable sidebar. The KDE equivalent to the images from other platforms would be the system settings page (where I agree, it makes sense to keep the title):

@davidre It does not if it is applied to all KCMs in the same way. However, if I understand this task correctly, this is only for one KCM while the others stay the same. That would be inconsistent, because then they treat hierarchy differently (plus the proposal introduces a right sidebar that is not used anywhere for this level, I think).

I just had a short look on how others do it to get some inspiration. It seems to be pretty common to also have the selected option as title (or in the window titlebar):

I agree that having both options might lead to problems. I think most or all other places where accent colors are used don't offer more detailed color settings. One possible way to circumvent problems would be to show accent colors by default and then have an additional "advanced" menu. Applying accent colors would override all settings in that "advanced" section (after displaying a warning probably). One could click on a blue accent color have that oveall scheme applied. After changing stuff in "advanced" and clicking blue again those things would be overwritten by the default values again.

One problem that came to my mind that I think @ndavis mentioned in a different context is that there might be conflicts with icon colors.

The problem is that these proposed changes might introduce inconsistencies with other KCMs as far as I see this. That would be something I didn't like and why I suggested discussing this on a higher level. But if you have a solution that doesn't introduce inconsistent behavior (maybe what @davidedmundson suggested) that would be fine with me.

In T13451#241704, @manueljlin wrote:

• Checkmark now has the same padding as the three-dot/partial state
• Removed gradient from inset components on both blue and grey colors (Checkboxes, radio buttons, sliders, progress bars) as requested by Noah

In T12443#217034, @davidedmundson wrote:

We don't want to do anything that will break searching - typing "colours" should still work as-is.

To a large extent it seems like we're reinventing something that already exists.

Effectively we just want to have one entry at level 2 and move everything into level 3 and then the searching still works.

The other key difference is that the KCM you open from level 2, doesn't appear at level 3 to indicate it's some sort of parent - but maybe we can find a less invasive way to visually hint that within the current architecture.

I like the overall idea. One thing (maybe even a benefit): I think it would require some more abstraction and maybe simplification of how the current system works (at least from how I think it works). In the future I guess that abstraction and simplification will make changes easier.

Sorry, I knew this had potential for misunderstanding. What I meant was keep the original design element for checkboxes in context menus and just change their radiuses to fit the rest of the style.

In T13451#241354, @PhilipB wrote:

Also, since the dolphin mockup from https://phabricator.kde.org/T10891 seems to be some kind of design goal, I went ahead and used the design elements from blue ocean there.

Don't know whether there is a link to Figma with the current state of the design (if there is such central source of truth currently), might make sense to add it here.

I added blue ocean to the description. Feel free to revert if the description is not thought to keep track of the current state of this task or some other reason.

Hm, if I have the correct version of blue ocean (which afaik is the current favored style), that seems to use 4px radius mostly (with some exceptions like 3px for tooltips).

Thanks! I updated the description with that information and also added the probably current state of "round vs. rectangullar corners".

I created a new subtask to keep track of the overall design approach for the future Breeze theme now.

I don't have the overview over all tasks. Best would be to check yourself I guess. Most tasks still seem to be in need of help.

I guess it has been settled on a design already? Does that mean it has been agreed to use round edges everywhere then and make the overall appearance rather soft?

As already written on the VDG chat, I prefer colors that stand out more. The current light approach of blue ocean feels to transparent to me.

In T10891#240744, @ndavis wrote:

It's hard to get a big picture on the original plans for Breeze and I'm not sure if there ever was a solidified big picture with lots of detail. The original authors have moved on, there's no central place to look and the documents @davidre linked above weren't written by them. You'll probably find some things on the KDE forums (https://forum.kde.org/viewforum.php?f=285, we don't really use this anymore), some things on the blogs of the original designers, maybe some things on the KDE wiki and maybe other places too.

Thanks! Those sites really only seem to cover some "philosopy" and don't go much into details. Ideally there would be a more detailed place, maybe something for the future.

I am wondering, is there some central point where the overall breeze theme "design philosophy" is documented? Or where that can be discussed? Since I think it makes sense to have some broader overall guidelines in order to make consistent decisions about the design of specific UI elements.

Most themes seem to be rather soft and skeuomorphic. In general I like both flat and skeuomorphic. However I think it has to fit with the rest of UI elements around on a desktop at least up to some degree.

Interesting Slant was voted so badly. I'd have preferred that, since the color scheme is similar to the old one and it looks a bit like an evolution to me. But design really seems to be subjective :)

Ping @PhilipB @abetts

Looks nice! Just mentioning a probably relevant merge request with overlapping similar changes: https://invent.kde.org/plasma/breeze/-/merge_requests/23

Alright, no problem. Let me (or others) know when you have more time and would like to get more involved. I am sure there are many willing to help you get started properly :)

Everybody has to start somewhere :) It definetely makes it easier to get changes integrated into KDE.

Alright then. I guess it makes sense from that perspective. I kind of hoped to move this forward maybe or talk about things that can be implemented right away without much effort. Maybe if you have the time, you could look into how this works and submit some merge requests on GitLab. I assume some things won't be that much harder then creating a mockup, so that would be some kind of win-win :)

In T11070#238054, @pshinjo wrote:

In T11070#238043, @clel wrote:

You might have some good points here. I understand that for an active team there is not much need for such a system. However, almost no language has all Strings translated already when looking at: https://l10n.kde.org/stats/gui/stable-kf5/team/. Quite the opposite if you look how much untranslated Strings there are for many languages. So apparently almost no team is active enough to reach a completeness level of 100 %. Thus I assume they lack the time and manpower.

Just to say, GNOME's l10n system is called "Damned Lies" (https://en.wikipedia.org/wiki/Lies,_damned_lies,_and_statistics). Yes, only a small number of teams reach 100% in the statistics. I personally do not aim 100% there because:

• websites-kde-org/www_www.po contains ALL release notes dating back from KDE 4.x era. Even if I translate 100% of them who will practically read all of them? Also I don't direct other translators to touch them either.
• Big specialized applications: I would name Krita, KStars, GCompris, RKWard as examples. They require specialized domain knowledge for usage (and correct translation). For some languages, even finding a user who is using the application in English (and eventually willing for a translation) could be hard enough.

In T11070#238036, @aacid wrote:

In that case I have to say that many users maybe just want to quickly correct some Strings for their application that they use.

This is the crux of the issue, you think random drive-by people translating 2 strings is a good thing, I am almost convinced it isn't.

In T12839#238032, @niccolove wrote:

Magic convoluted solution, second try:

Where does this come from? Has there been some discussion on Riot or somewhere else?

• The plasma themes defines four new margins: left-margin, center-margin, right-margin, separator-margin
• Specifying a generic margin will set the same margin to all three for backward compatibility of third party themes
• At startup and every time an applet is added or moved, the total number of applets with fillWidth: true (which we'll call "separators" here) is counted
  • All applets with fillWidth: true (the separators) get the separator-margin
  • All applets where separatorsLeftOfThisApplet / totalSeparators < 0.5 get the left-margin
  • All applets where separatorsLeftOfThisApplet / totalSeparators = 0.5 get the center-margin
  • All applets where separatorsLeftOfThisApplet / totalSeparators < 0.5 get the right-margin
  • (separatorsLeftOfThisApplet are the separators left of the applet in horizontal panels, and separators above the applet in vertical ones)
• A new enum costrainmenthints is added, a new property to appletinterface of the same name is added
• The task managers sets the costrainmenthints property to fillArea
• The task manager then sets taskmanager.svg normal-margin internally
• We make the panel 44 px with: 4px left-margin, 8px separator-margin, 8px center-margin, (or 4px?) 8px right-margin
• Make system tray adapt to panel size again, 2 rows where feasible

I like that it will show two rows where it fits!

• We add 2 separators left and right of the tray

Are this visual separators?

• We consider putting the concise date next to the time on horizontal panels (10:40 9 Jan)

I think I prefer the old way visually.

• We consider using the vertical version of the clock in https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/222

This currently does not look good to me, either. The font seems to be too big and it is harder to read imho.

Sorry, got it now, Konsole also offers that theme, so there is nothing to do about it.

I won't answer all your points this time, since I think it just won't make too much sense. There is clearly some misunderstanding on your side about my motives. You seem to think I would want to force you to use Weblate which is not true. Also I understand that using Weblate would slow down your workflow. However you use a problematic discussion style to outline that. To me it seems there is some truth to your points, but it is pretty hard to get to it, since the truth is sometimes covered behind some arguments that don't really make sense. This includes coming up with some non-standard definitions of words like "translator".

Alright. I created a current screenshot now:

No problem :)

There might have been misunderstanding. I was talking about the way Konsole looks by default now on a normal Plasma installation, so one can see what you changed in all your mockups compared to the status quo. I think you just replied with a more updated mock up version?

In T11070#237992, @yurchor wrote:

No. And you know what I mean. Typing, for sure, is as fast as for offline tools. But switching between translations is slow. And it eats plenty of time if you typing fast. It takes ~3-4 seconds just to switch between translations.

In T11070#237992, @yurchor wrote:

In T11070#237987, @clel wrote:

@yurchor I move the conversation here, since it seems to have nothing to do with the old task's topic anymore.

In T13514#237943, @yurchor wrote:

Fedora's translations are broken this way almost every week. The only savior is that they change very rarely.

The similar GNOME project (DL) is also *very* fragile (broken every month or so).

Are there any bug reports about this? Basically if what you write is true, those systems seem to handle conflicts rather poorly.

Just read the gnome-i18n@ for the last several months. The complaints there are just 1/3 of the real cases when DL was offline.

In T11070#237992, @yurchor wrote:

In T11070#237987, @clel wrote:

@yurchor I move the conversation here, since it seems to have nothing to do with the old task's topic anymore.

In T13514#237943, @yurchor wrote:

In T13514#237939, @clel wrote:

In T13514#237910, @yurchor wrote:

In T13514#237909, @clel wrote:

Alright. Then I don't really understand what problems you have with Weblate. The things you wrote are too general for me to understand what the concrete problems are that you experience.

Sure. Just one thing that I do not understand is that people who do not really understand how the translation system works eagerly want to change that system.

When you write "Sure", I expect some more insights :) You wrote about problems you had but did not really give much detail about them. You talk about Weblate being much slower than offline tools while not mentioning which parts of the workflow you are talking about (admin stuff, translation itself, downloading and uploading PO files?).

All of them. There is no need for offline administration, translating every string through web interface is several times longer even in the zen mode, "downloading" new strings through Subversion then found what to translate in Lokalize takes ~5 seconds, analyzing big projects (Fedora is smaller than KDE now) in Weblate takes minutes. Uploading big files (libguestfs and its man, libvirt, Weblate docs, etc.) literally takes up to 10 minutes for just one file. I can imagine how long it would be to upload KStars, Krita and its docs (the last update required several dozens of files to be uploaded, the translation itself contains several hundred files), RKWard, KMyMoney or LabPlot.

Interesting. I only sporadically worked with online translation tools like Crowdin and Transifex, but never noticed any slow behaviour when translating strings. I assumed it would just be similar in speed to any offline tool. You write several times slower, that means a factor of 3 or higher? That only seems plausible for very specific tasks like searching for a wrongly translated String maybe that one wants to correct.

No. And you know what I mean. Typing, for sure, is as fast as for offline tools. But switching between translations is slow. And it eats plenty of time if you typing fast. It takes ~3-4 seconds just to switch between translations.