lucashappy wrote:Alake, try to add the following line

Code: Select all

 __editor: Item { visible: !control.enabled}

inside the ComboBoxStyle. Here it resolved the overflow on the editable combo box.

Thanks SO much lucashappy! Fixed! MOAR please!

Here's a quick update after considering some of the feedback so far:

scummos wrote:Also is it planned to have a consistent style for widgets and QtQuick Controls?

Yes, the visual design is intended to be the same for both. We can complete the design for Qt Quick Controls much more quickly so we're directing our efforts here first to establish the visual design of the UI controls. Then we'll work with whatever QWidget solution to match that visual design. It'll take time, but the hope is for the best result. Obviously, we welcome help to make things move faster.

@othersimon it's difficult to tell from static screenshots but the control that has active focus, as would be the case with OK/Cancel buttons, is outlined in the highlight color. Running the live demo as described in the original post should help understand this behavior better.

@mmistretta and @KazAugustin, we really appreciate the feedback. I invite you and everyone else to carefully read the bullets in the original post and my follow up comment regarding the window decoration (different thread), debating the merits flat design, "looks like Windows" comments.

Keep 'em coming and thanks everyone for all the help and feedback so far!

Great work!!!. Just my two cents : I really like the clean approach but maybe you can use subtle gradients. Also a ligther background for the radio buttons and checkboxes could look better. Something like this:

I tried play with the busy indicator a little and end up with this.



Its a little whimsical so maybe does not fit the style, but it has a lazy inter spiral that i find slightly hipnotic. Here is the code to replace the busy indicator with.

Code: Select all

    busyIndicatorStyle: BusyIndicatorStyle {
        indicator: Rectangle {
            id: __busyIndicatorBase
            visible: control.running
            implicitWidth:  32
            implicitHeight:  32
            radius: 18
            color: sysPalette.window

            Rectangle {
                anchors.centerIn: parent
                width: 28
                height: 28
                border {
                    width: 4
                    color: ColorUtils.fullColorString(sysPalette.buttonText, 0.3)
                }
                radius:14
                color: "transparent"

                Rectangle {
          anchors.horizontalCenter: parent
                    width: 28
                    height: 8
                    color: __busyIndicatorBase.color
                }

                Rectangle {
          anchors.horizontalCenter: parent
                    width: 16
                    height: 16
                    color: ColorUtils.fullColorString(sysPalette.highlight, 1.0)
                    radius:8
                }
               
            }
            NumberAnimation on rotation {
                running: control.running
                loops: Animation.Infinite
                duration: 2000
                from: 0 ; to: 360
            }
        }

I have to say I really like GreatEmerald's variation of the tab style with subtly rounded corners!

I also kind of agree with the sentiment that the flatness and plainness in the style has gone a bit too far. I generally like flat designs but this strikes to me as too featureless. Maybe more slightly rounded corners, color contrasts or subtle gradients? The biggest problem for me in the original screenshots was the button, which didn't really look like a button but just a label with a frame. The updated version is better because there is a slight color contrast between the button and the background.

Finally, I'm a big fan of the Ubuntu's earthy brown/orange colors and lucashappy's screenshot made me hope I could one day have them on my KDE desktop ...

Nice work Andrew and the others!

I agree that slightly more rounded corners would be nice and maybe some suptle gradients, but pleasen not in the way Oxygen did it :s.

About the busy indicator: I always liked the idea the WebOS team had [1][2]

[1] http://latest.enyojs.com/lib/mochi/samp ... ample.html
[2] https://github.com/enyojs/mochi/wiki/Mochi-Designs

alake wrote:One other quick thing I thought I should share since it's already come up. "Looks like Windows/iOS/Android/GNOME/whatever" probably won't influence me much, and really shouldn't influence us much one way or another. What I am convinced of is that we can put together something that looks and works beautifully, representing KDE, without worrying about if it looks similar to, or different from, whatever else is out there. The design vision and visual design guidelines are available to help guide us.

I disagree. See, the first impression is what matters the most, and it's the worst thing that can happen if the first impression is "oh, it's a cheap Windows/iOS/Android/GNOME/whatever knockoff". When that happens, the product becomes off-putting, because you unconsciously start thinking of it as one.

One great example of this is Firefox Australis. Everyone hates it mostly because it looks like a Chrome knockoff. And no amount of talking that it's the interface that Thunderbird uses and that similarity is accidental is going to change that perception. That's just a psychological fact: people subconsciously do comparisons. When one product suddenly becomes visually too similar to another, this signals to people that the later project made a decision to copy the earlier project, which means one of the two things: a) the later project was bought out by the earlier project and thus is no longer an independent entity, or b) the later project has lost confidence in their own direction, gave up and decided to follow the herd. Both means that there is no more reason to use the product and it's better to just switch to the one that is being copied.

So being aware of the other interfaces in use is important, in my opinion. The looks should be as unique as possible to not create such subconscious comparisons that give users the wrong impression. Which doesn't mean they should be disregarded entirely, of course – one of the things that makes KDE great, in my opinion, is that it has a classic Windows-like desktop layout, but it's all more polished and offers more than Windows. So with looks, the same should apply: look at other interfaces, take the best elements from them and improve upon them to get a unique look. If the result is too similar to one UI, take steps to make it look more unique.

By the way, even the guidelines you linked to say this:

Edges are sharp and distinct. Corners are sharp but non-threatening; ~2px or 3px corner radius.

