![]() Registered Member ![]()
|
Very nice! I think we've found a good balance in most aspects. Once we can try this on real applications it'll probably be easier to do some more adjustments with sizes and so on. I'm very happy that we'll have a QtQuick controls style that matches the QtWidget style so that people can start writing native looking QML UIs for KDE apps as soon as the Frameworks come out. Just some random observations:
There's also a style for TableView but it's not included in the demo app? BreezeStyle.qml seems to import QtGraphicalEffects and QtTest even though they don't seem to be used. Might be a good idea to remove the imports to minimize the number of packages required to run the demo. It's a good idea to try the style with very large fonts as well (that are needed for high DPI screens). The button size will adjust to the size of the label, whereas text fields will stay fixed at 32pix. In general this is no problem, but currenctly there is a bug in the editable ComboBox, whose height will be determined by the label (even if it's invisible) but it will still be drawn 32pix high. This can be fixed by adding anchors.fill: parent to the background: [code] TextFieldBackground { visible: control.editable anchors.fill: parent }[/code] |
![]() Registered Member ![]()
|
Although the filled check box is a stunning graphical effect I'm afraid it diminishes usability. Using a check mark, or the like, differentiates the control from radio button on a further perceptual dimension than only the shape.
|
![]() Registered Member ![]()
|
Great progess everyone! It looks really nice already.
I only think that some elements could use an ever so light gradient, too. Like the buttons. I have questions though: It seems that the VDG has descided to embrace qtcurve, does that mean that the development of the GTK+3 engine will be continued again? Currently only oxygen is able to give gtk+3 applications a somewhat native look. |
![]() Registered Member ![]()
|
The buttons already have a gradient. It's so subtle that its hard to see but it does make it more button-like compared to a completely flat color. |
![]() Registered Member ![]()
|
Oh yes, I ment to say that these controls could use the same kind of slight gradient as used on the buttons. Words are hard ![]() |
![]() Registered Member ![]()
|
Oh yes that was just an oversight, just uncomment the 4th tab in Breeze.qml to see that. ![]()
Great catch thanks! If you see anything else like this that we can fix and tidy up, please share. As I get more info on packaging for use as a QtQuick system style, the wider community will certainly be grateful for your help finding and fixing issues like these. Of course if anyone wants to jump in and help with any of this, please feel free. ![]() |
![]() Registered Member ![]()
|
Yeah, this exercise was primarily to produce a UI controls design target that happens to be directly usable for QtQuick-based UIs. QtCurve is just a low workload option we've suggested to get some relatively cheap visual unity for non Qt-Quick based UIs. I know I would certainly welcome a C++ QStyle or GTK+ 3 or any other implementation of this design if someone was willing to do it. ![]() |
![]() Registered Member ![]()
|
While that is certainly true, we don't know if the negative effect on usability is significant. In Andrew's preliminary user test, it didn't seem to be. We can easily repeat the test with a larger sample (if everyone here asks just five people, we'd already have a good sample) and see whether they can easily enough distinguish checkbox from radio button. Good design needs to strike the right balance between aesthetics and usability, so if we can show empirically that the negative effect is negligible, we could still accept it for the gain in aesthetics. If we find that some people have considerable problems with the distinction, we should think again. |
![]() Registered Member ![]()
|
|
![]() Registered Member ![]()
|
Nice presentation ![]()
Perhaps the slider handle could have the same gradient as the buttons..? Since we are preparing for the first release, I thought ColorUtils.js could use some cleanup. Because we always use color objects (not strings) it was easy to greatly simplify the functions. Also I got rid of blendColors2() because it has the same purpose as Qt.lighter(). It doesn't always behave exactly the same way but I found parameters for Qt.lighter() that give practically the same button gradients as before. Here's the output of 'git diff':
|
![]() Registered Member ![]()
|
All of us will perceive the difference between round corners of 2px and 5px, or the like. But using a program efficiently you don't want to take attention on this tiny distinction. However, go ahead, if I'm the only one with concerns. It's very easy to change this aspect of the theme later, I guess. |
![]() Registered Member ![]()
|
I really like this new widget style. Great work! But I agree with Heiko that the difference between radio button and checkbox is too small. Would it destroy the aesthetics, if you would add a checkmark inside the box? Crude example proving that I'm not a designer ![]() ![]() |
![]() Registered Member ![]()
|
Looks wonderful! Small suggestion: how about making the length of the two differently colored 'bar sections' in the indeterminate progress bar unequal? I would be curious to see what it looks like, if either the dark blue or the light blue bar section would be very short, so much that it is as long as high (i.e. a square). Could you give it a try? |
![]() Registered Member ![]()
|
Yay, we got our rounding!
![]() I agree that the tabs are pretty much the only thing left. I thought the previous suggestions for the tabs were neat, but if you think they don't work well... Hmm... How about a lighter shade of grey? Or maybe even the same colour, but put the button-like gradient on the active tab? That, with the lack of the bottom border, may be enough to differentiate it. Another thing to remember is to change the highlight method on the text elements so it wouldn't just be a blue underline. I also think that the current checkbox design is good enough as it is. I know that several game UIs use such a checkbox design and it doesn't confuse anyone. |
![]() Registered Member ![]()
|
Excellent! Thanks Tuukka. I'll incorporate these changes in the next few days. I just wanted to quickly clarify for others here again that "release" here is about release of the design to the developers and packagers for incorporation when they see fit. Plasma 2 is already well past the feature freeze date, so no one should reasonably expect this in the initial Plasma 2 release in June Plasma 2014.06 release. Oh and I'm still looking for a set of extras hand to do up some QtCurve settings that mimics this as closely as possible. Thanks again! |
Registered users: Bing [Bot], claydoh, Google [Bot], markhm, rblackwell, sethaaaa, Sogou [Bot], Yahoo [Bot]