jstaniek wrote:Also, how to refer to atomic recommendations is still a question for me, maybe number them like HIGTABS-1, HIGTABS-2 ... ?

Absolutely, we need such references. But the only way I found is to add <div id="Tab1"></div> tags. Annoying for the editor and hard to find for the person who actually want to reference. Any ideas?

(I added the sections #Tab1... #Tab5 as an example. https://techbase.kde.org/Projects/Usabi ... trol#Tabs4)

Heiko Tietze wrote:In general I would suggest to keep guidelines simple. Therefore I would not recommend to use icon only or vertical tabs being aware that Kate and KDeveloper violate the HIG. But any new application should not need to read all the if-thens.

I agree. Plus, Okular shows well that the same thing (switching between different content types for a sidebar as well as expanding/collapsing it) can be done just fine with the list view with icons, so I don't see a reason for introducing a third way of "tabbing".

Open questions are functions with tabs (where to place and when to show). An option is to not show the close button at all relaying completely on short-cut and context menu. If we go with simple/powerful we should have an overall setting for it.

Erm, we're talking about document tabs (like in browsers) here, where opening and closing tabs is a very common task which should definitely be accessible directly from the UI, not hidden away. So I am strongly against that suggestion.

About the "close button on every tab vs. one in on the side" debate: Having the close button right on the tab (when the tabs are wide enough) and the "new tab" button next to the rightmost one has proven to be successful across browsers, so why should we deviate from the de facto standard?
Browsers and tabs on them are something that pretty much every users uses all the time, so people know that interaction by heard. Therefore we should stick with how they do it for the sake of consistency with expectation unless we have an immensely good reason not to.

For static tabs there simply should be no way to add or remove them, like the HIG already suggests.

Heiko Tietze wrote:

jstaniek wrote:Also, how to refer to atomic recommendations is still a question for me, maybe number them like HIGTABS-1, HIGTABS-2 ... ?

Absolutely, we need such references. But the only way I found is to add <div id="Tab1"></div> tags. Annoying for the editor and hard to find for the person who actually want to reference. Any ideas?

(I added the sections #Tab1... #Tab5 as an example. https://techbase.kde.org/Projects/Usabi ... trol#Tabs4)

Cool, how about templates? See https://techbase.kde.org/Projects/Usabi ... rol#TABS-1

jstaniek wrote:Cool, how about templates? See https://techbase.kde.org/Projects/Usabi ... rol#TABS-1

This would be the good solution, if we add some kind of a switch to show/hide all tags. Or if we replace the bullets using a template that shows the reference in a tooltip.

Heiko Tietze wrote:

jstaniek wrote:Cool, how about templates? See https://techbase.kde.org/Projects/Usabi ... rol#TABS-1

This would be the good solution, if we add some kind of a switch to show/hide all tags. Or if we replace the bullets using a template that shows the reference in a tooltip.

It's Mediawiki, everything is possible but I wouldn't want to bother the administrators so they install extension just for our small needs. They have enough work with patching anyway.

Without patching, the bullets cannot be magically modified. How about making the visible text smaller, such as just the number? http://wstaw.org/m/2014/10/23/plasma-desktopQv1772.png

Please try: https://techbase.kde.org/Projects/Usabi ... rol#TABS-1

Heiko Tietze wrote:About the "close button on every tab vs. one in on the side" debate: Having the close button right on the tab (when the tabs are wide enough) and the "new tab" button next to the rightmost one has proven to be successful across browsers, so why should we deviate from the de facto standard?
Browsers and tabs on them are something that pretty much every users uses all the time, so people know that interaction by heard. Therefore we should stick with how they do it for the sake of consistency with expectation unless we have an immensely good reason not to.

I second this. Konsole's current open/close tab button functionality is my #1 least favorite thing about it, especially considering how standardized tab interaction has become across so many different programs and operating systems. Adding this feature to Konsole would make me very happy.

Any news about this? Just came back to KDE after a long hiatus and am generally pleased with its development, looking forward to continuing improvements and would be happy to contribute if it would help.