User Details
- User Since
- Dec 15 2018, 12:42 PM (282 w, 1 d)
- Availability
- Available
Feb 16 2023
Feb 18 2021
In case I am allowed to participate in this voting:
Jan 18 2021
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?
Jan 8 2021
Alright! (I also was not entirely sure before whether you planned on implementing this)
Jan 6 2021
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.
Jan 3 2021
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.
Jan 1 2021
@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" ;)
Dec 23 2020
Created https://phabricator.kde.org/M179 now.
Dec 22 2020
Agreed to your first two points.
Dec 21 2020
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:
Dec 19 2020
I just had some thought about this again. I still feel neither current approach is "right" in every aspect.
Dec 15 2020
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.
Nov 23 2020
I guess that integration into a yet to come first run wizard will be the best in the future.
Nov 21 2020
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 :)
Nov 20 2020
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).
Nov 19 2020
You mean another https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/121? :)
Nov 18 2020
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.
Nov 14 2020
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).
Nov 11 2020
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.
Nov 10 2020
For consistency see the categories listed at https://phabricator.kde.org/T13690.
Oct 20 2020
Oct 19 2020
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:
Oct 17 2020
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 ;)
Oct 15 2020
Nice approach, I always thought the app looked pretty outdated (although I never actually used it). Added two small remarks.
Oct 14 2020
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).
Oct 12 2020
I like the direction the theme heads towards.
Oct 6 2020
Oct 5 2020
@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):
Oct 3 2020
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.
Oct 2 2020
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.
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.
Sep 28 2020
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.
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".
Sep 27 2020
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.
Sep 26 2020
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.
Sep 21 2020
Sep 18 2020
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.
Sep 11 2020
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.
Sep 7 2020
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 :)
Sep 1 2020
Looks nice! Just mentioning a probably relevant merge request with overlapping similar changes: https://invent.kde.org/plasma/breeze/-/merge_requests/23
Aug 24 2020
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 :)
Aug 23 2020
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?