Created attachment 200617 [details] Screenshot of the tabbed notebookbar in Writer, LO 25.8 nightly In the notebookbar tabbed UI mode, the RLT and LTR paragraph directions are placed one above the other - with a "toggle formatting marks", which also uses the pilcrow image, placed right next to the top button. That's confusing and kind of silly.
Yep, the over-under for the controls seems a little awkward, but only for the NB Tabbed UI. NB Tabbed Compact, Single Toolbar, Contextual Single places them side-by-side, while the Grouped and Grouped Compact place them onto the drop list menu of 'Paragraph' controls--top of the lb. Seems like the Tabbed UI Paragraph block could packed a little different to end up with them side-by-side? Andreas, Justin any thought?
(In reply to V Stuart Foote from comment #1) > Seems like the Tabbed UI Paragraph block could packed a little different to > end up with them side-by-side? > > Andreas, Justin any thought? The simplest thing, though not good enough IMO, is to put both directions on the top row, and move the non-printing characters toggle on the bottom row - a super-localized change. But it would be better to actually separate those somewhat. In fact, I'm not sure that the choice of a pilcrow for the non-printing characters is even appropriate, given how much that looks like the paragraph direction buttons.
We discussed the topic in the design meeting. And agree with Eyal's suggestion (In reply to Eyal Rozenberg from comment #2) > ...put both directions on the top row, and move the non-printing characters > toggle on the bottom row Easy hack: Edit per Glade or any text editor ./sw/uiconfig/swriter/ui/notebookbar.ui (no C++ knowledge required) the position of SectionButtom93, SectionButtom130, and Home-ControlCodes1 in SectionButtom81
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/369b726d308270679b792aa21c92bd0b308ec171 tdf#166406 sw nbb: position LTR and RTL side by side 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 Heiko Tietze from comment #3) > > Easy hack: > > Edit per Glade or any text editor ./sw/uiconfig/swriter/ui/notebookbar.ui > (no C++ knowledge required) the position of SectionButtom93, > SectionButtom130, and Home-ControlCodes1 in SectionButtom81 Justin Luth's patch says: > The worst thing to do to a bug > is to mark it as an easy hack. > That just means it will never be solved. > > With the increased push to spotlight the NBB, > these papercuts should be solved ASAP > instead of languishing forever.
(In reply to Eyal Rozenberg from comment #5) > (In reply to Heiko Tietze from comment #3) > > > > Easy hack: > > > > Edit per Glade or any text editor ./sw/uiconfig/swriter/ui/notebookbar.ui > > (no C++ knowledge required) the position of SectionButtom93, > > SectionButtom130, and Home-ControlCodes1 in SectionButtom81 > > Justin Luth's patch says: > > > > The worst thing to do to a bug > > is to mark it as an easy hack. > > That just means it will never be solved. > > > > With the increased push to spotlight the NBB, > > these papercuts should be solved ASAP > > instead of languishing forever. I don't get the point of such statements when we can do a search query like Keywords: easyHack, Whiteboard: target:25.8 Resolution: FIXED and get the result: 44 bugs found. At the moment we have 212 open reports with easyHack, skillCpp, so if the rate of fixing remained the same and no new hacks were to be defined, we would run out of single-hacker tasks within a handful of release cycles. Yes, the turnaround for the hacks should be better, I don't like seeing ancient hacks lingering, but "it will never be solved" is simply wrong as we could instead be running out of hacks without active defining work.
(In reply to Buovjaga from comment #6) Just to clarify - I'm not adopting Justin's position, I was just quoting him.
(In reply to Eyal Rozenberg from comment #7) > (In reply to Buovjaga from comment #6) > > Just to clarify - I'm not adopting Justin's position, I was just quoting him. Sure, I got it. But to add to the previous, nabbing an easy hack away from the pool is fine, if it's considered an urgent issue, there's no need to even argue about it.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/a6091a34e6adcd5780564f55abba40ffd279faa9 tdf#166406 sw nbb: position LTR and RTL side by side It will be available in 25.8.3. 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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-25-8-2": https://git.libreoffice.org/core/commit/3e2e55f53c121a9289b742c55cf578c91fa2bc7a tdf#166406 sw nbb: position LTR and RTL side by side It will be available in 25.8.2. 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.
Thanks, this is better. The fact that we have a paragraph mark right underneath is still somewhat confusing, but out of scope here.