The Calc UI has always put the sheet tabs on the same line of the horizontal scrollbar, which was resizable by the user to free the space needed for tabs. Now in 4.4.0.1 the scroll bar has moved up, hiding about another line of data, since it is no more placed in line with the sheet tabs. In a single sheet calc file this results in an absurd stripe which is 95% empty, and unless you work with files with dozens of sheets, some space is always wasted. If this behaviour is preferred by some users, calc options should let the user decide, not impose it.
An explanation for the reason can be found on: https://wiki.documentfoundation.org/ReleaseNotes/4.4 -> see Tab Changes in the GUI section But maybe an additional customisation option can be added as suggested by Andy, where the user can decide which form he/she would like to use.
let's see what the UX-team thinks about it. status NEW
Oh, a jewel: > this results in an absurd stripe It’s not unknown that every feature introduced will be seen as a “bug” (even a “regression” [of what?]) by some. It’s impossible to please everybody. This was a desired change, with a proper design rationale behind it (and desirable technical outcomes as well, such as supporting overlay scrollbars in OS X and Linux), already signed off by a UX designer (Mirek), we won’t just revert it right now when the change has not even yet shipped in a major stable release. And no, we also won’t clutter the program’s source code and Preferences UI with more options — we’re trying to go the opposite way: simplifying it.
At first I didn't like too much also, but after a bit of use, besides easier work with tabs. I think the major benefit is that now it's an option set up in the OS the width/height of scrollbars without worry about the tabs size, specially if you like thin scrollbars. I'm agree, about that we already have a lot of them. More options more tickets for trouble.
+1 as designed, and for WONTFIX...
Of course the prevailing opinion has to ..... prevail, so I won't take it to the streets to protest this. However let me add just one note: one of the things all M$ Office users admire and appreciate when they see me using LO is the vast and uncluttered work area; as you probably know just as well as I do, M$ Office standard interface (which is left as it is by 98% of users just out of laziness) has lately become so cluttered with big menus object etc. that you have the ridicolous situation where, unless you have a retina resolution screen, you can just see a dozens lines of cells of you spreadsheet or, in the same way, you write something in Word and can look at no more than a few lines if text at a time. This is made even worse by the present days screens who tend to be extremely "landscape", while most workflows like writing or using data on a spreadsheet are really "vertically intensive" affairs. For example, the right side tools now available in LO and OO are a perfectly rational solution to this absurdity - and moreover, they are completely optional. On the contrary, forcing the user to give up some further space in the vertical dimension, as it happens here, is IMHO a much less smart move. By the way, a similar change was made a few years ago in Impress, where the five tabs (normal, structure, etc) for slide display modes could have been easily put together with the horizontal scrollbar (even more than in Calc, since they are fixed in number and size and occupy just a fraction of the line where they are), but take instead their own space which is an empty and totally unused part of the UI (see attachment to clarify, space circled in red). I notified that as well at the time, but if was declined in the same way. UI design is a really important part of an app, and I am no professional of course on this topic; however I feel that having some space in it which is empty and an unavoidable part of it is not really smart in general. I thank you for the attention anyway!
Created attachment 111365 [details] the unused space in the UI design of Impress is circled in red
(In reply to Andy from comment #6) > By the way, a similar change was made a few years ago in Impress, where the > five tabs (normal, structure, etc) for slide display modes could have been > easily put together with the horizontal scrollbar (even more than in Calc, > since they are fixed in number and size and occupy just a fraction of the > line where they are), but take instead their own space which is an empty and > totally unused part of the UI (see attachment to clarify, space circled in > red). Thanks. While we’re not planning to move these tabs out of their row, we want to improve their placement to reduce the wasted space. See bug 73077.
Hi, I am here again because I wanted to suggest a possible simple solution to make everybody happy on this topic: At first I did some trials to see what configuration was best for me after the separation of horizontal scroll bar and tab list. I came to the conclusion that I did not actually need the horizontal scroll bar so often: even if we are all used to it, I very seldom use more than a couple of pages of cell columns (say about 30 - max 40 columns) horizontally. Since on this limited scale scrolling is easily performed moving the active cell with the left and right arrow keys, I could most of the times do without the Horizontal scroll bar. However, while in Writer you can do the same and insert in a toolbar a button to quickly show/hide the horizontal scrollbar if needed, the same button is not available for Calc. At present, to hide/show it you have to open the "Settings" dialog window, go to the right tab, etc. etc. which is definitely unfeasible on a high frequency basis. If such a button were available in Calc too, all would be well: when, like me, the user strongly values space for data display, he will keep the scroll-bar hidden, showing it with the button only when convenient. And I suppose that the addition of such a button to those available for Calc toolbars should be an easy task. Thanks,
@Andy, *, (In reply to Andy from comment #9) > ... > If such a button were available in Calc too, all would be well: when, like > me, the user strongly values space for data display, he will keep the > scroll-bar hidden, showing it with the button only when convenient. Any Spreadsheet table is by default much larger than any typical display screen so the Scroll-bar widgets are auto enabled and will always be an expected default UI function. You say you'd want non-display of scroll bars to be your norm--but that is a UI configuration not normally achieved with a toggle button. In fact, the scroll bar(s) have always had a configuration control in each module. In Calc, for those like yourself who might prefer to keep the extra spreadsheet table space (and depend on cursor and page movement) the scroll bars are easily disabled. Done from, Tools -> Options -> LibreOffice Calc -> View: with a separate check box for Horizontal Scroll bar, Vertical Scroll bar. A toolbar or menu item button to toggle behavior would be possible. But frankly a button or menu item seems superfluous given the continued ease of configuring UI behavior in the View for each module.
Thanks for listening. Yes, I know very well that you can hide/show each scroll bar with a specific setting in the options dialog window. I actually noted it in my previous post, maybe you've missed the clause: "...At present, to hide/show it you have to open the "Settings" dialog window, go to the right tab, etc. etc. which is definitely unfeasible on a high frequency basis...." The fact is that the horizontal scroll bar for me is not needed so often to keep it there all the time, but still it is needed often enough that going into the option settings each time you want to show it momentarily is way too long. A toolbar button would instead allow to instantly use it to move where you need to go in the sheet, then hide it again in no time. After all, the toolbar button is there for the same scroll bar in Writer, why should there be a difference between the two applications? I hope to have made things clearer now.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=12d37f92507ab66fd519a68a2479e1cd7136cf74 fdo#87684 option to make tabbar inline with scrollbar again It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Note: the change in Calc also affects the tabs in Draw, where vertical space is precious too. I'll reopen this and then mark as fixed because of the commit of Tomaz - thanks for that!
see comment #12
regressions are regressions, adding keyword
I would like to thank everybody for the interesting discussion on the issue. While everybody's opinion on it has some merit and should not be rejected on a priori basis, I am glad to see that I am not the only one who does have some reservations on irreversible changes that are not too smart regarding screen real estate, particularly on the vertical axis , which has been strongly sacrificed on late PC for reasons that have more to do with movies and games display than anything else. So thank you for the effort/patches/fixes, I will be glad to try and check them out when 4.5 is at the RC stage. To those who showed some irritation towards my comments, implying that it was too late to raise the issue now, I am soory for that but I would like only to point out that as a user I am not involved in the engineering discussions that take place about every detail (nor I could be, I have another job), so that very often I am only aware of a change that has been discussed for a long time when it reaches RC stage (that's normally the moment when I update my install of LO).
(In reply to Andy from comment #16) > To those who showed some irritation towards my comments, implying that it > was too late to raise the issue now, I am soory for that but I would like > only to point out that as a user I am not involved in the engineering > discussions that take place about every detail (nor I could be, I have > another job), so that very often I am only aware of a change that has been > discussed for a long time when it reaches RC stage (that's normally the > moment when I update my install of LO). Frankly, that is a very selfish position. With a few exceptions, work on LibreOffice is done by unpaid volunteers--and even those who are paid to work on it often have other responsibilities to their employers. With minimal effort or investment of your time, you could easily stay current and relevant to development of the project. The Design and UX-advise mail lists and project Wikis are freely available. Nabble-- http://nabble.documentfoundation.org/LibreOffice-f1639495.html even consolidates the ML for you. Daily builds containing the latest commits are readily available-- http://dev-builds.libreoffice.org/daily/master/ With clear instructions for installing in parallel so as not to impact your full release install -- https://wiki.documentfoundation.org/Installing_in_parallel That said, while Tomaž has provided a working configuration, given your comment 11, you will not now find it to your liking. It requires using Tools -> Advanced: Expert Configuration and locating the "TabbarInlineWithScrollbar" property. Also, at present it is only applied to the Scroolbar/Tabs on Calc, it does not impact Impress. Work on bug 73077 will resolve that. @Foss -- the new default was designed and implemented as such to permit scroll bars to integrate better by OS and DE. It was never a regression.
My final comment on this: Open Calc and move to the Tools -> Options -> Calc -> View panel (panel selection is stateful -- it will be there next launch). Then issue the following from the keyboard whenever you need to toggle <alt>+T+O+Z<enter> Aren't accelerators wonderful ;-)
Hi Stuart, (In reply to V Stuart Foote from comment #17) > Also, at present it is only applied to the Scroolbar/Tabs on Calc, it does > not impact Impress. Work on bug 73077 will resolve that. From the description there it doesn't look as it is related. But let's see ;)
(In reply to Cor Nouws from comment #19) > From the description there it doesn't look as it is related. But let's see ;) Design and implementation to address fdo#73077 is related only in the sense that it was raised here as an example of a widget consuming vertical space in the UI. It is not linked to its horizontal scrollbar. From OOo it has always been positioned at top as a horizontal tab bar, but there is no reason it could not be converted to a vertical tab bar, and positioned right or left--or even placed as content panel on the Sidebar. Your note on comment 13 kind of suggested differently, wanted to clarify that nothing has been done that affects Impress, and that there has never has been linkage between its tabs and horizontal scrollbar.
(In reply to V Stuart Foote from comment #20) > Your note on comment 13 kind of suggested differently, wanted to clarify > that nothing has been done that affects Impress, and that there has never > has been linkage between its tabs and horizontal scrollbar. I expect that the code for Calc is also used in Draw. Take a look ;)
I did, on Windows 7 sp1, 64-bit en-US with Version: 4.5.0.0.alpha0+ Build ID: 90d8f4fca566e46171b260ee3aadc655871c92ba TinderBox: Win-x86@39, Branch:master, Time: 2015-01-10_00:27:09 Locale: en_US Tomaž's "TabbarInlineWithScrollbar" Expert configuration property does not affect Draw's horizontal scrollbar and horizontal tabs (Layout, Controls, Dimension lines).
@Tomaž, Might we impose on you to go have a look at feasibility of adding a similar expert configuration property to duplicate for Draw, what was done for Calc with its "TabbarInlineWithScrollbar"? Samuel's and your work in September on LayerTabBar and viewshell for bug 36772 in http://cgit.freedesktop.org/libreoffice/core/commit/?id=20800ebc7ef05637134c3915798e13a272663341 Thanks!
Dear Stuart, I can easily agree that I - as generally everybody - could do more to be involved in LO development. And I was not implying that I was the only volunteer dealing with paid professionals, of course. However, I must say that I would find it impossible, at least at the moment, to find more time to spare to do this. As a academic dealing with statistics and data management, I teach all my courses with LO software; make all exams with it; have pressed and succeeded in having it installed everywhere in PC labs and classroom all over the 3000 students Campus, so that all users - teachers and students alike - have always the option to choose it; I advice and counsel anybody interested in LO on any issue regarding it and ts adoption. Doing this is not without costs, since promoting LO and especially Calc in such a strong and pervasive way, requires a substantial effort - consider that every time an update is applied, I have to check if any problem has surfaced that affects the work I am doing in various courses, and I must do it quickly and thoroughly, both to report the bug ASAP, and to try and find some workaround that is simple and does not cause students to protest it is too complicated or absurd. Sometimes this process turns out to be a big stress test! This fall, for example, the equation editor was missing all lowercase greek letters: you can imagine how difficult this was for us. Or just a couple of weeks later, we had to deal with a significant change in the way the user has to interact with matrix formulas, again something that I use everyday in classrooms, which was undocumented and quite dubious in its rationale. Right now I have two other critical (for the work we do) Calc bugs that I have to live with in classes everyday, still to be solved: copy and paste of matrix formulas in multiple cells does not work anymore; and formula input cells visualization that has partially disappeared, when the same cell is involved more than once in a formula, Sorry for not being able to do more, but that's it..... thanks anyway
Just to explain: I knew the issue was present for Draw also, but I did not mention it because work on data in calc is to me usually more "vertically oriented" that that in Draw and I am not a drawing specialist, so I was not sure to be able to speak on that with competence.
Just to propose an elegant solution (from a UX point of view, not a programming point of view): have Calc use separate lines for scrollbars and tabs when the user has the scrollbars set to be very thin, and have Calc use the same horizontal line for scrollbars and tabs when the scrollbars are thick and juicy. No options needed; screen real estate is automatically maximized.
I don't think we want tabs to depend on scrollbar in any way - tab height should be constant regardless of the scrollbar height. Also what is considered thin and what thick scrollbar? In LO 4.5 it is possible to turn the old inline tab and scrollbar view back (via expert settings), but the tabs are still the same size. I myself prefer inline tabs and scrollbar now in all scenarios.