Heiko Tietze wrote:

colomar wrote:If a sidebar needs a scrollbar, It's likely that something is wrong with the application design. We should probably put an advice like "do not put more items in the sidebar than fit into the default height of the window" in the HIG somewhere.

Agreed, and I would keep the simple solution too. But the user may resize the window to an abnormal height. We cannot presume that scrollbars are never shown,

No of course we can't assume that. I just meant to support Hugo's assumption that the scrollbar will rarely be seen, so it might not be worth obsessing about it.

davidwright wrote:I wonder if it would be possible to restrict the scroll bar height so that is the same as one of the tablets, no matter how many items are in the list. It might make it look slightly better? If it were then possible to make it 'jump' through the items (keeping the scrollbar in line with the tablets) as you scroll it would give it a more unified feeling.

I'm not sure if I understand your suggestion correctly. The way I interpret it, the scrollbar is always at the position of the currently selected item. That means that if we click the scrollbar at the bottom, the bottom-most visible item would be selected, right? How would we scroll to the ones below, then?
Plus, if the scroll bar always kept the same length, we'd lose the ability to communicate how long the list actually is, wouldn't we?

colomar wrote:I'm not sure if I understand your suggestion correctly.

He wants to remove the viewport size indication from the scrollbar an pass it a fixed size (like a slider button, just bigger
That's technically possible, though convolutionary.

It doesn't fit the illustrated grooves, but I once experimented with a scrollbar where the groove (only a line) indicated the scroll length and the slider had a static size, ie. the groove shrunk depending on how much there was actually to scroll rather than that the slider grew.
I frankly dropped it because it was too weird to have the slider only pass a limited section of the view edge.

I guess the problem is keeping the consistency between having the scrollbar and not having it?

Do we really need to have something connecting the module in the sidebar to the content bar? Just remove that to keep the consistency and it's done.

prosmaninho wrote:I guess the problem is keeping the consistency between having the scrollbar and not having it?

Do we really need to have something connecting the module in the sidebar to the content bar? Just remove that to keep the consistency and it's done.

The connection between the selected module and the content bar makes sense because the content is directly dependent on the selected item.
Since a scrollbar on a side bar should always be a rare case, the advantage of visually indicating the connection between selected sidebar item and content outweighs the disadvantage that it looks slightly weird with the scrollbar.

Was there a problem in using the arrows suggested by kdeuserk?

That GUI element does not exist - one would have to branch QAbstractScrollArea (that does not mean "reimplement it", but add a new mode or an entirely new kind of scrollarea)

A general issue with such buttons (that does not necessarily apply in this context) is that they're either dog slow (click, row, click, row, click, row ...) or imprecise (pagewise scrolling only. Even click, hold, accelerated autoscrolling is not "precise"). Also they do not hint the size of the area out of sight.
That's why scrollbars are generally considered superior in any functional regard (and why this GUI element does not exist

luebking wrote:That's why scrollbars are generally considered superior in any functional regard (and why this GUI element does not exist

The gui element exists for tabs.

While luebking is right about the general case, I am not sure if its always the best to consider the general case. Applications with 100 sidebar entries are bad designed imho. (List items are another issue).

Just realized I did not answer this one (sorry andrew, post notifications are a bit erratic here)

alake wrote:Perfect. Thanks Hugo. Is there an API option in the sidepanel widget for developers to turn on/off the frame? Just curious. That would allow the application layout designer/developer to decide show/hide the framing if sufficient visual alignment references exist elsewhere in the application layout (like in the "A" option).

Yes there is. The requirements are:
- Widget must derive from a QAbstractScrollArea
- Widget must set the property "_kde_side_panel_view" to true (widget->setProperty( "_kde_side_panel_view", true );

I just tested it with Okular, and it works: http://wstaw.org/m/2014/09/26/plasma-desktopgm2048.png

Ultimately I'd like to move this (custom) property name as well as others to a more generic place, accessible (without knowing the string by heart) to all applications, in e.g. Thomas' KStyleHook (or KStyleExtension, or QStyleExtension, whichever you prefer). Thomas ? Oppinion ?
(it is also still time to rename the property if not appropriate).

+1 for 1px

Done

hugo.pereira@free.fr wrote:I just tested it with Okular, and it works: http://wstaw.org/m/2014/09/26/plasma-desktopgm2048.png

I'm just gonna repeat myself: You've done a great job here Hugo!

hugo.pereira@free.fr wrote:Hi all,

Some screenshots from my latest experiments, based on (part) of the feedback recieved here

1. http://wstaw.org/m/2014/09/24/plasma-desktopcN2032.png
When the sidepanel actually has focus

2. http://wstaw.org/m/2014/09/24/plasma-desktopOj2032.png
When it doesn't has focus (i.e. the focus is on the right side, where something is edited

3. http://wstaw.org/m/2014/09/24/plasma-desktopiG2032.png
With scrollbar
Obviously the scrollbar breaks the connection between the selected item and the vertical line, but since scrollbars are (should be) a corner case, I don't think it matters too much. Also, the fact that it is left of the vertical line, makes it clear that you will scroll the side panel.

... now these screenshots are from some of my 'own' configuration panel.
In KDE land it looks a little bit different, due to margins, toolbars, etc:

4. http://wstaw.org/m/2014/09/24/plasma-desktoptn2032.png

Comments/suggestions are welcome,

Hugo

Thumbs up from me Hugo!

hugo.pereira@free.fr wrote:To be honest, my take on scrollbars would be that they should look identical everywhere, for consistency to the user.
Now maybe scrollbars are just too fat and in your face everywhere ?

Feel free to experiment with a slightly narrower scrollbar Hugo. I'm starting to think they're a little fat in use as well. So maybe with the same functional/clickable width but maybe just slightly (2px?) narrower. Holler to let us know how that might work.

alake wrote:

hugo.pereira@free.fr wrote:To be honest, my take on scrollbars would be that they should look identical everywhere, for consistency to the user.
Now maybe scrollbars are just too fat and in your face everywhere ?

Feel free to experiment with a slightly narrower scrollbar Hugo. I'm starting to think they're a little fat in use as well. So maybe with the same functional/clickable width but maybe just slightly (2px?) narrower. Holler to let us know how that might work.

Hi Andrew,
I did play with the scrollbar width and to be honest I find the current 'just right' (if only because it matches well with the arrow width).
Maybe what is not 'just right' is the colors (but I have not experienced with that yes. More precisely:

- *maybe* the dark color for unfocused scrollbars is too dark
- *maybe* one should not highlight (in blue) the scrollbars on focus, (more precisely whe the parent's scroll area has focus) but on mouse-over only.

That would be more inline with what is done with other styles (and what Thomas suggested), but has the drawback to make the style 'more grey' and less colorfull (something which I do like I must say).

I'll post screenshots when I have some on color experimenting

Hi,

I have an sidebar issue. my problem is that the breeze icon set is monochrome for sidebars and toolbar and is available for 16px and 22px.

Since now breeze don't support 32px icons for the sidebar. On the other hand most of the bugs we get for the icons are that monochrome toolbar icons were used somewhere else and it doesn't look good when you have monochrome and colored icons. See the preferences section in most kde apps.



most of the time there were 32px icons used. but the icons are sometimes toolbar icons somethimes mimetype icons or app icons, .... how should I fix this? Never ending story without an good plan and as I have to go to all preferences files it is better to have an plan (HIG).

The bottom line is Breeze is introducing a new design approach that perhaps our existing icon management framework should evolve to support a little better.

Maybe a KDE Frameworks function that lets the application devs specify a preferred and fallback icon. That way we could provide whatever Breeze icons we think make sense for sidebar and toolbar (including 32px icons) and if the user has a different icon theme installed without those icons, it'll fallback to whatever it does today. This may just be an opportunity to help improve our icon management framework for all KDE applications.

alake wrote:The bottom line is Breeze is introducing a new design approach that perhaps our existing icon management framework should evolve to support a little better.

Maybe a KDE Frameworks function that lets the application devs specify a preferred and fallback icon. That way we could provide whatever Breeze icons we think make sense for sidebar and toolbar (including 32px icons) and if the user has a different icon theme installed without those icons, it'll fallback to whatever it does today. This may just be an opportunity to help improve our icon management framework for all KDE applications.

when you look at the konqueror sidebar you will see that there are for a lot of icons toolbar icons available. also it would be a great benefit to use toolbar icons for toolbars or sidebars and app icons when you want to use an app.

your approach is nice but also a lot of work and I can't see an benefit for users that use other icon sets than breeze or oxygen.