Thank you so much for working on this, Hugo!
One small remark: From the Breeze perspective, the blue line should probably be on the right because that's where the content is (in the Plasma theme, it is supposed to be like that).

Code: Select all

In principle, palettes already have a "link" color (though against Base background, and not Window)


Yes, I know - but the Base ./. Window conflict as well as esp. that qtconfig did not allow to configure the link color (though meanwhile possible) and that virtuality uses a limited palette anyway made me rather generate it on the fly

Code: Select all

Finally, after testing the frame removal and custom (side) selection, I must say it does work well with some kcm (and app config pages) and not well at all with some other, especially when the page has no framing at all: you end up with some text and icons floating erratically in mid air, with little visual alignment one with respect to the other.


KDE and frames is a story of it's own - there're too many in general and otoh it really lacks some =)
I assume you've seen the virtuality approach on this global issue ("too many lines")

Right/left alignment of icons and text (depending on ::viewPosition()) instead of the horizontal center might indeed help to build an implicit front w/o being too intrusive (against an explicit frame in the current page) - this would also match the formlayout HIG.

Hi,
After experimenting some more, and actually pushing the code (argh), to be honest I think the idea sadly does not work:

http://wstaw.org/m/2014/09/10/plasma-desktopsH4453.png

To be compared to:
http://wstaw.org/m/2014/09/10/plasma-desktopJh4453.png

Admitingly, the second does not look so good either (all because of the scrollbar), but stil better (in my humble opinion) than the first ...

Another example where things do not look so nice:
http://wstaw.org/m/2014/09/10/plasma-desktopZj4453.png

And to finish on a positive note, this one might be ok:
http://wstaw.org/m/2014/09/10/plasma-desktopWe4453.png

Opinions welcome

Hugo

Probably just changing the existing widget won't work because existing UIs were designed with the current look of the sidebar in mind.
What about creating a new widget based on the old one but with the new styling, deprecate the old one, and try to port applications over to the new one when they work on their UIs so that they can be made to work well with the new one?

And about the highlight: I don't know if the small bar as highlight was really intended to be the highlighting mechanism in general (we still have both variants of highlighting in the Plasma theme). Andrew can surely tell us more about his vision there, but he's on vacation now so it might take a few days until he reads this.

colomar wrote:And about the highlight: I don't know if the small bar as highlight was really intended to be the highlighting mechanism in general (we still have both variants of highlighting in the Plasma theme). Andrew can surely tell us more about his vision there, but he's on vacation now so it might take a few days until he reads this.

Oh this, I hope not
Right now it is only used for these (detected) side panels, to follow some mockups seen earlier in this thread.
Other selected areas still appear as flat squares surrounding the entire item.

I was not sure from the beginning the "tab bar" would be the optimal solution. I mean, sure it looks nice in the mockup given by Anton, but imho consistency in the style is more important than a tab bar instead of an rectangle selection that does not look bad at all imho. Only thing I do not like about the current tab bars (apart from the white framed underground):

1. the bold font

2. selection is more a rectangle than a square.

This is much nicer done imho in the sidebar of cantata given as an inital example at the start of the thread.

please pretty please someone provide a mockup of how it should look + with a scrollbar+ on it.
(even an horizontal one, if you talk about also flattening tree lists), in comparison to how it look now ...

Hugo, thanks for your interest when I have time I will try to do some mockups, but maybe someone else who has more expertise could do them before me.
The issue with the scroll bar remains though, since nobody has come up with a solution for it yet.
Since I am not sure yet what to do about the scrollbar, doing a mockup does not make sense yet.

Here are some screenshots from earlier comments in this thread:

kdeuserk wrote:...
So in general,

should look like

in the future.


Davids suggestion was, that the same design concept should apply to tree structures in the UI, so that

should look like

I think this should really be considered, because we there is simply no reason to isolate the sidebar area from the rest of the UI.
...

kdeuserk wrote:VLC does it like this:

maybe the text color should be white there ...

EDIT: With oxygen the way dolphin does it does not look that wrong to me (and in my imagination even without the frame it would be fine):


But imho we can have a tiny frame like the one in dolphin.

