I like the minimal design of the new KDE taskbar. However, since I use my KDE taskbar in a vertical configuration, I was concerned how the new minimal design would look if the KDE taskbar was used vertically.

Most likely, the new KDE Visual Design Group already have a design planned, for when the KDE taskbar is in a vertical configuration. But before the taskbar design was finalized, I wanted to be sure that a vertical design was included in the planning.

Thanks for reading.

Source of the image above:
http://wheeldesign.blogspot.gr/2014/03/ ... ort-5.html

Ademos wrote:Most likely, the new KDE Visual Design Group already have a design planned, for when the KDE taskbar is in a vertical configuration. But before the taskbar design was finalized, I wanted to be sure that a vertical design was included in the planning.

As someone else that uses a single main vertical panel - I am concerned that this will end up being the ugly step child again.



Observations:

• Icon Tasks Task Manager widget: makes very inefficient use of vertical space flattened - a rectangular shape, like Windows 7, with a centred icon would be an improvement
• System Tray widget: I would really like scalable System Tray icons - that scale below 22x22 - the best implementation of this I've seen was done by the AWN dock

I would add that the Digital Clock, Homerun, and Pager widgets make good use of vertical space.

Just my opinions of course
Robert

The vertical taskbar in Plasma Next will be themed for accounting for its orientation.

alake wrote:The vertical taskbar in Plasma Next will be themed for accounting for its orientation.

Andrew,

That's great to hear - but a little bit vague!!

I still have an ongoing OCD issue with the KDE System Tray. This chews up tonnes of space (both horizontally and vertically) with a single row of 24x24 icons. To get a panel to get a double row of System Tray icons (the oft quoted KDE Dev team reply to complaints of this nature) requires a huge panel 80 pixels wide/high (to account for icon padding space).

This just can't be right...


I know there is work going on the KDE System Tray specification... But I am concerned that this particular issue will drag onto the next version of KDE (which could mean another decade)...

Robert

I'm sorry rwalker. My comment was specifically with respect to the task bar and really only the visual theme for the taskbar. I honestly can't speak to your specific system tray concerns. For me the systray switches to two columns of icons when my vertical panel width is ~62px which feels about right to me. I don't personally anticipate that system tray icons will ever scale below 24x24 (or 22x22) but that's just my guess. I'm glad you mention it though. Maybe there are opportunities there that we, or maybe the Plasma dev team, haven't thought of.

More generally though, not nearly every visual design issue can or will be addressed in the first release Plasma Next. The commitment to visual design, like the commitment to the technical and functional aspects, is made over the course of several releases. Hopefully, things will improve over time.

alake wrote:... I don't personally anticipate that system tray icons will ever scale below 24x24 (or 22x22) but that's just my guess. ...

Hi Andrew,

Thanks for getting back to me!

Having messed about with designing System Tray svg icons in Inkscape I should know they are 22x22 pngs (or svgs)!! Whoops.
Ah well I can but ask about a change in size

I know the usual response, to this request, is that other (non-KDE) applications can set 22x22 png System Tray icons that won't scale (well) below this size. This can be seen if you create a blank panel, add a System Tray widget, then squash the height of the panel down below a width/height of 22 pixels. The png (3rd party System Tray) icons will not scale to this smaller size - but the KDE supplied svg icons will.

I am hoping there will be plans to at least allow Icon Tasks entries to have a horizontal rectangular shape (with a centred icon) - when a panel is vertical orientated? Having large square icons in Icon Tasks - as you can see in my screenshot - also chews up a large amount of vertical real estate on a low(ish) resolution screen...

Thanks
Robert

alake wrote:The vertical taskbar in Plasma Next will be themed for accounting for its orientation.

Thank you for your answer. I am glad to know that Plasma Next's theme will work well in vertical orientation.

alake wrote:The vertical taskbar in Plasma Next will be themed for accounting for its orientation.

Hi Andrew,

