Hi Volga,

Can you send a screenshot of your regular toolbars and the notebookbar, as it has looked fine for me since bug 103235 was fixed.

Note: Notebookbar will have a single color similar to the menubar and wont have a gradient like toolbars.

Created attachment 133779 [details]
Sample

OK Yousuf,

I send a file to you to describe which areas on Notebookbar mode should be looks like.

(In reply to Volga from comment #2)
> Created attachment 133779 [details]
> Sample

Thanks for the screenshot, but i'm not able to reproduce this on Linux or Windows in 5.5 daily. What version are you running?

@Stuart, @Buovjaga, @Xisco: Can either of you guys repo this?

(In reply to Yousuf Philips (jay) from comment #3)
> Thanks for the screenshot, but i'm not able to reproduce this on Linux or
> Windows in 5.5 daily. What version are you running?
Oh, I forgot to report I just run LibO 5.4 beta1 on Windows 10.

(In reply to Volga from comment #0)
> Description:
> The default foreground color used on the Notebookbar looks lighter than the
> color used in toolbar, but the default background color looks darker than
> toolbar.

On Windows 10 Pro 64-bit en-US with
Version: 5.5.0.0.alpha0+ (x64)
Build ID: 6517fd2107a5a71290afad8850da0eab51519bc6
CPU threads: 8; OS: Windows 6.19; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-06-01_23:17:13
Locale: en-US (en_US); Calc: CL

The "foreground" color for an active tab _is_ lighter than the inactive tabs. While the inactive tabs have the same gray as used for the the toolbars. But I think both of those are implemented correctly.

As an aside, checking with a theme applied (Tools -> Options -> Personalization) would expect the "foreground" of the active tab would pick up a color when applying a theme--as is the tabbed Notebookbar does not style well when applying a theme.

Regards the separation of the menu bar (when active) from the Notebookbar, agree with Volga that the frame border is not needed and is visually jarring. We don't have a widget border separating the Standard toolbar from the Menu bar in default modes--so I think the decoration is not needed above the notebook bar modes when the menu bar is enabled.

Unfortunately, the "Groupedbar Full" and "Groupedbar Compact" modes will not toggle the menu bar active (bug 107158) so can not check border appearance and offset of the Menu bar in those modes. But if present it should be removed there as well. Think that would be an issue on its own.

(In reply to V Stuart Foote from comment #5)
> The "foreground" color for an active tab _is_ lighter than the inactive
> tabs. While the inactive tabs have the same gray as used for the the
> toolbars. But I think both of those are implemented correctly.
Now I agree with you, but the default foreground for active tab looks a bit dull, is it possible to implement gradient effect in there?
 
> Regards the separation of the menu bar (when active) from the Notebookbar,
> agree with Volga that the frame border is not needed and is visually
> jarring. We don't have a widget border separating the Standard toolbar from
> the Menu bar in default modes--so I think the decoration is not needed above
> the notebook bar modes when the menu bar is enabled.
Yeah that’s right. BTW I found menu button (three dashes) on the notebookbar not joined with tab when I see attachment 133779 [details] again.

Created attachment 145892 [details]
Theming

Hi,

From my point of view the theming is ok in 6.2 (alpha 1) My only suggestion would be to have the right menu button without boarders.

Created attachment 145897 [details]
Dark Personas Theme

Tabbed toolbar didn't work with dark personas theme.

*** Bug 106485 has been marked as a duplicate of this bug. ***

Screenshot from bug 123827 https://bug-attachments.documentfoundation.org/attachment.cgi?id=149701 and bug 124851 https://bug-attachments.documentfoundation.org/attachment.cgi?id=150889

*** Bug 123827 has been marked as a duplicate of this bug. ***

*** Bug 124851 has been marked as a duplicate of this bug. ***

How is this different from bug 121877? Should it be a duplicate?

Dear Volga,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug