Version: (using KDE 4.2.0) OS: Linux Installed from: I Don't Know The current tab bar extension in Kate (KDE 4.2.0) is nothing like the default/standard tab bar found in other KDE applications, such as Dolphin. This IMO breaks the user experiance by having different tab behaviour and style for Kate. I'd like to propose the use of the standard/default tabs to be used, to make things more consitant and useful.
I might be wrong, but I think the reason that kate uses buttons is that the standard tabbar is completely useless with more than a handful of files. It simply doesn't scale, while the current tab-extension allows to wrap-around the list of buttons.
Scale as in performance wise, or visually?
visually, because a standard tabbar gets those small, hard-to-hit buttons for "paging" through the list of tabs when there's more tabs than fit on the screen. And multi-row-tabs are considered bad usability (AFAIK), apart from being technically rather complex with Qt's QTabBar.
Andreas is right, that's why Kate by default has the "Documents" sidebar and not a tabbar. The extension indeed trys to still present you with as much document tabs as possible (configurable). I don't have any plans to change this (as it means removing this extension and writing a new totally unrelated one), so we either close this as WONTFIX or this is a new wish for another tabbar.
well, if the default/standard tabbar doesn't fit the job - then maybe this needs to be taken to QT and get them to improve how it handles? GTK handles this fine, maybe they can take some ideas from that. Either way, the current tabbar is quite an eye sore and doesn't have the features of the standard tabbar. Things I am most concered about: * Scrolling through tabs via mouse wheel * Close button on each tab (such a pain having to right-click). Or simply a button far right to close current tab * Graphical issues with long filenames, it just cuts off the name instead of maybe making 'Foobarcarzomgwtfbbq' into 'Foobarcar...' for example. * Visually, they are not attached to the editor part - which doesn't really mean they are associated with anything (although I know what they are for).
*** Bug 185301 has been marked as a duplicate of this bug. ***
*** Bug 188379 has been marked as a duplicate of this bug. ***
So, are there still any problems with doing this? I don't really see any other applications having issues with Qt's tab bar... Think of konqueror, and kdevelop4... It works fine..... Would it be OK to just make this an option, if we had to, then still leave the plugin in case some crazy person wants it ;) . I fully agree with Alex, and feel his exact reasons for wanting the standard (normal) tab bar. My way of seeing it, is if every application began making their own, we would have 10 differently-looking tab bars, which is exactly what we do not need any more of in KDE, un-standardized ways of doing things. This is my outlook on it.
(In reply to comment #8) > So, are there still any problems with doing this? I guess only one: Somebody who wants it needs to write the code. > I don't really see any other applications having issues with Qt's tab bar... > Think of konqueror, and kdevelop4... Both konqueror and kdev4 are horrible with more than a handful of tabs. The tabs are simply useless - at least to me. Thats why I have more than one konqueror window open at the same time and why I don't use the tabs in kdev4 (or kdev3 for that matter) at all. > It works fine..... Would it be OK to just > make this an option, if we had to, then still leave the plugin in case some > crazy person wants it ;) . It should be a plugin, then any use can choose which tabbar he wants, thats how the current one is implemented. > My way of seeing it, is if every application began making their own, we would > have 10 differently-looking tab bars, which is exactly what we do not need any > more of in KDE, un-standardized ways of doing things. Sure that would be bad, but as was explained by me and Dominik, the current tab extension is a tradeoff between normal tabs and something thats actually useful for more than 5 open files. I do agree that it might have bugs (cutting of filenames instead of eliding) or missing features (close-button per tab). Anyway, as I said someone needs to actually write the plugin, else you'll never get one and apparently kate devs are not overly interested to do that ;) PS: Changing to NEW as this is a valid wish.
Okay, adding this to my TODO-list :P
Good to see there is hope of having an additional plugin made, though one thing that I keep thinking - is it worth forwarding such request upstream to QT, to make tabs more workable when there are many? I find it quite strange that a project would work around a flaw/issue, instead of sending it upstream to fix.
(In reply to comment #11) > Good to see there is hope of having an additional plugin made, though one thing > that I keep thinking - is it worth forwarding such request upstream to QT, to > make tabs more workable when there are many? I find it quite strange that a > project would work around a flaw/issue, instead of sending it upstream to fix. There's no flaw in Qt's implementation of tabs (at least not regarding the use-case I presented), the point is that tabs themselves are problematic for some use-cases. There's no way to use tabs when you have 50 files open, you simply need a list for that. Multi-Row tabs are even worse than normal tabs, they totally confuse users and make it harder to hit the right one.
Ahh so you mean the concept of tabs, and not their implementation, simply don't work (in your opinion) for many documents in Kate specifically? True, multi row tabs would be a user interface nightmare!
Right, the concept of a "tabwidget" only works for a limited number of tabs, usually less than ten. If there are two many two problems arise: a) the text on the tabs is shortened so much that one cannot distinguish similar looking titles b) if the tabs don't get smaller, then you usually get two small arrows, which make jumping to a tab on the last page really slow Anyway, this is getting ot for this wishlist report.
*** Bug 219968 has been marked as a duplicate of this bug. ***
Ok, we could change the implementation to use a real tabbar. Is that the general consensus here? I'm almost 100% sure that then we will get but reports that want the other tabbar back. And shipping two options doesn't sound right either. So how to go on?
I think this should be an option. There are missing features on the current tab bar plug-in, so it could be improved (i don't think it's a good idea) or replaced by a standard tab bar. My suggestion is to let the user choose between the current Document List and a standard tab bar (being native). The current tab bar plug-in can be kept, for those who like it.
(In reply to comment #16) > Ok, we could change the implementation to use a real tabbar. Is that the > general consensus here? I'm almost 100% sure that then we will get but reports > that want the other tabbar back. And shipping two options doesn't sound right > either. So how to go on? I think the current tab bar is too non-standard and doesn't have a lot of advantages going for it. Most if not all KDE applications use standard tab-bars, so I think kate would gain a lot to move to a standard tab bar. Besides, it would be easy to get two tab-bar plugins working side by side if needed (but only one of them should be included in the standard install).
There is a standard tabbar, called Tabify right now. So the wish here itself is implemented. If there are other issues, please open a new report, since this one is already getting pretty long and, thus, hard to quickly grasp all the content.