I installed KDE Plasma Next on Kubuntu 14.10 this morning to kick the tyres on it. I was largely very impressed with the general direction things are taking!
However the issue with vertical panel layouts is clearly going from bad to worse...



As you can see the System Tray icons look titanic'ly sized on a low DPI screen (1366x768). For reference the same laptop screen as my previous KDE 4.x screenshots came from.

Robert.

rwalker wrote:

alake wrote:The vertical taskbar in Plasma Next will be themed for accounting for its orientation.

Hi Andrew,

I installed KDE Plasma Next on Kubuntu 14.10 this morning to kick the tyres on it. I was largely very impressed with the general direction things are taking!
However the issue with vertical panel layouts is clearly going from bad to worse...

*shiny picture*

As you can see the System Tray icons look titanic'ly sized on a low DPI screen (1366x768). For reference the same laptop screen as my previous KDE 4.x screenshots came from.

Robert.

Hrmmm... I tend to have a bit of a pixel-level OCD issue which stems from how KDE sizes icons; I like my panels nice and thick, but I don't like super-huge icons, so on fresh installs I try to size panels to *just* the point before icons snap past 32 pixels tall.

And it's a tough problem, because 'technically' it's the best assumption: make the most of available space.

Perhaps having a "resize" option built into the panel for contianed widgets, where (when editing the panel) you could scale down the virtual fillable area perpendicular to the plasma panel; this would automatically force the contained widgets to also scale down in a reliable and consistent way. This is more complex than other solutions and would only be easily findable by obsessive tweakers - but no modification on the part of individual widgets would be necessary; it would be limited to the panel. It would also slake my own personal lust for pixel-perfect icons and phat panels.

Then there's always the classic "empty container widget" which could be given a padding setting. It's lazy and introduces more visual noise, though.

Lastly, the panel could just have a "panel settings" dialog where obsessive tweakers could modify the inner padding, force maximum icons sizes, and modify the font size individually from the standard panel settings. If we made some sort of popup for this, it could also include things like background opacity, and other things.

One thing I noticed way the problem with the digital clock when the panel is not wide enough:

This should clearly not happen, a better action should be taken when there it not enough horizontal space.

I couldn't agree more with this. So, for starters, we need to remedy the alignment problems and then rotate the rendering of 'taskitems.svg' 90 degrees clockwise:

Kver wrote:....
Lastly, the panel could just have a "panel settings" dialog where obsessive tweakers could modify the inner padding, force maximum icons sizes, and modify the font size individually from the standard panel settings. If we made some sort of popup for this, it could also include things like background opacity, and other things.

Ken,

I wouldn't expect any of that stuff to be exposed in the GUI layer (as with KDE 4.x) - it's time for the user to dig out Inkscape at that point . Adding extra options on options, like that, just makes the KDE code base exponentially more complex and the more code you write the more bugs you write/ plus RAM you hog! Then you get complaints about that from disgruntled users

I can't believe it wouldn't be an unrealistic goal for the KDE Desktop to allow specifying the number of rows of System Tray icons to allow - for reference Gtk docks (such as AWN/Avant Window Navigator) appear to have managed this years ago... If you Goggle for this complaint about KDE 4.x - it has come in forum threads over the years. I think it might have been a feature/option in KDE 3.x (...which I never had the pleasure of using TBH).

I might have a go at digging into the code for Frameworks 5 to find out where the System Tray drawing code is. Without knowing how KF5 works at present it's hard to know what is possible to implement reasonably easily.

Robert

rwalker wrote:I might have a go at digging into the code for Frameworks 5 to find out where the System Tray drawing code is. Without knowing how KF5 works at present it's hard to know what is possible to implement reasonably easily.

Please don't take it personally, but even though I've given up trying to police branding usage in the outside world, I try to keep it correct at least within the VDG:
KDE Frameworks 5 (or KF5) is the underlying framework, Plasma 5 (by KDE) is the workspace. There is no framework for draving system trays in KF5, it's in Plasma (to be precise, it's in the System Tray Plasmoid).

