We have been going a transition from vertical to horizontal tabs in some dialogs. I am ok with the transition in itself, but - in some cases, this results in what I consider to be a completely unacceptable situation: Tabs which get left out of the dialog, and can only be accessed by scrolling... which moves other tabs out of view, and places all tabs in a different vertical position. This means: * Another area of the dialog whose content is not fixed, forcing you to keep track of it. * You cannot develop "muscle memory" of how to get anywhere in the dialog - since that always depends on the tabs scroll position. * To decide where to look for something in the dialog, you can't just evaluate all of the possible tabs - you have to make a mental list of them, and fill it while scrolling, then remember it when you've scrolled all the way. * ... in both directions if you started in the middle. This is absolutely terrible. Horrid. I claim we must not allow this to continue. We need to take a decision that this never happen. That any of the alternatives is always superior to being in this situation. Those could be: * Less height for each tab header (i.e. tabs closer together). * Using a list-ish control rather than tabs. * Unifying related tabs. * Two columns of of tab headers. * Switching back to vertical tabs. Yes, I know some of these are kind of cringy. But none of them are as bad as having to scroll to releval tabs. If nothing else - the last option, of simply reverting to the old layout, is very easy to implement, and its shortcomings are far outweighed by the current situation. --- I've filed this as an LO-general bug, although for now the most prominent example is the Paragraph Style editing dialog in Writer.
Not perceiving an issue! The Style dialogs (launched from Sidebar F11 deck) come up in Vertical tabs rather than legacy horizontal. And for now you can still see some like Paragraph style in Horizontal mode (if launched from context menu). However, the vertical tab list is easily navigated. It rolls up or down with mouse scroll wheel or with cursor up/down. Wheel scroll does not open the panels so not distracting at all, while cursor up or down, or mouse click, exposes the panel. I find the Vertical tabs no more unwieldy than the Horizontal tab layout for dialog where the entire layout (upper and lower row) shifts position depending on the tab selected. -1
(In reply to V Stuart Foote from comment #1) > Not perceiving an issue! > > The Style dialogs (launched from Sidebar F11 deck) come up in Vertical tabs > rather than legacy horizontal. And for now you can still see some like > Paragraph style in Horizontal mode (if launched from context menu). > > However, the vertical tab list is easily navigated. It rolls up or down with > mouse scroll wheel or with cursor up/down. Wheel scroll does not open the > panels so not distracting at all, while cursor up or down, or mouse click, > exposes the panel. > > I find the Vertical tabs no more unwieldy than the Horizontal tab layout for > dialog where the entire layout (upper and lower row) shifts position > depending on the tab selected. > > -1 Would say though that the dialog should probably be resizable, rather than fixed as implemented. Users with issues of a cluttered UI could drag it taller to expose all the tabs.
(In reply to V Stuart Foote from comment #1) > Not perceiving an issue! > > The Style dialogs (launched from Sidebar F11 deck) come up in Vertical tabs > rather than legacy horizontal. And for now you can still see some like > Paragraph style in Horizontal mode (if launched from context menu). I think we may be using the terms vertical/horizontal in opposite ways. > However, the vertical tab list is easily navigated. The problem is the _need_ to navigate it. I described why this is a huge degradation of the UI. > I find the Vertical tabs no more unwieldy than the Horizontal tab layout for > dialog where the entire layout (upper and lower row) shifts position > depending on the tab selected. Actually, shifting is also rather bad; but at least there are only two possible states, and the distance between the positions of the tabs is relatively small. > Would say though that the dialog should probably be resizable, rather than > fixed as implemented. Even if it were resizable - no scrolling should be guaranteed, IMNSHO, with the default dialog size.
The new layout is Vertical tabs--stacked into a tab bar. Implemented as for bug 99528 The old layout was Horizontal tabs--wrapped when width didn't hold all the tab (usually two rows) so appeared as a multi-line horizontal tab bar. There definitely are some consistency issues with the new Vertical tab layouts. In Writer, all the dialogs open with fixed heights. But in Draw/Impress those that I checked all could be resized taller as needed. Also, some of the controls still open to the Horizontal tab bar, noticed mostly for those launched from the context menus. So resizable (with a default height to hold all of tab bars up to max of 800px), and made consistent across the modules--that alone should be sufficient.
VT style is supposed to have icons (similar to the hyperlink dialog), tracked in bug 163008. Plus, all dialogs needs a review for the new layout. I don't see need for another ticket => INV
(In reply to Heiko Tietze from comment #5) If: > VT style is supposed to have icons (similar to the hyperlink dialog), > tracked in bug 163008. Doesn't that just mean that a resolution of 163008 would resolve this bug? > Plus, all dialogs needs a review for the new layout. > I don't see need for another ticket => INV but this has already been released with 25.02. If we're talking about an after-the-fact review - this is one such "review": The new vertically-layed-out tabs introduce an unacceptable aspect to the UI.
(In reply to Eyal Rozenberg from comment #6) > but this has already been released with 25.02. We decided to keep VT on a few dialogs to keep some urgency for the topic. It would be a nice design variation if we had VT with fancy icons - people often complain about LibreOffice old-school look and feel. But at this point it is more likely that we revert the changes than fixing all issues (see also bug 165487).
Hello, I recently discovered this change, and I disapprove of it. In particular, I disapprove of: - the way the interface change was carried out; -the meager comments in the original bug (99528) to justify the implementation (I prefer it, I find it...). - While the original ticket had been open since 2016, and the importance of this change was noted, the fixes were proposed all at once, without (sufficiently) questioning the relevance of this change for all users. - I regret that at the very least this change was not treated as an experimental function, as was done when the metabar was implemented. - I regret even more that no information was given on this change, in the release notes (yet the change is not minor). - I'm even more disappointed that no indication is given of how to get back to the previous way of working, even though this is mentioned in the ticket. Finally, I totally disagree with an evolutionary strategy that would aim to copy what's being done next door, because "since that's how it's done at Microsoft, users will accept it more easily if we do the same": no. LibreOffice has nothing to be ashamed of in terms of how it works, or its interface (which is in no way "old-fashioned"). LibreOffice should be proud of what it offers, of its respect for the user and the possibilities for customization and preference it gives him. And that's exactly what's wrong with this evolution: the user is subjected to a few people who have decided in a uniform way for him, instead of offering a modification as an option. What's more, this change of display is not applied to all dialog boxes, so it's unfinished and incomprehensible to an "end" user who doesn't know how a feature matures. Having clarified these points, I'd like to shed some light on the root of the problem. Each user operates in his own way, according to his needs, his habits, his tools and his screens. For some users, the in-line tabs are unsatisfactory (perhaps things could be reworked, without "throwing away" these in-line tabs), for others the display of a vertical menu is destabilizing. And if one of us finds that we get used to it in 2-3 days, that's a hazardous generalization. Any UX/UI subject should at least take into account the cognitive functions of each individual. To sum up: just because it's good for me, I'm used to it, doesn't mean it's the same for my neighbor. It seems to me that a minimum of inclusion isn't orthogonal with LibreOffice's values. There are other programs (I'm thinking of VLC, for example) that have evolved the way they present their settings. The difference is that VLC doesn't have such a wide variety of functions and dialog boxes. And when this change was made (a long time ago now), there was only a checkbox to return to the old display. The fact that this change of display is not uniform for all dialog boxes doesn't help matters, and shows that the answer would have deserved a little more work, without a backtrack, a switch to experimental function for example. In any case, with this vertical display, I agree with the subject of this ticket: the scroll bar is not sufficiently visible, nor are the "chevrons" (top and bottom). I think a clearer separation of menu items would be useful, but for all the reasons given above, not everyone agrees. I understand that this is an issue that the UX team needs to think about before improving the strategy (whatever the final decision may be). The urgent thing is to provide the user with information in the release notes, and, if possible (I haven't found it) to specify how to restore the display of inline tabs in the dialog boxes concerned. I usually devote more time to helping French-speaking users on the dedicated list than to participating in bug reports, but the method displeases me too much for me not to "do my bit". ==================================== original French version ==================================== Bonjour j'ai découvert il y a peu ce changement, et je le désapprouve. Particulièrement je désapprouve : - la façon dont le changement d'interface a été réalisée - les maigres commentaires dans le bug d'origine pour justifier de la mise en place (moi je préfère, moi je trouve...). Alors que le ticket d'origine était ouvert depuis 2016, que l'importance de ce changement était noté, les fix ont été proposés d'un coup, sans s'interroger (suffisament) sur la pertinence de ce changement pour tous les utilisateurs - Je regrette qu'à minima ce changement n'ait pas été traité comme une fonction expérimentale, comme cela a été fait lors de la mise en place de la metabarre. - Je regrette encore plus qu'aucune information ne soit donnée sur ce changement, dans les notes de version (pourtant le changement n'est pas mineur). - Je regrette encore plus qu'aucune indication ne soit donnée pour retrouver le fonctionnement précédent alors que cela est évoqué dans le ticket. Enfin, je suis en total désaccord avec une stratégie d'évolution qui viserait à copier ce qui se fait chez le voisin, parce que "comme ça se passe comme ça chez Microsoft, les utilisateurs accepteront plus facilement si l'on fait pareil" : non. LibreOffice n'a pas à rougir de son fonctionnement, de son interface (qui n'est en rien "vieillotte"). LibreOffice doit être fier de ce qu'il propose, de son respect de l'utilisateur et des possibilités de personnalisations et de préférence qu'il lui donne. Et c'est bien ce qui ne va pas avec cette évolution : l'utilisateur est soumis à quelques personnes qui ont décidé de façon uniforme pour lui au lieu de proposer une modification en option. Par ailleurs ce changement d'affichage n'est pas appliqué à toutes les boites de dialogue, c'est donc inabouti et incompréhensible pour un utilisateur "final" qui ne connait pas le processus de maturation d'une fonctionalité. Ces points précisés, je souhaite apporter mon éclairage sur le fond du problème. Chaque utilisateur fonctionne a sa façon selon ses besoins, ses habitudes, ses outils, ses écrans. Pour certains utilisateurs, les onglets en lignes sont insatisfaisants (peut être que des choses pouvaient être retravaillées, sans "jeter" ces onglets en ligne), pour d'autres l'affichage d'un menu vertical est déstabilisant. Et si l'un de nous trouve que l'on s'y fait en 2-3 jours, c'est une généralisation hasardeuse. Tout sujet UX/UI devrait intégrer un minimum les fonctionnements cognitifs des uns et des autres. Pour certains l'adaptation sera rapide, pour d'autres l'adaptation forcée constituera une panique réelle. Pour résumer : ce n'est pas parce que pour moi c'est bien, je m'y fait, que c'est la même chose pour mon voisin. Il me semble qu'un minimum d'inclusion ce n'est pas orthogonal avec les valeurs de LibreOffice. Il y a d'autres logiciels (j'ai pensé à VLC par exemple) qui ont fait évoluer la présentation de leur paramétrage. La différence c'est que VLC n'a pas une telle variété de fonctionnalités et de boites de dialogues. Et que, quand ce changement est intervenu (il y a lo ngtemps maintenant), il n'y avait qu'une case à cocher pour retrouver l'ancien affichage. Le fait que ce changement d'affichage ne soit pas uniforme pour toutes les boites de dialogue n'arrange rien, et montre bien que la réponse aurait mérité un peu plus de travail, sans un retour arrière, un passage en fonction expérimentale par exemple. Vraiment, ce qui a été fait lors de la mise en place des interfaces utilisateurs multiples (dont meta-barres) me semble un bon compromis. Dans tous les cas, avec cet affichage vertical, je rejoins le sujet de ce ticket la barre de défilement n'est pas suffisament visible, les "chevrons" (haut et bas) non plus. Une séparation plus évidente des éléments du menu m'apparait utile, mais pour toutes les raisons évoquées précédemment, cela n'est pas forcément l'avis de tous. Je comprends que le sujet mérite réflexion de l'équipe UX notamment avant d'améliorer la stratégie (quelle qu'en soit la décision finale). L'urgence est d'apporter à l'utilisateur dans les notes de versions, et, si cela est possible (je n'ai pas trouvé) de préciser comment retrouver l'affichage des onglets en ligne dans les boites de dialogue concernées. habituellement je consacre plus de temps à aider les utilisateurs francophones sur la liste dédiée qu'à participer aux déclarations de bugs, mais la méthode me déplait trop pour que je n'apporte pas "ma pierre"
(In reply to ocleyr2lalune from comment #8) Thanks for your supportive comment (I mean, supportive of my perspective...) - but I think I need to point out that this bug is about a specific aspect of the change - some of the tabs being out-of-view. Perhaps you should post the comment on the meta-bug for "vertical" tabs, or on the bug where the patches were posted etc.
Yes, I fully agree with V Stuart Foote's comments in Comment 1, Comment 2, and Comment 4: - Need more Vertical Tabs!!! - Allow Scrolling = Good! - Allow Resizing = Good! - Oddly, only these Writer menu's sizes seem to be hardcoded, like Comment 4 noted. - Helpful for menus that aren't quite-yet-completed in design too. - See Bug #161492. - A few labels accidentally have a few letters "going off the screen" now, like: - Right-Click > Edit Style - "Text Flow" tab -> "Split Options". I think the list potentially "being too tall" is a non-problem, especially if it gets scrolling enhancement #165989. Bug #165989 also allows us to split out even MORE tabs in the future, like pulling "Hyphenation" out of "Text Flow". - - - Instead of stuff being cut off vertically... What I currently see as a serious issue is: - "Tabs" with text cut off *horizontally*. - The tab column's width is non-stretchy. This especially becomes a problem on computers set with HUGE TEXT SIZE. STEPS-TO-REPRODUCE 1. In Windows OS: - Open Start Menu. - Search "Text Size" setting. - Set "Text Size" -> 200%. 2. Open LibreOffice Writer. 3. Go to any dialog with Vertical Tabs. BUG: See only a few letters of the "tab name" appears before chopping off and turning into an ellipsis. Expected these to appear fully: - Indents & Spacing - Alignment Actual: - Indents ... - Alignm... with the rest of the tab names "cut off". I assume this is even worse in some localizations over others. (I first noticed this issue while working on an 80-year-old grandma's laptop. It was a very old laptop: low resolution plus ENORMOUS FONT SIZES set by the OS. But this issue happens on a huge 4K monitor too.) Note: Old horizontal tabs, the labels correctly grew ENORMOUS along with all the other text. - - - I agree with ocleyr2lalune's input: > this change of display is not applied to all dialog boxes, so it's unfinished and incomprehensible to an "end" user who doesn't know how a feature matures. Yes, it did currently feel it was rushed and a little half-baked. I was very excited Vertical Tabs finally made it, but could've used a bit more refinement before mass public release. Now that they're here though, let's try to incrementally (and quickly) move them in the right direction. Once we get passed this huge speed bump, refining a few of these initial menus, I think it'll be a lot smoother sailing after that. Note: I wrote a tiny bit about that in this comment on the LO subreddit: - "Plans for a total UI/UX redesign?" - https://old.reddit.com/r/libreoffice/comments/1k2h0lr/plans_for_a_total_uiux_redesign/mo14ts6/
(In reply to Tex2002ans from comment #10) > I think the list potentially "being too tall" is a non-problem, especially > if it gets scrolling enhancement #165989. It is a seriously usability problem. So serious, that if it is decided not to fix it - we should revert the entire change from "horizontal" to "vertical" tabs. Dialogs where one has to scroll to get to parts of the dialog are annoying and broken.
(In reply to Eyal Rozenberg from comment #11) > (In reply to Tex2002ans from comment #10) > > I think the list potentially "being too tall" is a non-problem, especially > > if it gets scrolling enhancement #165989. > > It is a seriously usability problem. So serious, that if it is decided not > to fix it - we should revert the entire change from "horizontal" to > "vertical" tabs. Dialogs where one has to scroll to get to parts of the > dialog are annoying and broken. Have to disagree there, its a configuration screen. Swipe scroll is pretty standard UI and offers reasonable UX. Present LO implementation can be improved, and consistency cross platforms needs to be there for documentation. UX is no worse than legacy horizontal tab bar with wrapping into multiple rows.
(In reply to V Stuart Foote from comment #12) > Have to disagree there, its a configuration screen. It is not. > Swipe scroll is pretty standard UI Not in a properties dialog that is used frequently and repeatedly. > and offers reasonable UX. Imagine if the menus were only 10 item long and you had to scroll down to get the the rest of the menu items. It's that kind of reasonable. > UX is no worse than legacy horizontal tab bar with wrapping into multiple > rows. It is worse, because there, nothing was off-screen and left to memory and imagination. > Present LO implementation can be improved, Let's do that then, and I see that Heiko has taken charge of this bug. I trust he'll work out something nice :-)
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cd4f6d6f284c27cf783ba413fdb3650808552640 Related tdf#165474 - Size vertical tabs according the content It will be available in 26.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 Eyal Rozenberg from comment #0) > Tabs which get left out of the dialog, and can only be accessed by scrolling... > which moves other tabs out of view, and places all tabs in a different > vertical position. (In reply to Eyal Rozenberg from comment #3) > I think we may be using the terms vertical/horizontal in opposite ways. Missing some details here. To my knowledge you run gtk3 which draws VT natively. Kf6 works well now too, the latest patch expands the VT parent window to the largest text. The remaining issue I see is with gen that spaces out the tabs and hides some vertically in case of Styles > Edit Style... but only after adding icons ending up in a tad larger tab height. And only for gen. And only if CTL/CJK are enabled. Of course it depends on many other factors such as resolution, scaling, and system font. While it might be possible to solve the gen issue we cannot deal with every configuration. So my take: if this is the problem we just show the scrollbar. And aim for less than 12 tabs.
Created attachment 201212 [details] Paragraph style dialog box - LO 25.8 nightly, GTK3, 1920x1080 monitor Screenshot of what I see even with a very favorable case.
(In reply to Heiko Tietze from comment #15) > (In reply to Eyal Rozenberg from comment #3) > > I think we may be using the terms vertical/horizontal in opposite ways. > > Missing some details here. So, first, about the vertical/horizontal: In the first comment of this bug I referred to the old style as vertical tabs and the new style as horizontal, while the common terminology is the opposite. So, I switched. > To my knowledge you run gtk3 which draws VT natively. Kf6 works well now too, the latest patch expands the VT parent window to the largest text. I never complained about the quality of drawing. I just claim, and demand, that we absolutely never ever allow a situation in which tabs are out-of-view (whether scrollbar-accessible or otherwise). gen actually doesn't exhibit this problem with any dialog I've seen; and neither does qt5. Have not been able to load kf5 for some reason, and the nightlies don't come with a kf6 VCL. It's possible that some such dialogs do exist, or that I might see it on a lower-resolution display. > The remaining issue I see is with gen that > spaces out the tabs and hides some vertically in case of Styles > Edit > Style... but only after adding icons ending up in a tad larger tab height. > And only for gen. And only if CTL/CJK are enabled. Separate issue; file it please. > Of course it depends on many other factors such as resolution, scaling, and > system font. While it might be possible to solve the gen issue we cannot > deal with every configuration. So my take: if this is the problem we just > show the scrollbar. And aim for less than 12 tabs. On the contrary - we can, and we must. The desideratum should be that the tabs don't go off-screen. And when building LibreOffice (or reviewing commits), we must _prove_ that this can never happen, on any display which meets our minimum requirements; and if that can't be proven - then we have a bug. And such bugs can be resolved by taking one of the measures of: less height per tab, less tabs in dialog, more height for dialog, going back to vertical tabs, or two tab columns. Any of these, even the last of them, is a great improvement compared to tabs potentially going off screen.
(In reply to Eyal Rozenberg from comment #17) > we must _prove_ that this can never happen... All container UI have some overflow mechanism. We absolutely cannot guarantee that everything is shown on the screen, for example a device with 1440x900px resolution using a font size of 16px and a theme that adds large margins around controls.
So, LibreOffice 25.8 has been released with a Paragraph Style dialog in which not all tabs are viewable. That is very bad and should not have happened. I would like to ask for this bug to now be switched to a higher priority. Will add an additional screenshot. Heiko, if you are missing any information in order to fix this, please mark NEEDINFO again but be specific.
Created attachment 202815 [details] Paragraph style dialog box - LO 25.8, GTK3, 1920x1080 monitor Problem persists even with our release. Version: 25.8.0.2 (X86_64) Build ID: 80a8bc2ef75d415a197e282da0ebf917315d5e24 CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Calc: threaded
Issue of OP is GTK3 only Win builds are unaffected, and UI fully fits screen while the VT list scrolls as needed (looks like the GTK3 flavor does as well--the arrow up and down). Also for 26.2, users now can choose (Tools -> Options -> Appearance) to retain Horizontal tab layout of dialogs, or accept the new Vertical Tabs motif with its associated icon layouts. Don't know that we need do anything further just for the gtk3 use. IMHO => WF
Created attachment 202821 [details] Vertical Tabs status on Win, 25.8.1 and 26.2.0 with icons
(In reply to V Stuart Foote from comment #21) > Issue of OP Issue of OP? Issue of LibreOffice. Always so dismissive after so many years doing QA. > is GTK3 only ... don't know that we need do anything further just for the gtk3 > use. "Only", "just" - as in, "only" affecting millions of LibreOffice users for which GTK3 is their default VCL. No need to do anything for them I guess. > Also for 26.2, users now can choose (Tools -> Options -> Appearance) to > retain Horizontal tab layout of dialogs You're suggesting that our users have to experience this bug; develop the idea that maybe they would like to disable vertical tabs altogether (giving up the benefits vertical tabs do offer); ; then locate a relevant setting for this disabling - all so as to circumvent our bug? No.
(In reply to V Stuart Foote from comment #21) > Also for 26.2, users now can choose (Tools -> Options -> Appearance) to > retain Horizontal tab layout of dialogs, or accept the new Vertical Tabs > motif with its associated icon layouts. Horizontal tab layout has the same issue as vertical one: not enough room to show all tabs and to discover that there is more tabs left or right. Best regards. JBF
Gtk3 draws natively with large margins leading to more aggressive overflow (but properly adds controls to scroll through the list). We cannot change this behavior except by enlarging the whole dialog, in theory. The Gtk design was build for less complex dialogs and considering alternative input methods. You can start the application with the generic VCL or for Qt, if the binary is build for it. And as mentioned before you can switch to horizontal tabs as another countermeasure. => NAB/NOB
(In reply to Heiko Tietze from comment #25) > Gtk3 draws natively with large margins leading to more aggressive overflow > (but properly adds controls to scroll through the list). We cannot change > this behavior except by enlarging the whole dialog, in theory. Of course we can change it. * We can draw the dialog differently on GTK3. Specifically, we can use a control similar to the one we use in Tools > Options, which has little vertical padding/margins. * We could use that control for this dialog, and other overflowing dialogs - on all VCLs - which would be less visually pleasing perhaps, but would forego the need for VCL-specific dialog layout if that's an issue. * Even easier - we could render all overflowing dialogs with horizontal rather than vertical tabs. And at least one, if not two, of these stop-gap solutions are easy to implement. (Actually, I also suspect that the vertical spacing of the tab headers we have now can in fact be manipulated with some programming effort, although that's only speculation.) This serious problem was reported well before 25.8 was released, and that release should absolutely not have taken place with vertical tabs enabled where they must not be. This frivolous attitude reminds me of the active cell rectangle situation: Massive UI degradation being adopted with nothing but a shrug, with people having to clamor and make a fuss afterwards to get that retracted or fixed. > The Gtk > design was build for less complex dialogs and considering alternative input > methods. You can start the application with the generic VCL or for Qt, Heiko, we've been over this endless times in many bugs. It is entirely irrelevant to tell a bug reporter that "you can do X" or "you can do Y". The bug is in the how LibreOffice behaves when the typical user runs it; it is not about the workflow of a power-user who knows about VCLs and switching them can arrange for more convenient settings. The only situation in which you can dismiss bugs with a certain VCL by saying "use another VCL", is if that VCL is not intended for public use. You can say this (maybe) about issues with QT6, or GTK4, or gen; not about GTK3. We cannot legitimize an introduction of a massive, critical degradation in the UI by the fact that only 10% or 8% of users experience it. Please don't wait for other users to come shouting about this (like with the active cell rectangle situation). > => NAB/NOB You made no argument for "not a bug", so how can you even suggest that? As for "Not our bug" - we chose, or rather you chose, to have this dialog look this way. We can draw it differently. So it is our bug.
Again, there simply is no functional, design, or UX issue with all controls not being visible on a dialog or toolbar. That is what overflow handling provides. There is a valid issue when the UI impacts users ability to identify and select a control. Movement to VT with icons is a well implemented evolution of the UI. Spacing issues on GTK3 (where we draw the controls compliant with that toolset) do not invalidate the UI design. Rather it points to need to resolve bug 165989 bug 167955 providing mouse/touchpad and screen swipe for scrolling the VT listings. Additionally, for consistency, all the dialogs with VT layout implemented really should be user resizable at least in y-axis, so user can choose/set their preferred height.
(In reply to V Stuart Foote from comment #27) > Spacing issues on GTK3 (where we draw the controls compliant with that > toolset) do not invalidate the UI design. Please re-read the motivation for having vertical tabs in the first place: bug 99528, comment #0. This behavior in GTK3 completely invalidates the design. But, of course - the invalidated design is not vertical tabs _generally_; it's just that vertical tabs are valid only while, and to the extent that, all tabs are always visible, and never move or scroll around, and can't get mixed up. > Again, there simply is no functional, design, or UX issue with all controls > not being visible on a dialog or toolbar. That is what overflow handling > provides. Exactly the contrary. It is horrible design and UX to have what should be the fixed UI of the dialog be messed up and redistributed, so that they look like the what should be a fixed UI, but in fact are different tabs in the same places. It is confusing, it is jarring, it prevents forming "muscle memory" for reaching controls on panes in the dialog, and in fact, it hampers forming the overall idea of what the dialog contains. And this is even worse than with the horizontal tabss about which Samuel Mehrbrodt was complaining. It should also be stressed that we are not even talking about overflow control, per se, e.g. affordance for some extra items at the bottom of a list; we're talking about a scrolled view of items. That is something which is only ever acceptable for _content_ - the list of available fonts, or of the file formats to save a document as etc. It is entirely unacceptable for dialog tab headers.
I have read all the new comments since last time and would like to add the following: I am probably more on the side of the end user or user assistant. I find arbitrary remarks unacceptable such as “it's enough,” “it's not a problem,” or “it's only a problem for users with a particular VCL” (and yet gtk3 is not particularly anecdotal; knowing how to switch VCLs considerably reduces the population) . They just have to change. That pretty much ends the debate. And I thank Eyal Rozenberg for his search for an acceptable compromise. Yes, I should share my general comments on this change in the initial bug report. But that's the bug I found in the first place. Still, I'll do it. I repeat what I have already stated: it is not acceptable for the end user, who has no visibility of the development process, for such a change to be applied without warning, without information in the release notes, and without first being placed in the experimental features. Once again, the strategy adopted for the meta bar should be followed here. It allows us to accept the “draft” nature of a gradual implementation. It allows us to avoid upsetting the user. The adoption of the meta bar took time, years, and is still not the default setting? Very well, it is up to the user to make the choice for their needs. Not the developers, not the designers. The user benefits from and appreciates the investment made by developers and designers to offer them new, more suitable features (or at least features that attempt to be more suitable). As soon as LibreOffice imposes and does not give a choice, LibreOffice loses some of the freedom it offers. I haven't forgotten that the subject of this bug is the appearance of the vertical menu bar (new appearance) which, according to the dialog box, causes the menu to be displayed incompletely. V Stuart Foote considers that there is nothing to review or improve, the overflow is fine. Period, end of discussion. I would like to emphasize several points (already mentioned) - beyond muscle memory, this requires remembering which features are present for which the tab is no longer displayed (not just muscle memory, so once again, let's be inclusive and think of those who won't remember) - Knowledge of the features offered by the interface. Will we be able to identify that there are “menus” to scroll through? Can we make some of the settings “invisible”? How can we ensure this? - Let's not believe that offering different functions depending on the dialog boxes is a possible or coherent solution. Users won't understand it and won't know what to do. - Let's not rush through the issue of different languages, as the impact can be much more disruptive from one language to another. Once again, this argues in favor of making it an experimental feature. This would satisfy the most impatient users, who would be tolerant of the initial rough edges, and would allow time to offer something more polished to everyone later on. One last point after reading the comments: A display similar to what is offered in Tools > Options would indeed be quite interesting. It removes a number of obstacles. In the same vein, the search box would then be invaluable for finding the parameter you want to change, without having to scroll through a menu to find the right tab/item where it is located. Of course, this is an improvement “in addition to” and not “instead of.” Thank you on behalf of the users :-) ************ Original French Version ************ J'ai lu tous les nouveaux commentaires depuis la dernière fois et j'ajoute les éléments suivants : Je me situe probablement plus du côté de l'utilisateur final ou de l'assistant utilisateur. Je trouve inacceptable des remarques arbitraires du type "c'est suffisant", cela ne pose pas de problème, cela ne pose un problème que pour les utilisateurs avec un VCL particulier (et pourtant gtk3 n'est pas particulièrement anecdotique, de là à savoir switcher de VCL, on réduit considérablement la population), ils n'ont qu'à changer. Cela ferme plutôt tout débat. Et je remercie Eyal Rozenberg pour sa recherche d'un compromis acceptable. Oui je devrais faire part de mes remarques générales sur cette évolution dans le bug initial. Seulement c'est bien ce bug que j'ai trouvé au départ. Mais je vais le faire. Je renouvelle ce que j'ai déjà précisé, il n'est pas acceptable pour l'utilisateur final qui n'a aucune visibilité du processus d'évolution qu'un tel changement soit appliqué sans prévenir, sans informations dans les notes de version, sans être placé dans un premier temps dans les fonctions expérimentales. Encore une fois, la stratégie adoptée pour la méta-barre devrait être suivie ici. Elle permet d'accepter le caractère "brouillon" d'une mise en place progressive. Elle permet de ne pas brusquer l'utilisateur. L'adoption de la méta-barre a pris du temps, des années, et n'est toujours pas le réglage par défaut ? Trés bien c'est à l'utilisateur d'en faire le choix pour son besoin. Pas aux developpeurs, pas aux designers.L'utilisateur profite et apprécie l'investissement des développeurs, et des designers pour lui proposer de nouvelles fonctionnalités, plus adaptées (enfin qui tentent de l'être). Dès que LibreOffice impose et ne donne pas le choix, LibreOffice perd un peu de la liberté qu'il offre. Je n'ai pas oublié que le sujet de ce bug est l'apparence de la barre verticale de menu (nouvelle apparence) qui induit, selon la boite de dialogue un affichage incomplet du menu. V Stuart Foote considère qu'il n'y a rien à revoir ou améliorer, le débordement gère. Point, fermez la discussion. Je voudrais insister sur plusieurs points (déjà évoqués) - au delà de la mémoire musculaire, cela exige de retenir quelles sont les fonctionnalités présentes, pour lesquelles l'onglet n'est plus affiché (pas que musculaire la mémoire donc, encore une fois, restons inclusifs, pensons à ceux qui ne retiendront pas) - la connaissance des fonctionnalités offertes par l'interface. Va-t-on bien identifier qu'il y a des "menus" à faire défiler ? Est-ce que l'on n'arrive pas à rendre "invisible" une partie des réglages proposés ? Comment s'en assurer -ne croyons pas que proposer des fonctionnements différents selon les boites de dialogue est une solution possible ou cohérente. L'utilisateur n'y comprend rien, il ne sait pas sur quel pied danser. -ne passons pas trop vite la question des différents langages proposés, l'impact peut être bien plus gênant d'un langage à un autre. Encore une fois cela plaide pour un passage en fonctionnalité expérimentale. Cela permettrait de contenter les plus impatients, qui serait tolérant devant le coté brouillon de départ, et laisserait le temps de proposer quelque chose d'abouti à tous, plus tard. Un dernier point à la lecture des commmentaires : Un affichage similaire à ce que propose Outils > Options serait effectivement assez intéressant. Cela retire un certain nombre de frein. Dans cette même logique, la zone de recherche serait alors précieuse pour trouver le paramètre que l'on veut modifier, sans avoir à faire défiler un menu pour trouver le bon onglet/item où il est présent. Bien sûr il s'agît d'une amélioration "en plus de" et pas d'un "à la place de" Merci pour les utilisateurs :-)
Looked into a potential solution with set_margin but no success. Gtk developer replied on IRC: "Calling gtk_widget_set_margin_top on the tab's widget will not work because the default spacing is usually handled by the GTK theme and applied to the notebook's internal components, not the tab label itself". So it's clearly NOB - or we have to reduce the number of tabs.
Caolan provided a working solution. Patch incoming...
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bc23214c2b9defa71401d4e58f8d59cdecafc839 Resolves tdf#165474 - Ensure all items being visible on vertical tabs It will be available in 26.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.
Thank you very much Heiko and Caolan, it is far better with this patch. All tab labels are now visible. Tested on: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bc23214c2b9defa71401d4e58f8d59cdecafc839 CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Ubuntu_22.04_x86-64 Calc: threaded Is it possible to backport this fix to 25.8? Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #33) > Is it possible to backport this fix to 25.8? I'm a bit hesitant to quickly backport patches. In this case it should not be an issue. Xisco, what do you think?
(In reply to Heiko Tietze from comment #34) > (In reply to Jean-Baptiste Faure from comment #33) > > Is it possible to backport this fix to 25.8? > I'm a bit hesitant to quickly backport patches. In this case it should not > be an issue. Xisco, what do you think? There have been a lot of activity related to vertical tabs recently in master so ideally the patch should be tested in libreoffice-25-8 branch before merging to see if it works well there too