Bug 154296 - Lost ability to customize Notebook Bar UI --element checkboxes have no effect
Summary: Lost ability to customize Notebook Bar UI --element checkboxes have no effect
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.5.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Jim Raykowski
URL:
Whiteboard: target:7.6.0 target:7.5.3
Keywords: bibisected, bisected, regression
: 153114 (view as bug list)
Depends on:
Blocks: Customise-Dialog
  Show dependency treegraph
 
Reported: 2023-03-20 20:07 UTC by V Stuart Foote
Modified: 2023-10-12 08:22 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
20230326 nightly with patch, still not correctly refreshing NB Tabbed Compact (290.40 KB, image/gif)
2023-03-26 22:06 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2023-03-20 20:07:39 UTC
Uisng Tools -> Customize... dialog and its Notebookbar tab, unchecking widget objects is not removing them from the respective tab.

The "customization" does not apply when in one of the UI modes, nor when set while in Standard and then toggling to the mode.


Version: 7.5.1.2 (X86_64) / LibreOffice Community
Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 1 V Stuart Foote 2023-03-20 20:13:16 UTC
Further to Sumit C's GSOC 2019 work and Andreas's follow-on work on bug 101513 theability to customize the Notebookbar MUFFIN assemblages has slipped.

@ady's note copied from bug 140557
<snip>
Although this might be tangential to the issues already reported here, I must add an important factor regarding the Tabbed Toolbar UI.

Until LO 7.4.6.2, we can go to menu Tools > Customize > Notebookbar and then edit the toolbar’s items.

But in:
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: b5c3a7502f7ff6ccf0f829c1f3a2ba50b8584c41
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-US (es_AR); UI: en-US
Calc: CL threaded
Built 2023-03-19

...any customization is not actually performed.

To be clear, this problem did not start on that version/date, but earlier. I haven't tested LO 7.5 in this regard.
</snip>
Comment 2 Buovjaga 2023-03-23 08:53:05 UTC
*** Bug 153114 has been marked as a duplicate of this bug. ***
Comment 3 Buovjaga 2023-03-23 09:01:10 UTC
Bibisected with linux-64-7.5 to e79741488cc740f49ebd4426c40b45e7139ff663
tdf#112237 Show tooltips for Assigned Commands in Customize dialog
Comment 4 Jim Raykowski 2023-03-23 20:57:12 UTC
Here is effort to fix the regression and keep the tool tip:
https://gerrit.libreoffice.org/c/core/+/149470
Comment 5 Jim Raykowski 2023-03-25 08:07:25 UTC
I mistakenly merged the patch under bug 154294.
Comment 6 ady 2023-03-25 09:00:27 UTC
Although I have not tested the patch yet... IMHO this should be set to target 7.5 too, not just 7.6 as it is now by:

https://git.libreoffice.org/core/commit/48b7cf3182cc8fb0b728860f9cbb489390074101

https://gerrit.libreoffice.org/c/core/+/149470
Comment 7 V Stuart Foote 2023-03-25 15:03:00 UTC
(In reply to ady from comment #6)
When work is done it is normally developed against the git source master, so the target here of 7.6.0 is correct. Next step would be to "backport" aka "cherry pick" into a release build (e.g. 7.5 branch and landing in 7.5.3 or .4) and requires specific additional actions and more robust review to avoid additional regression.

Expectation is for folks to pull either a nightly build of master including the patch or roll their own, and test that it in fact corrects the issue.

But yes the backport is needed to clear the regression in the 7.5 branch.
Comment 8 ady 2023-03-26 06:25:03 UTC
(In reply to V Stuart Foote from comment #7)
> (In reply to ady from comment #6)
> When work is done it is normally developed against the git source master, so
> the target here of 7.6.0 is correct. Next step would be to "backport" aka
> "cherry pick" into a release build (e.g. 7.5 branch and landing in 7.5.3 or
> .4) and requires specific additional actions and more robust review to avoid
> additional regression.

I thought my comment 6 was clear enough for this case and for the expected target readers. Perhaps it wasn’t, so let's clarify then (FWIW).

The Whiteboard field was not specified, so there was no target for this report. That's why I said that the target was specified by the commit+gerrit links.

Since the automatic comment for the pushed commit was not included in this report (because of the typo mistake mentioned in comment 5), and since the report was already set as fixed, I thought I should post the relevant links (together) and the mentioned target (that was not yet set in Whiteboard) and to hint that version 7.5 should still be considered IMHO, instead of closing this report as fixed (prematurely).

Additionally, I wanted to make clear that my comment 6 didn't mean that I had already tested the patch, so I mentioned that fact explicitly, in order to avoid any potential misunderstanding.

> Expectation is for folks to pull either a nightly build of master including
> the patch or roll their own, and test that it in fact corrects the issue.

And now (when there is such new build available) I have. Solved as of:
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 67bb7f71b785d3d831ffaa47262b6cbd84e71c42
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-US (es_AR); UI: en-US
Calc: threaded
Built 2023-03-26

> 
> But yes the backport is needed to clear the regression in the 7.5 branch.

Now that target 7.6 was confirmed as fixed and the report has been set as reopened, someone qualified should add target 7.5 to Whiteboard and hopefully Jim will post here a gerrit link for evaluation against LO 7.5.
Comment 9 Jim Raykowski 2023-03-26 21:30:50 UTC
(In reply to ady from comment #8)
> Now that target 7.6 was confirmed as fixed
I resolved it as fixed (in master) to indicate a fix for this bug is checked into the tree and that I have tested it but I don't see that anyone has confirmed (verified) the patch.

QA usually does the backporting. Perhaps if this patch is confirmed to fix this bug they will kindly do so.

https://bugs.documentfoundation.org/page.cgi?id=fields.html#bug_status
Comment 10 V Stuart Foote 2023-03-26 21:59:47 UTC Comment hidden (invalid, obsolete)
Comment 11 V Stuart Foote 2023-03-26 22:06:17 UTC Comment hidden (invalid, obsolete)
Comment 12 V Stuart Foote 2023-03-26 22:11:59 UTC
(In reply to V Stuart Foote from comment #11)
Opps sorry, wrong issue! And in fact with 
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 67bb7f71b785d3d831ffaa47262b6cbd84e71c42
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

The Tools -> Customize 'Notebook Bar' tab fully functional again.

It does need a backport to 7.5, Stephane can you get that going?
Comment 13 Commit Notification 2023-03-27 09:20:44 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "libreoffice-7-5":

https://git.libreoffice.org/core/commit/6524b8efecaab39486f54d8b95a4e124d1482b08

tdf#154296 Fix customize notebook bar regression

It will be available in 7.5.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.