rwalker wrote:Ken,

I wouldn't expect any of that stuff to be exposed in the GUI layer (as with KDE 4.x) - it's time for the user to dig out Inkscape at that point . Adding extra options on options, like that, just makes the KDE code base exponentially more complex and the more code you write the more bugs you write/ plus RAM you hog! Then you get complaints about that from disgruntled users

I can't believe it wouldn't be an unrealistic goal for the KDE Desktop to allow specifying the number of rows of System Tray icons to allow - for reference Gtk docks (such as AWN/Avant Window Navigator) appear to have managed this years ago... If you Goggle for this complaint about KDE 4.x - it has come in forum threads over the years. I think it might have been a feature/option in KDE 3.x (...which I never had the pleasure of using TBH).

I might have a go at digging into the code for Frameworks 5 to find out where the System Tray drawing code is. Without knowing how KF5 works at present it's hard to know what is possible to implement reasonably easily.

Robert

I'm just throwing out potential options; whether they're good, bad, easy, difficult - any idea could potentiality open roads to more refined or elegant solutions. I do think there could/should be some way of resizing widgets in the panel to be smaller than their current "maximise space usage" approach, or at least offering some sort of general control for those times widgets make not-so-smart decisions or aren't optimised for all use-cases, and I think I might have a cleaner approach;

In the dialog for individual widgets, we replace the "keyboard shortcut" section with "General Settings"; Instead of being the lone bastion of the shortcut button, it would offer some additional options when the widget is in a panel, and later, it could be the place some unknown future features could be placed. For now, I'd propose a having two general settings added for widgets if they were placed in a panel;

First would be a "scale" slider. The scale would be between 50-100%, and users could use it to scale down a widget to half its normal size. On a technical level, it would operate on the height of the widget for horizontal panels, and the width of the widget for vertical panels. Widgets already handle the thickness of the panels fairly well, so this would incur minimal overhead, and would be done on a panel-level.

The second (which would solve the clock issue mentioned earlier) would be an option to rotate the widget by 90 degree increments. Fans of vertical panels, for example, could rotate the clock so the text flows along the length of the panel; or a task manager could be rotated to behave more like their horizontal counterparts. Again, this would incur minimal overhead as we already have code to rotate widgets - it's just adding the UI to control the QML-level attributes.

I think those two features together could solve 90% of problems vertical panel users face. It doesn't involve adding a whole new dialogue to the panel (which I do agree is madness), and recycles an existing and underutilised section of dialogue.

Kver wrote:...
First would be a "scale" slider. The scale would be between 50-100%, and users could use it to scale down a widget to half its normal size. On a technical level, it would operate on the height of the widget for horizontal panels, and the width of the widget for vertical panels. Widgets already handle the thickness of the panels fairly well, so this would incur minimal overhead, and would be done on a panel-level.

The second (which would solve the clock issue mentioned earlier) would be an option to rotate the widget by 90 degree increments. Fans of vertical panels, for example, could rotate the clock so the text flows along the length of the panel; or a task manager could be rotated to behave more like their horizontal counterparts. Again, this would incur minimal overhead as we already have code to rotate widgets - it's just adding the UI to control the QML-level attributes.

I think those two features together could solve 90% of problems vertical panel users face. It doesn't involve adding a whole new dialogue to the panel (which I do agree is madness), and recycles an existing and underutilised section of dialogue.

Ken,

I can see why I would a sliding scaling option would be nice ... But I feel for the System Tray it's probably easier to at least offer a "number of icon rows" option. See what happens when a Wine game dumps you to a 800x600 desktop for the damage this does to your KDE4 Layout At least the "number of icon rows" option would allow the System Tray to simply re-flow back to the old layout when you change back the resolution setting.

I like the idea of being able to rotate widgets! That solves some of the issues with the panel stuff Task Manager, Clock, etc. You just rotate it!

Robert