- User Since
- Apr 16 2016, 9:34 PM (147 w, 6 d)
Dec 19 2018
I'm in favour of having a different colour for the active window title bar, as this is also what controls like buttons do.
Having the same colour for the inactive title as the rest of the window is imho fine.
Jul 15 2018
if it falls back then all is perfect :)
Jul 14 2018
Ah, great, so it would not be any regression for non-PA users, thanks for the info
What happens to supported systems that do not have pulse audio?
The *BSDs we do support come to mind.
Also Linux distributions that do not use PA or offer to not use PA.
Jul 2 2018
Jun 24 2018
Personally I don't think that we should ship changes that rely on hard-coded theme names like
Jun 22 2018
as written on Telegram, added here per your request:
Jun 19 2018
Maybe add the technical term in brackets though, for those people who search for the technical term and don't find it otherwise?
Jun 14 2018
I think it makes it a lot harder to see though, depending on what the background is.
Taken from VDG discussion:
Jun 10 2018
Personally I am very much in favour, even to tech-savy people who had to deal with systems like the Atlassian Stack (Jira, BitBucket etc.), Redmine and GitLab, Phab can sometimes be very confusing and it's not entirely sure if a button will do what you expect it to.
I also assume that for people who don't feel terribly comfortable with English yet, it might make it even harder.
Jun 6 2018
Task Switcher > Alternative (https://phabricator.kde.org/M112/390/) - What does this actually do?
Jun 1 2018
In an ideal world I'd agree with you. But if the changes can only be done by few people (or not at all), it would not hurt to safely check beforehand whether a) it is possible b) someone with the needed knowledge and skill is willing to do it, because we can neither force people nor make things happen by magic, so that might safe some time and frustration. Not saying it should be the default for every minor change.
Personally I'd be okay with no borders without rounded boarders by default, even though I'd consider it a UX setback to have a less visible resize area just for the sake of a more thin look. To me form follows function.
Plus, personally I don't think we should switch defaults too often during a major release cycle, but rather decide something and then go with it for a while. This would lead to fewer inconsistencies where some areas are adapted to the new look and others are not, and give us a more polished look. (I am fully aware that we don't major release that often)
May 22 2018
Maybe we need to discuss things, especially also with https://phabricator.kde.org/D12463 where I have an interest in, on a broader scale.
May 21 2018
Highlighting them in the menu is a good idea and it also is what Windows does (since quite a few versions)
May 15 2018
Well, I think I mentioned my arguments about not wanting to override what other applications do by force. Applications where we have no control over what they do and, more important, why they do it.
Against 3) because the window manager will modify window content which apps are not designed or prepared for.
The rest is fine, with my usual "keep in mind that changing a default, in KDE, does override what existing users had and might have liked, please change as few defaults as possible and only where really needed".
May 8 2018
Personally I prefer the group boxes as they add some vertical separation when multiple radio groups follow.
May 7 2018
I like the idea in general, I agree though that, despite the severity, it is technically not an error and should not be shown as such, but rather a warning indeed.
May 2 2018
Apr 26 2018
Apr 24 2018
Apr 23 2018
On the existing bug: it's related to the TODO at line 1513, changing that to
Apr 22 2018
Also needs https://phabricator.kde.org/D12463
Apr 12 2018
happy fox now happy, says thanks :)
Mar 22 2018
Mar 19 2018
Mar 16 2018
Personal opinions, based on discussions here and on TG
Mar 15 2018
+1, looks great to me.
Bit of duplicate control, but given there can be one at most, that seems fine to me.
Mar 14 2018
Sorry, but clear -1 from me for the reasons outlined in the Telegram channel.
Mar 12 2018
Please definitely no hover. Whilst I agree that some things get way too tailored for other form factors, this is not one of them. I just very recently discovered that the plasma theme chooser has a preview button that magically appears on hover, so I agree with that being hard to discover and user hostile.
Yes, I very much like the overflow and the usage you describe, as per the discussion on Telegram and https://phabricator.kde.org/D11231, I think mixer is however not an example where it should be used, because in the mixer it's not an overflow of functionality, but rather a menu on its own.
New screenshot with fixes
- Better hack for placement
- Change the layout import according to kbroulik
- Use Math.round() as per discussion
- Capitalized History in the tooltip label as per discussion
Updated, I didn't see that old community wiki entry, that is of course way better. Linked until it gets ported, which also fixes the second comment as side effect.
- Link to the community wiki as per phab comment
Mar 11 2018
Whilst I like the labeled one more than the current one, I can't say I'm a huge fan of either.
Feb 27 2018
Adapt code style.
Move text back to if/else for at least a bit of readability, reverted the check to go for > 1 since that is what we are interested in. Final revision, hopefully.
According to discussion on IRC, sacrifice some more readability for brevity.
Updated the text, tried to merge the code blocks. Due to most of it happening in a for loop depending on the type, this was not possible in a sane way without having a helper method created.
Aug 23 2017
[KMail user, not VDG person].