Created attachment 194409 [details] tabbed interface misposition Hi, on Mac OS, when using the tabbed interface, the buttons do not appear in the right place, they are shifted to the right
Thanks for the report. This issue is already tracked in bug 127610, marking as duplicate. *** This bug has been marked as a duplicate of bug 127610 ***
Changing to NEW per discussion in bug 127610
Summary adjusted to address remaining issue after resolution of bug 127610
Hi there, This issue still persists, also in v25 - using the lates LO release on latest MacOS ARM on an MacBook Pro M1 Pro. The tabbed menus are too far on the right and "collide" with the decoration of the toolbar below. No fix in sight? Cheers Martin
(In reply to Martin W from comment #4) > > The tabbed menus are too far on the right and "collide" with the decoration > of the toolbar below. > Actually, no. The tab items are correctly calculated and positioned relative to the shortcuts on the bar. The remaining issue is the underlaying decoration, call it "the cut out" notch, in the controls bar is not using the same offsets from left and right. And it remains centered for the calculated width of the tabs.
OK, that may be right. Still, it looks pretty ugly. Plus, the decoration and the quick access icons in the top left corner (open, save, print, undo etc) somehow don't work together well. Sometimes you can see the (darker grey) decoration background, sometimes you see the lighter grey "icon background", depending on if you have hovered with the mouse cursor over one of those icons or not. Kind of surprising that this problem has been around for years, apparently.
*** Bug 165691 has been marked as a duplicate of this bug. ***
*** Bug 165893 has been marked as a duplicate of this bug. ***
*** Bug 166719 has been marked as a duplicate of this bug. ***
*** Bug 125511 has been marked as a duplicate of this bug. ***
*** Bug 166982 has been marked as a duplicate of this bug. ***
*** Bug 167037 has been marked as a duplicate of this bug. ***
Hi Patrick, do you have any desire/cycles to go ahead and tweak this visual glitch on the Notebook Bar Tabbed UI? Or alternatively you could provide code hint(s) and set it as an easy hack, and see if another macOS dev picks it up.
Created attachment 201339 [details] Snapshot using debug patch in comment I don't have much spare time anymore and I am not familiar with any of the application UI layout code. But I was able to break on the one of the native "draw tab item" calls in a debugger to figure out what code is drawing the top half of the notebook bar (i.e. the native tab area). Found some code that was setting the height of the section to 28 pixels so I increased it to 100 in the debug patch at the end of this comment. As shown in my snapshot, I was able to increase the height of the top half and that, in turn, appears to push the bottom half (i.e. the notebookbar's button area) but the two buttons on each end of the bottom half are still taller than the middle buttons. Unfortunately, I wasn't able to find the code that lays out the bottom half's buttons but it sure looks like the height of the bottom half needs to be increased to the height of the middle buttons. But AFAICT, the end buttons are taller than expected and don't fit within the bottom half's bounds and so the end buttons bottom edge are align to the bottom edge of the bottom half and the top edge "spills over" into the top half's area. I think the original developer's at Collabora of the notebookbar code probably help. My guess is that the end buttons fit within the bottom half on Windows and Linux but are slightly larger on macOS and the code doesn't handle that: diff --git a/vcl/source/control/tabctrl.cxx b/vcl/source/control/tabctrl.cxx index 1d6ffa3a1958..651e81e25896 100644 --- a/vcl/source/control/tabctrl.cxx +++ b/vcl/source/control/tabctrl.cxx @@ -2349,8 +2349,13 @@ bool NotebookbarTabControlBase::ImplPlaceTabs( tools::Long nWidth ) if( nFullWidth < nMaxWidth && !item.maText.isEmpty() && aSize.getWidth() < 100) aSize.setWidth( 100 ); +#if MACOSX + if( !item.maText.isEmpty() && aSize.getHeight() < 100 ) + aSize.setHeight( 100 ); +#else if( !item.maText.isEmpty() && aSize.getHeight() < 28 ) aSize.setHeight( 28 ); +#endif tools::Rectangle aNewRect( Point( nX, nY ), aSize ); if ( mbSmallInvalidate && (item.maRect != aNewRect) ) I wasn't able to find the code that handles the toolbar area just below the native tab area (I don't have much free time to work on LibreOffice these days so I ran out of time), but what
Created attachment 201341 [details] Snapshot with loading of notebook bar configuration file disabled OK. After some random poking around the code, I think that I might have narrowed down what might be causing this bug. I was able to suppress loading of the notebook bar's configuration file using the debug patch below. As shown in the attached snapshot, only the notebook bar's background color is drawn and the height is much less. I didn't see anything about sizing in the notebookbar.ui file for Calc so I am guessing that there is some bug in vcl's automatic layout code which I am unfamiliar with: diff --git a/vcl/source/control/notebookbar.cxx b/vcl/source/control/notebookbar.cxx index 6f143a867dcf..be4e0cd3fe86 100644 --- a/vcl/source/control/notebookbar.cxx +++ b/vcl/source/control/notebookbar.cxx @@ -96,6 +96,11 @@ NotebookBar::NotebookBar(Window* pParent, const OUString& rID, const OUString& r } else { +(void)sUIDir; +(void)rUIXMLDescription; +(void)rID; +(void)aNotebookBarAddonsItem; +/* m_pUIBuilder.reset( new VclBuilder(this, sUIDir, rUIXMLDescription, rID, rFrame, true, &aNotebookBarAddonsItem)); @@ -116,6 +121,7 @@ NotebookBar::NotebookBar(Window* pParent, const OUString& rID, const OUString& r i++; } while( pContextContainer != nullptr ); +*/ } UpdateBackground();
The vertical "mis-size" is annoying, but isn't the horizontal difference in positioning the tab bar against its "notch" on the background what folks most comment on? The h-size for to notch seems to match the h-size of the tabs, just not aligned. @Caolán, any thoughts?
*** Bug 167235 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from comment #16) > The vertical "mis-size" is annoying, but isn't the horizontal difference in > positioning the tab bar against its "notch" on the background what folks > most comment on? The h-size for to notch seems to match the h-size of the > tabs, just not aligned. > > @Caolán, any thoughts? Don't know if the "notch" is intentional, but I don't see how the tab items could fit in it without being obscured by some of the buttons to the left of the tab items. As shown in attachment #201339 [details], there is very little spare horizontal space in the tab items area when a window is fairly normal size on my 14" MacBook Pro screen. Plus, the to border to the right of the end of the notch draws over hamburger icon in the tab items area so I still think the problem is that the ends of the notch are unexpected too tall and bleed into the tab items area above it.
(In reply to Patrick (volunteer) from comment #18) > (In reply to V Stuart Foote from comment #16) > > The vertical "mis-size" is annoying, but isn't the horizontal difference in > > positioning the tab bar against its "notch" on the background what folks > > most comment on? The h-size for to notch seems to match the h-size of the > > tabs, just not aligned. > > > > @Caolán, any thoughts? > > Don't know if the "notch" is intentional, but I don't see how the tab items > could fit in it without being obscured by some of the buttons to the left of > the tab items. As shown in attachment #201339 [details], there is very > little spare horizontal space in the tab items area when a window is fairly > normal size on my 14" MacBook Pro screen. > > Plus, the to border to the right of the end of the notch draws over > hamburger icon in the tab items area so I still think the problem is that > the ends of the notch are unexpected too tall and bleed into the tab items > area above it. Right. Except the h-width of the notch looks to be calculated the same as the tab bar h-width. Just centered in app frame. If it is calculated but then positioned centered, imagine its position could get the same h-offset as needed for the buttons that the tab bar gets (what you'd tweaked), rather than simply being centered. But if it can not be positioned, only centered, then eliminating the notch and extra height on the ends allowing it to close up with the tab bar would also look OK.