Any news on this? I too agree that sidebars need some revamp.

tassos wrote:Any news on this? I too agree that sidebars need some revamp.

I am definitely interested in learning Qt (I started some time ago, but now I have not got time at all to experiment) and refresh the c++ knowledge I gathered in the last year and extend it further.
My idea would be to make an own framework for elements like this / or modify existing ones (I would also like to extend toolbar elements to make them more interactive and flexible.).

But I am not good enough yet to code anything as I am a beginner and that wont change in the next two months, as I am / should be busy with my graduation from school.

So unless a dev picks up the ideas the situation wont change in the next months.

Ok so just a quick comment on this:
I'm trying to find a good way to implement the ideas - the issue is that its a rather massive undertaking and I need to contact a ton of (right now overworked) devs. So I'll start throwing out emails to see if we can get some key devs to chime in on the ideas.

I've managed to remove the border and background from KPageView (the widget responsible for the sidebars).
The result in oxygen:
http://wstaw.org/m/2014/09/04/frameless-sidebar-oxygen.png
If I get a positive feedback here, I'll try to upstream it.

Here is an idea, how to design it for breeze (not sure, wheather this is technically doable, though):
http://wstaw.org/m/2014/09/04/frameless-sidebar-breeze-idea.png
If you like it, I'll try to talk to Hugo about it.

Anton wrote:If I get a positive feedback here, I'll try to upstream it.

And a +1 from my side. It fits perfectly the flat style of Breeze.

+1 for me.
That looks exactly like what was desired by everyone.
As for the Breeze concept it looks nice IMO, but other people here were thinking about using monochrome icons in the sidebar although I think that is unrelated to what you have achieved. Can't wait to see this change upstream.

Very nice!. What about having the vertical blue bar on the right side of the "button"? Since the stuff you are interacting with is on the right side, it might be easier to see

When you use a vertical panel the blue bar is also on the right side, but realy nice.

In the breeze theme the frame of the header has another padding than the other bottom frames.

This is great, please go for it!
Thanks!

andreas_k wrote:In the breeze theme the frame of the header has another padding than the other bottom frames.

This is actually a flow in the application, that result in title frame being not aligned with contents frame
In any case, the frame around page "title" is now gone in breeze too (as it was in oxygen) so that the issue, albeit still present, is less visible

thanks hugo.pereira@free.fr

Hi
I've been playing around with implementing the ideas from Anton
Concerning removing the absence of frames, it obviously should go to kpagewidget
Concerning the "modified" rendering of the selected item, I believe this also should go there because:

- it is hard for the style to detect that it is ask to render the selection for *this* type of lists (as opposed to any list)
- it is even harder for it to alter the text color, so that it uses the highlight 'background' color instead of the highlight 'foreground', which is usually white (when selected and active, and with the current default palette)

Now on the other hand it is quite straigtforward to implement in kpagewidget directly.
Result here:
http://wstaw.org/m/2014/09/08/plasma-desktopna1780.png

The only drawback is that this type of selection would now apply to _any_ widget style and not only breeze, and might not render well with some styles.

For oxygen, it looks like this:

http://wstaw.org/m/2014/09/08/plasma-desktopyg1780.png

which is still acceptable, I think.

Wdyt ?

Below the patch to kwidgetsaddons, for say, anton, to play more with it if need be.
(there are commented lines there two, in case someone want to test the selection on the right side rather than left, though I am not sure yet which one I like the best)

http://paste.kde.org/pxkifbgvx

Best regards,

Hugo

Amazing!

I think patching directly is okay, but what about consistency with other applications that have similar sidebars that do not use that class?

Hugo could you also have look at the widget that is used for example in kmail (despite it being a treeview there)? The white underground does not make sense there either.

Amazing work.

> http://paste.kde.org/pxkifbgvx

- viewport()->setAutoFillBackground(false);
- "opt.rect.setWidth( 4 );" - i first thought this was a slider. Maybe it should be symmetric? (Is it required at all?)
- bear in mind that QPalette::Highlight might not provide enough contrast to QPalette::Window to create well readable text (esp., but not limited to, bright on dark schemes) - virtuality has some code for contrast measuring and builds the QPalette::Link color from QPalette::Highlight this way. iirc KDE already has some color util code somewhere (but i don't know for sure)

luebking wrote:> http://paste.kde.org/pxkifbgvx

- viewport()->setAutoFillBackground(false);
- "opt.rect.setWidth( 4 );" - i first thought this was a slider. Maybe it should be symmetric? (Is it required at all?)
- bear in mind that QPalette::Highlight might not provide enough contrast to QPalette::Window to create well readable text (esp., but not limited to, bright on dark schemes) - virtuality has some code for contrast measuring and builds the QPalette::Link color from QPalette::Highlight this way. iirc KDE already has some color util code somewhere (but i don't know for sure)

Thomas,
Agreed with all the above.
In principle, palettes already have a "link" color (though against Base background, and not Window)
Also, as per whether it should be in the widget or in the style, I was thinking this through a bit more.
In the style is doable, except for the fact that you can't easily detect which widgets would like this type of selection and which would not.
So that would be another case for some KStyleHook property. (e.g. _kde_side_panel_view = true)
Been experimenting this locally.
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.
I'll post some screenshots around later.