![]() Registered Member ![]()
|
I'd like to pipe in and say that I really like both the gears and the planet+ring busy indicators. Another option for the gear-based busy indicator that I was thinking up earlier would be to have the gear spinning along the inside of a(n invisible) box.
Also, as there are many suggestions and mock-ups for various styles of busy indicators perhaps we could gather several of the best ones and have the ability to select between them (choice is good, right)?
airdrik, proud to be a member of KDE forums since 2008-Dec.
|
![]() Registered Member ![]()
|
So true. In fact I just watched video yesterday of an interview with Matias Duarte, and he mentioned how helpful user testing has been for sorting out new or difficult design choices. Truth be told, the moment I tried this design (which was based on verbalshadow's excellent suggestions) was a moment of mix emotions. This new design felt almost inevitably correct, but I was genuinely conflicted by my attachment to the previous checkbox design. And no matter how much I looked at them and interacted with them I could not distangle those feelings. That's why I ran that quick user test to get the designer out of the loop for a minute. It cleared up things up immediately and, while I was sorta sad to see the previous design go, the more I use it the clearer it becomes that the new design was definitely the best choice. It weird how one little change can really strengthen the design language. When I load up the previous checkbox design now it just feels... odd. |
![]() Registered Member ![]()
|
Good ideas, I'll be sure to try that. ![]() |
![]() Administrator ![]()
|
I like the look of those! The only concern I have is that checkboxes with a square already exist (I know that at least Windows has them) and mean something else, see e.g. http://www.java2s.com/Tutorial/CSharp/0 ... eckBox.htm Also, I personally feel that the distinction between checkboxes and radiobuttons are less clear with the new design, but your test results seem to indicate otherwise. So for practical reasons I prefer something like the previous design, or just having a blue check inside the box, even though I think the square looks neat. I also want to echo the previous comment about the buttons, they pretty much blend in with the background. Lighter or darker colors would make them stand out a bit more, which I think would be good.
Problem solved? Please click on "Accept this answer" below the post with the best answer to mark your topic as solved.
10 things you might want to do in KDE | Open menu with Super key | Mouse shortcuts |
![]() Registered Member ![]()
|
Great observation Hans, thanks! Actually, it won't be terribly difficult to solve the tri-state checkbox design within the language of the current design. What matters isn't that the "check" is a square, What matters is finding a solution than can clearly represent a mix of the checked and unchecked states. I already have several ideas that I'll implement this weekend. |
![]() Global Moderator ![]()
|
Yes Qt has tri-state checkboxes too and KDE even uses them in a few places. But I think it's a solvable problem.
![]()
I'm working on the KDevelop IDE.
|
![]() Registered Member ![]()
|
I guess the obvious answer is a triangle (the square cut diagonally into two parts, one blue and one empty). |
![]() Registered Member ![]()
|
or a different color of the inner square(orange maybe?)
|
![]() Administrator ![]()
|
So my main concern was about consistency. It would be bad if the new style used a square for the "checked" state, while other styles and operating systems use a square for a different purpose. (Personally I think that tri-state checkboxes should just disappear from Earth, but that's another discussion. ![]() I like that you did the user test, which seems to indicate that users were not confused about the new usage of the square. My guess is that most people aren't familiar with the tri-state checkbox, so they don't associate "square within a checkbox" with what it currently means. If we keep the current style, I think that GreatEmerald suggestion about a triangle sounds great. I can imagine it looking good and it makes a lot of sense to me (more than the current usage of a check/square). @scummos: Can you give some examples of where they're used in KDE? I can't think of any place at the top of my head, and I'm curious about how they look like in Oxygen.
Problem solved? Please click on "Accept this answer" below the post with the best answer to mark your topic as solved.
10 things you might want to do in KDE | Open menu with Super key | Mouse shortcuts |
![]() Registered Member ![]()
|
Hi.
I wanted to throw my two cents into this discussion ![]() First of all - it's my first post here so 'Hi everyone' again. I wanted to prise everyone working on new style. It looks better and better every time when I peek into this topic. Up till now I just looked at pictures but few moments ago I ran qmlscene to have real-time experience and it's amazing. I noticed one thing. The hover event over SpinBox arrows does not work. I mean the control should be highlighted but it isn't. I don't now if it's Qt bug or if it can be done, but it's a little, bothering thing when you notice it. Second thing - I noticed a little inconsistency in controls highlighting: - textArea control have 1px highlighted border when it's focused, and it does not have highlighted border when 'hovered'. It's different then every other active rectangular control. - It's my suggestion but shouldn't 2px border appear on buttons/comboboxes when they are clicked? I think it's fitting well with 2px border when text controls are focused. Here's a picture of how it would look (inactive/hovered/pressed): ![]() And here is code for BreezeStyle.qml (It's changing tabs too - I wanted to change them, but it didn't go well)
Also - sorry for my English. It's not my native language. I hope everything I wrote is understandable. |
![]() Registered Member ![]()
|
Nice catch. The reason for this seems to be that the hovered property in the SpinBox control is defined as
and the MouseAreas of the up and down arrows catch the hover events on them and don't let them through to the global mouseArea. This could perhaps be considered as a bug? It could be fixed by
Anyway, we can work around this by checking for the styleData.upHovered and styleData.downHovered properties. On a related note, looking closer at ScrollUpArrow.qml, it seems that there is a hover effect on the arrows that won't work. This line:
should be replaced with
By the way, the properties in the styleData of a given control seem to be completely undocumented. According to the source code the SpinBox control has these styleData properties:
A documentation bug? |
![]() Registered Member ![]()
|
I noticed there's quite a lot of code duplication in ScrollUpArrow.qml, ScrollDownArrow.qml and DropDownMark.qml. I combined them all into one component, ScrollArrow.qml:
Here's a diff of changes needed for BreezeStyle.qml:
|
![]() Registered Member ![]()
|
The new busy indicator is pretty cool. Something I didn't even know we could do. Everyone seems to love the new busy indicator. After considering this for a day or so hoping that it would grow on me or figure out why it bugged me so much. I think the problem is that it is inconsistent with the rest of the style. Same issue I had with the hightlight on the spinning ball. Way to 3d for the style. In this case so much so that it is worse then the highlight changing directions. If it is on screen the user's eye will be attracted there first and always. Sorry I do not have code or a good suggestion to fix this issue.
verbalshadow, proud to be a member of KDE forums since 2008-Nov.
|
![]() Registered Member ![]()
|
Thanks for the awesome detective work, patches and feedback everyone! I'll push some updates soon.
![]() |
![]() Registered Member ![]()
|
Ok, I made a few updates. The updates are pretty straightforward:
![]() I wasn't going to bother including a screenshot since it tells so very little at this point. The best way to experience the style is to get it directly from the repo as described in the original post (and by others here) and running the demo app. Now, where are we? At this point, we've made enough progress on our original objectives for starting this thread that I'm comfortable that we're really on the tail end of design work for a first design release. Thanks so much for your amazing participation!!! I never imagined that we could iterate so quickly, so efficiently in such a short time. I updated the progress report. So what does this mean? The bulk of any remaining work on for a first design release of this style are implementation details (bug fixes, packaging for use as a default style, etc.) which I'll work with developers on - if anyone here wants to help out with that feel free to chime in. We'll do another design cycle like this in the future once we get some real-world validation and feedback. If you made a suggestion, rest assured that I tried it - every suggestion was seriously considered. Some feedback got incorporated directly, some were modified a touch, some served as inspiration for another design choice. Hopefully, like me, many of you will have learned something interesting along the way and are motivated to put together some QML styles of your own to share. Hey, do like I did and start a thread and get the positive, helpful feedback of our fellow community designers! We can request the inclusion of any successful design you come up with as an option and, who knows it might be so good that it gets picked as the default in Plasma or by a distro. ![]() Ok, so I have to beg just a couple more favors from the community:
Once again, THANKS for all the brilliant feedback and positive energy everyone here provided. Much respect. P.S. For clarity, "first design release" does not necessarily mean it will make the first release of Plasma 2 (which is getting close). |
Registered users: Bing [Bot], claydoh, Google [Bot], markhm, rblackwell, sethaaaa, Sogou [Bot], Yahoo [Bot]