The calc sheet-tab widget is normally at the bottom left of the grid and makes it easy to add and remove sheets. Recently we added a nice '+' widget to this to allow adding a sheet. It seems to me that on a very wide screen - we don't do a wonderful job of allocating enough space for tabs; I can easily have only ~10% of the screen containing my tabs, and the rest as a huge scrollbar - which is quite annoying. It'd be nice to tweak that balance, so more tabs are visible as a proportion of the screen space.
I agree, that would be great. But I doubt that it will be an easyhack, because several considerations will be involved, for example: a) A fix for "Bug 41777 - Window size reopening a document not like size when saved" might be precondition b) What if user adjusted allocation manually? Should that be ignored for next fileopen? c) how should size of docked toolbars (right / left) be mentioned? d) how should creation of additional TABs be regarded? e) is unification of IMPRESS / DRAW Layer TABs handling required? Some further considerations in my attached screenshots with comments.
Created attachment 52644 [details] Screenshots with comments
Not a particular Master bug, most of the behavior OOo heritage.
I think Michael is talking about the default tab control width when the width is not explicitly specified. The tab control width can be stored with the document, so when it is stored with the document, we should just set that width don't do our own width calculation. When the width is not explicitly set, however, we simply use the default size of the tab control, which appears to be 270 pixel wide regardless of the number of initial sheets. And here, we could indeed use a bit more clever algorithm to determine the best tab control width given the number of sheets.
The width of the sheet tab control is calculated in ScTabView::DoResize(), along with the size of all the other controls. One should be aware that the width may be set manually via ScTabView::SetTabBarWidth(), after which we should stick with that manual width. The tab control itself is defined by class ScTabControl, which is a child class of class TabBar in svtools. The tricky part is, we may not know the required width of the sheet tab control such that all the sheet tabs be visible. So, depending on how good we want the algorithm to be, we may have to tweak the code in class TabBar as well. I would say this is a medium-difficulty easy hack.
Myself and some other college students are in a class on open source software and we are starting to look at this bug as our first real project. My plan so far is as follows: 1. figure out how to calculate an optimal size for the tab selection part - either as wide as it needs to be to show all the tabs or a third of the size of the window, whichever is smaller. 2. figure out an absolute minimum size for the tab part - like where it shows 2 or 3 tabs plus the little scrolly thing. 3. Whenever the window is resized, regardless of whether the user manually set the size or not, if the size of the tab selection part is less than the minimum, or more than the maximum, it is clamped. (exception: when the window is super tiny. At that point no one cares and the current behaviour is fine) 4. limit the users ability to resize the tab part bigger than the size of all the tabs? 5. update all of this stuff whenever the number of tabs changes, just like on a resize
Forest - wonderful to have you involved; thanks ! :-) 4. sounds reasonable enough with the '+' sign widget we have in there; but Kohei / Eike might want to
(In reply to comment #7) > Forest - wonderful to have you involved; thanks ! :-) > > 4. sounds reasonable enough with the '+' sign widget we have in there; but > Kohei / Eike might want to Well, I personally don't want to limit user's ability to re-size, since that would also affect the re-sizability of the horizontal scroll bar (some users may want it small). Other than that, all the other points Forest raised sound very good to me. :-) Welcome to our project, Forest!
I noticed that there are 5 versions of tabview.cxx, I'm assuming that they are different implementations of the tabview, probably from days past?
(In reply to comment #9) > I noticed that there are 5 versions of tabview.cxx, I'm assuming that they are > different implementations of the tabview, probably from days past? No, they each implement different set of ScTabView methods; they are not different implementations of ScTabView. This sort of division of source files is common in this code base. It was introduced back when C++ compilers has limit on the size of a source file it could handle (or so I'm told).
I'm sorry that this is off topic, but this is the only place we have been able to get in contact with knowledgeable developers. After we got back from winter break, our build environments were changed, and were not backed up, and now we are having build issues that we can't resolve. We currently cannot build. Here are the key bits of information we need. All I'm asking for is a trivial response. - Has anyone else been having build problems recently in smoketestoo_native with a missing cliureversion.mk? If you want details, here is a post by a fellow student about the problem: http://lists.freedesktop.org/archives/libreoffice/2012-January/024798.html - Assuming that I'm starting from a mint fresh ubuntu 10.04 instalation, is this the correct process for building an older revision of LibreOffice? http://pastebin.com/BVRdPAa2 - What is the most popular / best environment in which to build LibreOffice?
> I'm sorry that this is off topic, but this is the only place we have been > able to get in contact with knowledgeable developers. We are all (and far more of us) on the developers list. You need to ask small, nice, self contained questions there with all the relevant details. > After we got back from winter break, our build environments were changed, > and were not backed up, and now we are having build issues that we > can't resolve. That is annoying of course- but without a reasonably complete build log, and some more interactive help [ such as that you can get on IRC - ask on #libreoffice-dev on irc.freenode.net ], it is hard to help here. > Here are the key bits of information we need. All I'm asking for is > a trivial response. Quite possibly the problem is not trivial. > - Has anyone else been having build problems recently in smoketestoo_native > with a missing cliureversion.mk? If you want details, here is a post by a >fellow student about the problem: > http://lists.freedesktop.org/archives/libreoffice/2012-January/024798.html Not personally, no. > - Assuming that I'm starting from a mint fresh ubuntu 10.04 instalation, > is this the correct process for building an older revision of LibreOffice? > http://pastebin.com/BVRdPAa2 Why start from Nov 30's of last year: > git branch -f rollback ec894c5fb90bdee1c56d113d14b0bf524df9f # create > new branch named rollback starting from the commit indicated by the hash Looks odd. > - What is the most popular / best environment in which to build LibreOffice? As long as it's not windows, it should be reasonably do-able from any Linux; I use openSUSE of course, but YMMV.
Thanks for the help, we finally got a response on IRC that suggested using some other linux distribution might help. We switched to Fedora and now it is working again.
Created attachment 58579 [details] preliminary patch Hi, Here is our preliminary patch that somewhat resolves this issue. We decided to take a different course of action in how we approach the fix. We made the position of the tab-bar splitter relative to the window size, rather than pixel-specific. We also made the tab bar splitter "drag out" the tabs as if inside a drawer instead of leaving empty space. There could be some issues with this patch. For example, we should probably apply the same relative behaviour to the phSplitter (the splitter that can be dragged out from the right side to allow the user to see two different sets of columns at the same time). Also, we plan to make the "drawer" behaviour cease when a different tab is selected. Finally, one variable that we use, mfPendingTabBarWidth, is used elsewhere and we need to ensure that we aren't breaking whatever else uses it.
Some other students and myself were wondering about some additional enhancements to this bugfix. Should minimum and maximum tab sizes be enforced (e.g. further truncation of sheet names, max character limit, and single character names)? Should the boolean (mbTabsLastMovedBySplitter) that is changed when the aHSplitter is selected be a right-click menu option that the user can set and reset during the same session? Should that boolean state also be stored when the document is saved? Should the "active tab" widget be shown along with the "+" widget when the splitter is being moved on top of the other tabs? If the tab area is too small to show both the "active tab" and "+" widgets, the splitter will simply move over top of them.
Hi there, Thanks for working on this. I've just tested your patch. But I'm not sure if I see any noticeable improvement. What I did is as follows: 1. Open a new spreadsheet document. 2. Go to Tools -> Options -> LibreOffice Calc -> Defaults. 3. Change the number of default worksheets to, say, 5. 4. Click OK. 5. Close the app. 6. Re-open Calc with a new document. 7. the right part of the tab is still obscured. This results even when the window is large enough to show all tabs (including the plus tab). What I would expect is that the default position of the drag handle to be variable based on the number of sheet tabs such that all sheets be visible when the window is large enough. Regards, Kohei
(In reply to comment #15) > Some other students and myself were wondering about some additional > enhancements to this bugfix. > > Should minimum and maximum tab sizes be enforced (e.g. further truncation of > sheet names, max character limit, and single character names)? Are you talking about SC_TABBAR_MIN and SC_SCROLLBAR_MIN in tabview.cxx? If so, I don't have a strong opinion about this. If you feel that it's better to change them, I won't have any objection. > Should the boolean (mbTabsLastMovedBySplitter) that is changed when the > aHSplitter is selected be a right-click menu option that the user can set and > reset during the same session? No. > Should that boolean state also be stored when the document is saved? Nope. > Should the "active tab" widget be shown along with the "+" widget when the > splitter is being moved on top of the other tabs? If the tab area is too small > to show both the "active tab" and "+" widgets, the splitter will simply move > over top of them. Honestly, I have no idea. ;-) I would think that showing the active tab should be the priority. I wouldn't worry too much about the plus tab. Hope this helps.
Created attachment 60503 [details] diff of the fixes, updated to fix the problem Kohei mentioned Ok, here is a new patch with the problem that Kohei mentioned fixed. I tried it out by applying it to a slightly older version because the current master doesn't build for me (on fedora right now).
(In reply to comment #18) > Created attachment 60503 [details] [review] > diff of the fixes, updated to fix the problem Kohei mentioned > > Ok, here is a new patch with the problem that Kohei mentioned fixed. > > I tried it out by applying it to a slightly older version because the current > master doesn't build for me (on fedora right now). Hello Forest, This patch is definitely in the right direction. I can see different width of the visible area depending on the tab count. I can still see two issues: 1) the width is still not wide enough to show all tabs (including the '+' tab) when the window is not maximized. Especially when you set the initial sheet number to, say, 6, only the first 5 sheet tabs are visible. 2) The patch ignores custom width set by the document. See Comment 4 for details. BTW, this is not a major issue, but it would be great if you could create your patch by git format-patch, rather than git diff. See this page http://wiki.documentfoundation.org/Development/Patch_Handling_Guideline for general guidelines that we follow. It's not mandatory, but it would make our job a bit easier when applying patches. Thanks a lot! Sorry it took a little while for me to review. Kohei
(In reply to comment #19) > 1) the width is still not wide enough to show all tabs (including the '+' tab) > when the window is not maximized. Especially when you set the initial sheet > number to, say, 6, only the first 5 sheet tabs are visible. So, make the window small, initial sheet count to 6, new sheet, and the plus is hidden? > 2) The patch ignores custom width set by the document. See Comment 4 for > details. The intended functionality is that when you save a document and re-open it the splitter should be in the same place?
(In reply to comment #20) > So, make the window small, initial sheet count to 6, new sheet, and the plus is > hidden? excuse me, I meant new spreadsheet document not make a new sheet/tab.
(In reply to comment #20) > (In reply to comment #19) > > 1) the width is still not wide enough to show all tabs (including the '+' tab) > > when the window is not maximized. Especially when you set the initial sheet > > number to, say, 6, only the first 5 sheet tabs are visible. > > So, make the window small, initial sheet count to 6, new sheet, and the plus is > hidden? Make the window smaller but large enough to have enough room to show all the tabs. In my case, I just un-maximized the window. And it's not just the plus tab that's hidden, Sheet6 tab and a part of Sheet5 tab was obscured as well. > > 2) The patch ignores custom width set by the document. See Comment 4 for > > details. > > The intended functionality is that when you save a document and re-open it the > splitter should be in the same place? Not exactly. When the user never adjusted the scroll bar width, then you just set the default width even after saving and re-opening. But if the user has adjusted the scroll bar width even just once, that width will be stored with the document, and the next time the document gets loaded its width should be restored. I hope this makes sense...
This is a Calc issue, therefore changed 'Component' field accordingly.
I still think that this one is a more general Component "Libreoffice"(or even Better: UI"?) issue. Although I think there are more spreadsheets with many sheets than DRAWings with lots of layers, behavior should be the same. BTW, may be for the sake of unifications we should have an "add layer" + Tab for DRAW and Impress? May be that can be integrated into the thoughts here?
(In reply to comment #24) > I still think that this one is a more general Component "Libreoffice"(or even > Better: UI"?) issue. Although I think there are more spreadsheets with many > sheets than DRAWings with lots of layers, behavior should be the same. Not necessarily. Using the same tab class doesn't mean behavior should be the same in all places it is used, the same reason why using the same button doesn't mean clicking on it should do the same thing (it doesn't). > BTW, may be for the sake of unifications we should have an "add layer" + Tab > for DRAW and Impress? May be that can be integrated into the thoughts here? No. Inflating a bug to widen its coverage would have the danger of not covering any corners at all. We should keep each bug report focused on one issue, and one issue only. Besides, showing the plus button is easy, but deciding what to do when the user clicks on it will be up to each application.
Deleted "Easyhack" from summary.
(In reply to comment #18) > Ok, here is a new patch with the problem that Kohei mentioned fixed. > > I tried it out by applying it to a slightly older version because the current > master doesn't build for me (on fedora right now). > Hi Forest - if you're still working on this, want to signal that to others by assigning the bug to yourself?
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
There is no need to fix this anymore since the tabs have now an own row for 4.4.
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting SkillCpp ) [NinjaEdit]
Remove LibreOffice Dev List from CC on EasyHacks (curtailing excessive email to list) [NinjaEdit]