Hugo, as always thanks for tackling this.

I think we'll likely need to treat these visually like lists instead of tabs (we don't usually provide scrollbars for tabs and, more generally these behave like lists). I agree though that the visuals with a scrollbar need to be resolved.

I'll try to come up with something shortly (still on vacation). Of course if anyone else has ideas don't be shy about sharing them.

Edit: Actually, consider this a request to our VDG community to help out with this. The challenge, as Hugo stated, is to come up with a visual design for these sidebar list selections for the Breeze style, including making sure it looks and works well with or without scrollbars as well. Just take your best shot at it, don't worry about being right or wrong, good or bad.

After a few days we'll see what we've come up with. Good luck!

I thought I'd throw my hat in on this one with an idea, and a butchered mock-up.



Fairly self explanatory I think. The blue bar on the left would have to be the default when there is no scrollbar I think. I did wonder whether the blue bar on the left would still be necessary, but I don't think it would look right without it; another opinion on that one would be great though.

Having said all that it might look better just have the blue bar on the left and leaving the scrollbar as is. Of course, whether it is possible to change the scrollbar is another story.

Edit:
Negative space for the blue box approach



Might be served better by some slight curves on the scrollbar edge with the negative space.

Another idea I had was to keep a dividing line as a default, that would transform into a scrollbar when more items were added:

Before:



After:



The thickness's of the lines would need some thought I think, as well as the transformation effect.

My idea (though this would require the widget to be changed, since I find that scroll-bar inappropriate):



SVG: https://drive.google.com/uc?export=down ... 2ZIZGEyMmc

The icons of the sidebar are from Cantata (http://kde-apps.org/content/show.php/Ca ... ent=147733) by Craig Drummond.

With this approach you could also implement the tab bar without any problems, though like I said, I am not sure about the tab bar.

The solution for getting rid of horizontal scrollbars could be similar.

If you do not like that approach, I would try to leave the scroll-bar, see the above screenshot how it's currently done in dolphin and I am okay with it.

For me I change the navigation bar in dolphin that I don't see the scrall bar.

When the scrall bar was necessary, than I don't understand why every scrall bar is blue. for example when navigation through files the actual area is not the sidebar, so I don't need the scrall bar in blue, because the focus in not at the sidebar. when the focus isn't there the scrall bar could be gray or unvisible until the focus is there.


In addition the Icon size slider or any other slider could be gray (like pused icons) to.

My try on the horizontal space problem:



Embedding images here in the forum is problematic, to see all of the mockups in proper resolution see here: https://drive.google.com/file/d/0B-ihXi ... sp=sharing (simply download and open with gwenview to properly zoom) or directly get the svg: https://drive.google.com/uc?export=down ... WE0dEhHY2s

Thanks for all the ideas for how to handle this side panel, everyone.

So after all the feedback and going through a few ideas of my own, I think it comes down to this:


If the content area has some kind of vertical reference line (framing, tab frame, groupbox, etc.) then the no-frame side-panel generally looks just fine (mockup A). Absent that vertical reference line, these center aligned icons have no alignment reference and "text and icons floating erratically in mid air" as Hug correctly identified (mockup B). Incidentally, when the side panel list is long enough to show a scrollbar, the scrollbar itself provides enough of an alignment reference to make things look a touch better (mockup C - ignore the incorrect scrollbar length). But we can't rely on the scrollbar always being there.

The side-panel widget can't know if the content area has enough of a visual alignment reference to depend on - so it needs it's own. Yes, I think that does mean that does mean it's own frame (mockup D). Yes, that's pretty much how it looks today. Sometimes, an existing solution may be the best solution.

As for how to handle the scroll bars. Either mockup E or mockup F I think would be fine. I have a very slight preference for E because it might be a little clearer that the scrollbar is associated with the list, not the content area. (Again, ignore the incorrect scrollbar length in the mockups.)

One possible addition might be to offer an option on the widget to turn the framing off, so that application designers can decide if the other visual cues (like content area framing) provide sufficient alignment references. At the widget level, I think there's only so much that can/should be done to solve all the potential visual issues that emerge when used in an application.

Hope this helps! And thanks for everyone's feedback on this.