The current widgets ignore this guideline and that's partially what makes it so off-puttingly similar to Metro. You can clearly get injured on those tab corners (0 px radius), and the button corners are dangerous as well (1 px radius). If you made them all 3 px in radius, everything suddenly would look much better and much less similar to Metro.

alake wrote:Here's a quick update after considering some of the feedback so far:
http://wstaw.org/m/2014/04/15/feedback2.png

The changes do look better. Though you should probably just disable the window decorations for these previews, they are distracting

Paulms wrote:Great work!!!. Just my two cents : I really like the clean approach but maybe you can use subtle gradients. Also a ligther background for the radio buttons and checkboxes could look better. Something like this:
http://wstaw.org/m/2014/04/15/pantalla2.png

Yes, exactly. Subtle gradients are your friends, not your enemies. I also like the stylish colour play on the tabs you did there.

Sogatori wrote:About the busy indicator: I always liked the idea the WebOS team had [1][2]

[1] http://latest.enyojs.com/lib/mochi/samp ... ample.html

It's too liquid to fit the KDE style, but I agree with the direction, something like this is the innovation I'd like to see.

@alake: In your mockups the first radio button is underlined. Whether or not it was made intentionally, for instance as on-hoover effect, you should think about another solution. Underlines (in particular in blue color) is preserved for links and must not get mixed up.
All other design looks pretty nice.

Heiko Tietze wrote:@alake: In your mockups the first radio button is underlined. Whether or not it was made intentionally, for instance as on-hoover effect, you should think about another solution. Underlines (in particular in blue color) is preserved for links and must not get mixed up.
All other design looks pretty nice.

This seems to be a bug (in QML?). The underlining only happens after the user changes to another tab and back again. And there's no way to make it go away.

All right, so I tried to consolidate everything into one image now:

This is a mod of alake's image to show how it should look according to the 3px rounding guideline. It no longer looks like Metro! I rounded the tabs, the boxes, the buttons, the borders (and tried to do a better job at anti-aliasing). I also made the borders 2px thick so the line would look consistent (I feel like 1 px is too sharp). The button I borrowed from Paulms (which I think is a bit too much, the colour should be more white, but I didn't want to bother with that here). I noticed that alake did actually change the background tone a bit, but I think it's a bit too subtle, so I made it stronger, and applied the cardboard grey to the main part of the window (which seems to me like more according to the guidelines).

I also still feel like the plain blue could use a very subtle gradient as well, but I'm not sure how best to implement that.

Hi, I modified GreatEmerald's mockup with a little more subtly shaded button:



I also wanted to try something new so here's one with a horizontal gradient instead (I know it's a bit crazy.....)

Tuukka wrote:Hi, I modified GreatEmerald's mockup with a little more subtly shaded button:



I also wanted to try something new so here's one with a horizontal gradient instead (I know it's a bit crazy.....)

I like the subtle vertical gradient! It look good, could you add the same gradient to the slider handle?

alake wrote:

Hm, if truth be told, I'm not sure about this. It looks extremely big and clumpsy to me... IMO it should just be a little more.. subtle. This looks like some UI designed for a tablet.
Just my first impression though. But I appear to be the only one?

Tuukka wrote:Hi, I modified GreatEmerald's mockup with a little more subtly shaded button:

Thanks! Yes, that's pretty much exactly how I think it should look like. Perhaps just a point stronger, but it looks great in any case.

Tuukka wrote:I also wanted to try something new so here's one with a horizontal gradient instead (I know it's a bit crazy.....)

That's another thing I was considering. Well, for one, your gradient there is actually inverted, the lighter part should be on the left (to simulate that the "sun" is shining from the top left, which is what the shadow around the button is indicating). In general, it might be interesting to do a 45° gradient. Though it might be too flashy for the style...

What I think might be interesting is a gradient on the blue lines for the sliders, but I'm not sure how it should behave when sliding... Shifting the colour is probably not desirable, but having it statically just slightly darker on the right could be interesting (it's also a visual cue that says it's increasing something when sliding to the right).

Nuc!eoN wrote:Hm, if truth be told, I'm not sure about this. It looks extremely big and clumpsy to me... IMO it should just be a little more.. subtle. This looks like some UI designed for a tablet.
Just my first impression though. But I appear to be the only one?

A bit. This must be due to the checkbox, radio button, slider handle and drop-down boxes. Other elements are in fact of the same size as it is right now. However, I don't think it's a bad thing, given that resolutions nowadays are typically large enough to support that (although some sort of scaling down option would be awesome for things like netbooks).

Nuc!eoN wrote:Hm, if truth be told, I'm not sure about this. It looks extremely big and clumpsy to me... IMO it should just be a little more.. subtle. This looks like some UI designed for a tablet.
Just my first impression though. But I appear to be the only one?

Well, I'm looking at it on a high DPI screen so it looks pretty good... I just checked it on an ordinary screen and everything indeed looked pretty big. Maybe alake has a high DPI screen too? (of course the style should adapt to the DPI of the user's display)

GreatEmerald wrote:

Tuukka wrote:I also wanted to try something new so here's one with a horizontal gradient instead (I know it's a bit crazy.....)

That's another thing I was considering. Well, for one, your gradient there is actually inverted, the lighter part should be on the left (to simulate that the "sun" is shining from the top left, which is what the shadow around the button is indicating). In general, it might be interesting to do a 45° gradient. Though it might be too flashy for the style...

Good point about the shadows! Here's a button where the lightest point is at the top left corner. I find it quite pleasing to the eye...



Too bad it's not straightforward to do this in QML...