verbalshadow wrote:Sorry, I have been busy. Ok, I have been thinking about tabs and playing with the style. After many attempts with ways to find something that looked nice and did not over use the highlight colour here is what i have come up with: a simple triangle in the left corner of the tab that is the highlight colour when select and slightly darker grey on inactive tabs. When hovered over the corner is still grey giving the impression of a folder system in a drawer.

Pretty neat idea verbalshadow. It's a well restrained use of that highlight color. I'll take a look at it tonight. Thanks!

psst. Because this thread was so ridiculously successful I'm hoping to run a similar community design cycle for the default window decorations soon, but don't tell anyone I told you about it. <giggles> stay tuned!

Just to close the loop on this, I made a few minor updates to refactor the QML files into a format suitable for installation as a default Qt Quick Controls style, and submitted it to the Plasma team.

Thanks again for everyone's participation.

Much respect.

Here's a patch for the editable combobox size bug with large fonts:

Code: Select all

diff --git a/ComboBoxStyle.qml b/ComboBoxStyle.qml
index 5573814..820ea55 100644
--- a/ComboBoxStyle.qml
+++ b/ComboBoxStyle.qml
@@ -44,6 +44,7 @@ ComboBoxStyle {
         }
         TextFieldBackground {
             visible: control.editable
+            anchors.fill: parent
         }
         ScrollArrow {
             anchors.verticalCenter: parent.verticalCenter


Hi !
Congratulation for your great work !
I just updated the controls this morning, and figured one little thing :
When you select a text field or an editable combo-box, there is a quite thick outline around the control (I like it !)
The problem is that the thickness of the outline is not the same depending on the control type : It it thiner for comboBox, text box and table.

https://fr.owncube.com/public.php?service=files&t=c4134a1ff6d746524ed65449c0aaa281
https://fr.owncube.com/public.php?service=files&t=7dd6f03428c8d7a72e5a0434bcddb8ea
https://fr.owncube.com/public.php?service=files&t=b4c02628a6b20bba75c6b846dc4bc292

Was it intended ?

On another side, i must admit that I am a little bit disappointed by the checkboxes that I find too invasive once marked as checked (although I like the initial idea)

Best regards

Tuukka wrote:Here's a patch for the editable combobox size bug with large fonts:

Code: Select all

diff --git a/ComboBoxStyle.qml b/ComboBoxStyle.qml
index 5573814..820ea55 100644
--- a/ComboBoxStyle.qml
+++ b/ComboBoxStyle.qml
@@ -44,6 +44,7 @@ ComboBoxStyle {
         }
         TextFieldBackground {
             visible: control.editable
+            anchors.fill: parent
         }
         ScrollArrow {
             anchors.verticalCenter: parent.verticalCenter


Ooh, that's right a forgot about that fix. I'll add that tonight. Hey Tuukka if you have a KDE developer account you can just push those changes directly to the repo (If not I recommend it since your contributions here have been immensely valuable and we have a QML window decoration thread coming up in the next few days you might be interested in). If not I'll push these updates when I get home.

Thanks again!!!

Hi,
I tried to play with the Controls and try to assign a thicker border to the TextArea and TableView when they are selected (and see whether it improves the visual consistency).
However, it seems that modifying border.width in the TextAreaStyle has no effect. Is it a known qml behaviour ?

Best regards,
T

tsokar wrote:Hi,
I tried to play with the Controls and try to assign a thicker border to the TextArea and TableView when they are selected (and see whether it improves the visual consistency).
However, it seems that modifying border.width in the TextAreaStyle has no effect. Is it a known qml behaviour ?

Best regards,
T

Thanks for taking a stab at trying to figure that problem out tsokar! We're all learning QML as we go. There are some nuances to the style for this that I haven't quite figured out yet. I think it'll ultimately be solvable, but it might take a little more digging like you have so far. Obviously, if anyone finds the trick to solve this, definitely share it here.

Am I correct in assuming this is the one and only official future KDE user interface style?

qwach wrote:Am I correct in assuming this is the one and only official future KDE user interface style?

I'd say this UI controls design is being proposed for the eventual default. However, just like with the cursor themes, my personal opinion is that if this community comes up with great UI controls designs, there no reason we can't propose their implementations for inclusion as well. I think Jens shares that view, but I won't speak for him. Distros, of course, can pick whatever default they want.

Hope this helps!

alake wrote:

tsokar wrote:Hi,
I tried to play with the Controls and try to assign a thicker border to the TextArea and TableView when they are selected (and see whether it improves the visual consistency).
However, it seems that modifying border.width in the TextAreaStyle has no effect. Is it a known qml behaviour ?

Best regards,
T

Thanks for taking a stab at trying to figure that problem out tsokar! We're all learning QML as we go. There are some nuances to the style for this that I haven't quite figured out yet. I think it'll ultimately be solvable, but it might take a little more digging like you have so far. Obviously, if anyone finds the trick to solve this, definitely share it here.

The trick was to adjust the padding property. The contents will be drawn on the frame, so unless the frame is larger than the contents it will not be seen (padding does this). Unfortunately, rounded corners will still be partly covered by the contents. This becomes a slight problem with the TableView when it's not active and has a thin border.

I went ahead and pushed the fix.

It'd be better if the frame would be drawn on the contents. The only thing would be to avoid filling it with a color because that would cover the contents. Maybe something to suggest to the Qt devs.

Tuukka wrote:

alake wrote:

tsokar wrote:Hi,
It'd be better if the frame would be drawn on the contents. The only thing would be to avoid filling it with a color because that would cover the contents. Maybe something to suggest to the Qt devs.

I did. https://codereview.qt-project.org/#change,73101
It was rejected as it breaks windows. It can be worked round with good use of negative margins on the control object and a low z index.

david_edmundson wrote:

Tuukka wrote:It'd be better if the frame would be drawn on the contents. The only thing would be to avoid filling it with a color because that would cover the contents. Maybe something to suggest to the Qt devs.

I did. https://codereview.qt-project.org/#change,73101
It was rejected as it breaks windows. It can be worked round with good use of negative margins on the control object and a low z index.

Good to know! I'm not quite following you though... what do you mean by negative margin? And how can you use z indices here? I tried to play around with the z value but it didn't have any effect on the order of drawing things.

The one thing that definitely needs to go is the blue title text, it's awful to read in many situations. Centered text would also be nice - as I previously wrote in another topic:

You'll usually be focusing on the center of the window, so glancing to the left all the time is just annoying.

I made a mockup with both changes applied, as well as one with that and a one-pixel-width blue line below the title bar for some visual separation. Specifically: You may be able to drag the window in other areas too, but the title bar still has its own context menu (as it should) and doesn't affect what goes on below it. It's also another indicator whether a window is selected or not. There's another version with a 2-pixel wide line, but that might be too much.

https://www.dropbox.com/s/fui1nh3rq48tyht/windec-line2px.png
https://www.dropbox.com/s/hcuaya6wtbk0kq8/windec-line.png
https://www.dropbox.com/s/tyekkxp7yel6u82/windec-noline.png

qwach wrote:The one thing that definitely needs to go is the blue title text, it's awful to read in many situations.

Window title design is not a part of a widget style so you should take these points to some other thread. Widget style is about how the actual contents of windows are drawn, whereas window decorations are an entirely different matter.

A bit of a offtopic, but did anybody seen new firefox theme? It looks really good and slick!