Created attachment 124669 [details] Paragraph style: Current layout Currently we have some dialogs which have multiple rows of tabs, for example the "paragraph style" dialog. I find it highly confusing to use this kind of tabs. As they are not in one row, it is hard to read all tabs to get a glance what tabs you have. Also when selecting a tab from the top, that row moves to the bottom, which is even more confusing, since the position of all tabs changes. I have two ideas how to improve the situation: 1. Leave the tabs as they are (multiline), but don't switch rows when selecting a tab from the top. 2. Stop using multiline tabs at all and use vertical tabs instead (have them on the left). Any thougts on this?
Created attachment 124670 [details] Mockup: Vertical tabs for paragraph style dialog
The proposal was to introduce icon views instead of tabs. Looks tidy and modern with icons and enough white space. But I remember harsh criticism saying we cannot change all dialogs. http://listarchives.libreoffice.org/global/design/msg07251.html https://wiki.documentfoundation.org/Design/PropertyDialog An alternative is to just disable multiline tabs. In that case, arrows allow to navigate to the undisplayed tabs.
(In reply to Heiko Tietze from comment #2) > The proposal was to introduce icon views instead of tabs. Looks tidy and > modern with icons and enough white space. But I remember harsh criticism > saying we cannot change all dialogs. In this case we have *17* tabs. That would mean a lot of scrolling with your mockup. I'm sure power users would complain very soon. If anything, I would keep the small tab size and add icons left to the text, like: [icon] label [icon] label ... > > http://listarchives.libreoffice.org/global/design/msg07251.html > https://wiki.documentfoundation.org/Design/PropertyDialog > > An alternative is to just disable multiline tabs. In that case, arrows allow > to navigate to the undisplayed tabs. This is ok as long as there is one or two tabs that cannot be shown by default, but I wouldn't do it if half of the tabs need scrolling, this would also seriously slow down power users.
(In reply to Samuel Mehrbrodt (CIB) from comment #3) > (In reply to Heiko Tietze from comment #2) > > The proposal was to introduce icon views instead of tabs. Looks tidy and > > modern with icons and enough white space. But I remember harsh criticism > > saying we cannot change all dialogs. > > In this case we have *17* tabs. That would mean a lot of scrolling with your > mockup. I'm sure power users would complain very soon. If anything, I would > keep the small tab size and add icons left to the text, like: > > [icon] label > [icon] label > ... Looks as a reasonable idea. Wrt power users: one might expect a decent key stroke to move to the next/previous page/tab. Maybe the same as currently. We must realize that also dialogs with as little as two tabs exist. Then the labels in a vertical row is a waste of space.. (In reply to Samuel Mehrbrodt (CIB) from comment #0) > I have two ideas how to improve the situation: > 1. Leave the tabs as they are (multiline), but don't switch rows when > selecting a tab from the top. I would love to see some experimenting with that.
(In reply to Cor Nouws from comment #4) > We must realize that also dialogs with as little as two tabs exist. Then the > labels in a vertical row is a waste of space.. Sure, I am talking about dialogs with more than one row of tabs, I wouldn't change the others. > I would love to see some experimenting with that. Maybe we can do this as a first step and then iterate? Or do we want to ban multiline tabs at all, then I won't waste time on this.
Stacking text/tabs to avoid whitespace and having different UI concepts that would be two epic design failures.
(In reply to Samuel Mehrbrodt (CIB) from comment #5) > Sure, I am talking about dialogs with more than one row of tabs, I wouldn't > change the others. Would look odd to me, to have two types.. > > I would love to see some experimenting with that. > > Maybe we can do this as a first step and then iterate? Or do we want to ban > multiline tabs at all, then I won't waste time on this. I would love to have a look with a not so much used dialogue maybe in a daily. Heiko, what do you think? Honestly I see no solution, bringing more improvements that drawbacks ;) , in the first option.
When there is a limited number of tabs and the dialog contains functionality that is seen by basic users (benjamin), the icon-based vertical tabs which is found in the hyperlink dialog is nice. We are hoping to implement this in a simplified options dialog (bug 90989). When there are many tabs and the dialog is primarily focused on more experienced users (eve), the non-icon vertical tabs found in the options dialog is nice. MS Office does a similar type of vertical tabs dialog with sufficient white spacing between each entry - https://support.content.office.net/en-us/media/5053c209-22b4-4336-a8ec-fd03d4547678.jpg
I find the current layout much more clear and faster readable than any vertical layout. Most people are used to read LTR or RTL, not top to bottom or reverse. Also there is much more horizontal than vertical space. Using a scrollbar would be a usability disaster. A vertical layout should only be an option for very few (~handful) points. Disabling multiline tabs and showing arrows to scroll reduces the usability too because you can't have all options at a look, what's important especially for Benjamin to find the right tab/option.
(In reply to Thomas Lendo from comment #9) > Most people are used to read LTR or RTL, not top to bottom or reverse. The contents of the tabs are ordered top to bottom in columns. > Also there is much more horizontal than vertical space. That all depends on how the controls are organized. Many tabs have extra wide controls for no reason (e.g. Character dialog's hyperlink and highlighting tabs, nearly every tabs in the Paragraph dialog) > Using a scrollbar would be a usability disaster. A vertical layout should only > be an option for very few (~handful) points. Cant say i agree with you, as when you have content that is larger than the available space, scrollbars are common and useful (e.g. browser, file manager). Alternatively you would have to have more vertical tabs, but you wouldnt be for scrolling within the vertical tabs.
Having no tabs at all, and have every area collapsing/expanding (like "Other options" section in Find & Replace dialog) would IMO be much better option. Such layouts are used e.g. in apps like 3ds max, AutoCAD (MS Office has a single non-collapsing long sheet, and that is much worse). Having a dialog with all such sections initially collapsed would create something like ToC right in the middle of the main dialog area; clicking the expand button would automatically bring the area to the center of the dialog; and the scrollbar would only be needed when several of the areas are expanded (and then it would be handy IMO, not a "usability disaster").
(In reply to Mike Kaganski from comment #11) > Having no tabs at all... The pattern is called accordion and would change the native integration (see also bug 120371 c15). Not an easy decision.
Samuel, with the latest changes by Caolan can we close this issue as solved/wfm? Since we aim to be as close to the system as possible, the alternative concepts with accordions or icon views are also a wontfix. In a nutshell, feel free to reopen.
(In reply to Heiko Tietze from comment #13) > Samuel, with the latest changes by Caolan can we close this issue as > solved/wfm? Since we aim to be as close to the system as possible, the > alternative concepts with accordions or icon views are also a wontfix. In a > nutshell, feel free to reopen. The issues I described in comment 0 are still there. I can't see how recent changes have improved anything there.
(In reply to Samuel Mehrbrodt (CIB) from comment #14) > I can't see how recent changes have improved anything there. gtk3 has no multiline tabs anymore, see also bug 121752.
gtk3 is not our only backend
And gtk3 also has multiline tabs in current master?!
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
*** Bug 113418 has been marked as a duplicate of this bug. ***
Vertical Gnome-like tabs were requested on bug 113418. (In reply to Heiko Tietze from bug 113418 comment #12) > We discussed this in the design meeting: > > + dialogs with vertical "tabs" wouldn't be according the OS/DE anymore > but make the application likely more appealing than (stacked) tabs > + sidebar with large image and text might be a good solution for option > dialogs but not in case of properties; good icons are very challenging > and doubt it's helpful (Sascha) > + would appreciate the sidebar with icon solution instead of tabs (Rizal) > + never liked the tabs, go with sidebar (John) > + ideally we have a solution that can be reverted if not accepted (Heiko)
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b64751ba28fd69fb2a93a21b10a92b68f4dd2097 tdf#99528 Properly layout vertical tabs without icons It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/62172db2d71fdc49a3ad9c177b8635353b90a7eb tdf#99528 Use vertical tabs in character style dialog It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 193947 [details] Character Style Quite ugly with kf6 without any margins, no icons, badly colored highlighting, zero spacing between frames, cut-off text... How does the patch work in your environment?
(In reply to Heiko Tietze from comment #23) > Created attachment 193947 [details] > Character Style > > Quite ugly with kf6 without any margins, no icons, badly colored > highlighting, zero spacing between frames, cut-off text... How does the > patch work in your environment? Icons can be added in Glade files, see hyperlink dialog for reference. I'll leave that to you or other ux people. For visual improvements please file a separate task with a graphic how it should look like. I checked Windows & gen plugin which looks ok. Gtk is fine since it supports vertical tabs natively.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d700acbcba68e8b56e22db53bfcdfeb4c5777b9c tdf#99528 Use vertical tabs in Frame dialog It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Can you make the vertical tabs optional? I expect some trouble and a lot users who want to stick with horizontal configuration.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/67dc0edb688d345607ae6afe3ad849f143804e28 tdf#99528 Use vertical tabs in 'Edit Style' dialog It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/971db10d73a0fe80cceca70d19edd02de30be414 tdf#99528 Use vertical tabs in Calc draw styles dialog It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d9bcf481b40d2a20169a98eb53caf7b19a03f3b8 tdf#99528 Use vertical tabs in list style dialog It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Heiko Tietze from comment #26) > Can you make the vertical tabs optional? I expect some trouble and a lot > users who want to stick with horizontal configuration. From what I read in comment 20 the vertical tabs idea was generally accepted and if it causes too much trouble it can be reverted. Don't see the need for having an option for this at the moment.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d71ea85d286a9a89e6cf784da90a820a09c0db2e tdf#99528 Use vertical tabs in Calc page styles dialog It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2199e603691a770ea6b67cbaba4ce1e0ce7b1919 tdf#99528 Use vertical tabs in 'Format cells' dialog It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2a41f854ceb2860239b1d7ec8fbc3d460c7499a1 tdf#99528 Use vertical tabs in Calc paragraph styles dialog It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e5e9ed7b87072c3c6366f50127cf2b9cf6bf4499 tdf#99528 Use vertical tabs in page dialog It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2f141c543494f44eab05db79533c60d342213901 tdf#99528 Use vertical tabs in frame style dialog It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Samuel Mehrbrodt (allotropia) from comment #30) > From what I read in comment 20 the vertical tabs idea was generally accepted > and if it causes too much trouble it can be reverted. I have only now heard about this initiative... I can't say I like vertical tabs all that much. And while I do agree that the horizontal tabs are not very convenient, they are a better established UI "idiom". I believe that well before this commit was made, we should have seen some kind of outreach: * Design meeting discussion (AFAICT that didn't occur) * Heads-up in the design Telegram/Matrix/IRC channel since this is a really big deal.
(In reply to Eyal Rozenberg from comment #36) Trying it out for the first time with a nightly. * The vertical "tabs" are not very tabby. More like a vertical nav-bar with a special kind of selection highlight. But this is ok for me, I think. At least with GTK3. * On second though, perhaps some kind of discoloration rectangle around the active tab would be nice, not just the blue bar. * I'm lacking space at the top of the tab. There's too little before the first group title (e.g. Paper Format, Area Transparency mode etc.) Also, now that all tabs are in sequence, their ORDER begins to matter: * Is their order purposeful? Why was this order chosen? * Shouldn't 'Page' by the first tab, at the top and selected by default? It has the most frequently-sought-after properties after all * Or maybe it should be 'organizer', which summarizes the style's features (and in the future, its delta from the parent style, see 41316), and has the style name? * Or perhaps the tabs should be sorted, so it would be easier to "guess" where on the list to find a tab whose name you have in your mind? * This draws attention to how Organizer is perhaps mis-named. It's more like the "General" or "Summary". Maybe I should open a bug about that. * Maybe "Organizer" should be separated from the rest, or otherwise distinguished visually, and then the Page tab can be first among the "non-Organizer tabs" if you will. Anyway, I'm weakly-in-favor of keeping the change.
(In reply to Samuel Mehrbrodt (allotropia) from comment #30) > (In reply to Heiko Tietze from comment #26) > > Can you make the vertical tabs optional? I expect some trouble and a lot > > users who want to stick with horizontal configuration. > > From what I read in comment 20 the vertical tabs idea was generally accepted > and if it causes too much trouble it can be reverted. > Don't see the need for having an option for this at the moment. Considering the impact it might have on end users and the trouble it might cause, I'm also in favour of making it optional for the time being.
Sorry, I had no time to comment before the design meeting but here are my thoughts. Since I swapped in my browser from top-of-the-window tabs to left-side-of-the window tabs, I love this layout a lot more. I needed a little time, maybe a day or so, to get familiar with it but it uses the screen space a lot more efficiently and I would hate now to switch back. I think the proposed new layout should be the default, with keeping the option for switching back to the "old" style for the users who don't like it.
(In reply to Xisco Faulí from comment #38) > Considering the impact it might have on end users and the trouble it might > cause, I'm also in favour of making it optional for the time being. I don't know about that. If you make it opt-in, then basically nobody will use it, and then you'll just have the same dilemma when you want to make it default; and if you make it opt-out, most of the "trouble" will happen anyway, since people who know how to fiddle with Tools > Options will be able to handle the tab layout change well enough. And - I don't think it would be a good idea to bring up a message box while people are watching the page properties dialog telling them "do you want to switch dialog layout?" ...
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/68260d7525aeaf38ac09ca9920fa1fa76dc8018a tdf#99528 Move through tabs with Ctrl-PageUp/Down keys It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/30380c2f9888685ddceaafc9fb3a637e7167a3ac tdf#99528 Use vertical tabs in para dialog It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/da21a102d072e73db8f7b8594903bf2780f6cdac tdf#99528: revert vertical tabs changes (24.8 only) It will be available in 24.8.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
with revert, have adjusted whiteboard and removed from the release notes Wiki
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/302a0de82e1227e0e99b11e0157d859bfa96ccd7 tdf#161351 Revert "tdf#99528 Use vertical tabs in list style dialog" It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #45) > Samuel Mehrbrodt committed a patch related to this issue. So, does this cover all dialogs with multiline tabs? All dialogs with tabs?
(In reply to Eyal Rozenberg from comment #46) > (In reply to Commit Notification from comment #45) > > Samuel Mehrbrodt committed a patch related to this issue. > > So, does this cover all dialogs with multiline tabs? All dialogs with tabs? Above commit only reverts the vertical tabs in one dialog where they caused problems (see bug 161351).
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/edb96ed2d9270b601d8f23c0978f6bca05747ff1 tdf#162552 Revert "tdf#99528 Use vertical tabs in 'Format cells' dialog" It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 165814 has been marked as a duplicate of this bug. ***
How about reopening this ticket, Samuel?
Hello, In previous comments, you suggested that the feature be optional to avoid upsetting users. As a user and user assistant, I believe it is essential that the implementation of this feature be more structured and gradual for the end user. Beyond making it optional, which could be the ultimate goal, I believe this major interface change should be treated as an experimental feature. The way the meta bar (and gradually the different types of user interfaces) was implemented seems to me to be appropriate for this change. Although I have read all the comments on this bug, I do not see any decision-making or consultation process for this change, which is, once again, a major one. I discovered it for myself in version 25.2 and find it particularly disruptive, especially because this change is being implemented dialog box by dialog box. This is not an invisible change that only affects users who have a particular use case. However, this change was not documented in the Release Notes before it was first rolled out to all users. This amounts to offering an interface with various functions, without the user being able to identify what justifies it. Fundamentally, I disagree with Samuel; I do not think this change is necessary, as I already mentioned in bug 165474, comment#8. Above all, I am convinced that we are in an area where preferences will depend on the needs and way of thinking and designing of each individual. The richness of LibreOffice lies in allowing users to choose what is best for them. We must strive to maintain this approach. Otherwise, it is no longer LibreOffice, and we lose our freedom. In summary -I do not think this bug should be considered resolved. -I would like these changes to be experimental at first, and then once they are mature (which is not the case today, see bug 165474), I would like the feature to remain optional. -I would like to see a real discussion on the relevance of this structural change. This discussion should go beyond just the dev and UX teams. It should consult end users. Thank you on behalf of the users! ************** Original French version ************** Bonjour dans des commentaires précédents, vous proposiez que la fonction soit optionnelle pour éviter de brusquer les utilisateurs. Comme utilisatrice et assistant utilisateurs, il me parait indispensable que la mise en place de cette fonction soit plus encadrée et plus progressive pour l'utilisateur final. Au delà d'un fonctionnement optionnel, qui pourrait être l'objectif final, il me parait nécessaire que cette évolution majeure de l'interface soit traitée comme une fonction expérimentale. La façon dont la métabarre (et progressivement les différents types d'interfaces utilisateurs) ont été mis en place me parait être adaptée à ce changement. Bien qu'ayant lu l'ensemble des commentaires de ce bug, je n'identifie pas de processus de décision et de concertation sur ce changement, encore une fois, majeur. Je l'ai pour ma part découvert dans la version 25.2 et il me parait particulièrement perturbant, plus encore parce que cette évolution se fait boite de dialogue par boite de dialogue. Il ne s'agît pas d'une évolution invisible qui ne concernerait que les utilisateurs qui ont tel ou tel usage. Pourtant, ce changement n'a pas été documenté dans les Release Notes avant sa première mise en production pour tous les utilisateurs. Cela revient à proposer une interface avec des fonctionnements variés, sans que l'utilisateur puisse identifie ce qui le justifie. Sur le fond, je ne suis pas de l'avis de Samuel, ce changement ne me parait pas nécessaire, comme je l'ai déjà évoqué dans le bug 165474, comment#8. Surtout, je suis convaincue que nous sommes sur un domaine pour lequel les préférences dépendront, des besoins et de la façon de penser, de concevoir de chacun. C'est la richesse de LibreOffice que de laisser à l'utilisateur le choix de ce qui est le mieux pour lui. Nous devons nous efforcer de garder cette ligne de conduite. Sinon, ce n'est plus LibreOffice, et nous perdons de notre liberté. En résumé -je ne pense pas que ce bug doive être considéré résolu -je souhaite que ces modifications soient en mode expérimental pour commencer, et ensuite une fois mature, (ce n'est pas le cas aujourd'hui, voir bug 165474) que la fonction reste optionnelle. -je souhaite qu'une réelle réflexion soit menée sur la pertinence de ce changement structurant. Cette réflexion devrait aller au delà des seuls équipes de dev et UX. Elle devrait consulter les utilisateurs finaux Merci pour les utilisateurs !
(In reply to ocleyr2lalune from comment #51) > Above all, I am convinced that we are in an area where preferences will > depend on the needs and way of thinking and designing of each individual. > The richness of LibreOffice lies in allowing users to choose what is best > for them. We must strive to maintain this approach. Otherwise, it is no > longer LibreOffice, and we lose our freedom. > And please note that based on UX feedback, wef. 26.2 users may now choose either the Vertical tab bar VT representation or the legacy Horizontal tab multirow. Tools -> Options -> Appearance. Meanwhile there is nothing incorrect or misimplemented with the VT, though ability to resize any VT instance to fully expose its listing is likely needed for consistency.
(In reply to V Stuart Foote from comment #52) > Meanwhile there is nothing incorrect or misimplemented with the VT, though > ability to resize any VT instance to fully expose its listing is likely > needed for consistency. Stuart, you are intentionally misinforming people with that claim. There is a very serious problem with VT, which is that they exceed the vertical boundaries of the dialog, and when that happens - they are absolutely horrible UI, with worse problems than the horizontal tabs, which started this whole journey. This is bug 165989, which you are intentionally neglecting to mention. Even if you personally believe it is not much on an issue, you would have at least said that there is a dispute about this point. Samuel wrote in comment 0, about the problems with horizontal tabs: > they are not in one [row], it is hard to read all tabs to get a glance what tabs you have. Replace "row" with "column" and we have the same situation with vertical tabs. > when selecting a tab from the top, [that row moves to the bottom], which is even more confusing, since the position of all tabs changes. Replace "row moves to bottom" with "you need to move all tabs away from where they were placed before, and drive some of them off of the dialog" - which is even worse. In fact, you have to apply mutliple mouse-strokes to even get to the tab you want to select; and you have to remember by heart that it even exists. This currently happens - in released versions no less with GTK3. But - there is nothing guaranteeing it doesn't happen with other VCLs, if somehow you were to use some UI theme which increases vertical space between tab headers. It should also be clearly restated that dialog resizing is irrelevant for dealing with these situations. If that were the case - one could just resize the horizontal-tab dialogs to always have one line of tabs, easy peasy, right? Of course not, many dialogs are already very large, and there is simply no screen real-estate to resize them.