Bug 142704 - %PRODUCTNAME shown in extended tips
Summary: %PRODUCTNAME shown in extended tips
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.3.2 release
Hardware: All All
: low minor
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.3.0 target:7.2.3
Keywords:
Depends on:
Blocks: GTK3
  Show dependency treegraph
 
Reported: 2021-06-07 17:19 UTC by J22Gim
Modified: 2022-01-24 16:48 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description J22Gim 2021-06-07 17:19:20 UTC
Description:
When using Track Changes in Writer, I want to have my own color. This means, when I add text I need it to show in a given color. BUT, when another reviewers makes changes, I want it to be a different color.
There is a set of options for this in Options->LibreOffice Writer->Changes
When I hover the cursor over the options (see image below) I see the message "...When you choose the condition "By author" in the list, the color is automatically determined by %PRODUCTNAME, then modified to match to the author of each change"

1) So I want to explore this a bit more, what is (and where can I read about) the paramter called '%PRODUCTNAME'?

2) is there a way to set eg RED for myself and "automatic" for the rest of the reviewers?

Thanks for this amazing software!

https://i.ibb.co/Cb9W1xM/2021-06-07-13-10.png

Steps to Reproduce:
1. open a writer document with any text
2. activate the track changes option
3. make a change in the document (eg insert any word)
4. you'll see with a given (automatic color)
5. but that color in particular is not convenient (for whatever reason -in my case it is very close my document background color) so you need to have another color assigned to you, while keeping the "different authors different color" idea

Actual Results:
You can only choose between color "by author" (ie a color for each user who makes changes in the document) or one color for (all) any author (ie if you choose RED then changes by ANY user will always have the same chosen color, eg. RED)

Expected Results:
I would like to chose a color for my current user (myself) but still have the changes made by other in different colors (one color per user). So the idea would be "one color per user, but please let me chose my user's color".


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.3.2 / LibreOffice Community
Build ID: 10(Build:2)
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 1:7.1.3~rc2-0ubuntu0.20.04.1~lo1
Calc: threaded
Comment 1 Xisco Faulí 2021-06-07 17:56:37 UTC
%PRODUCTNAME is just a variable that should be replaced by 'LibreOffice', why it's not replaced, it's a mystery to me
Comment 2 Heiko Tietze 2021-06-08 06:37:23 UTC
1) Apparently this extended tooltip was never shown correctly. The variable needs to be replaced per code. Add something like .replaceAll("%PRODUCTNAME", utl::ConfigManager::getProductName()) to sw/source/ui/config/optpage.cxx at SwRedlineOptionsTabPage() for m_xInsertColorLB, m_xDeletedColorLB, and m_xChangedColorLB with get/set_accessible_description.

Or just drop the %PRODUCTNAME from the label in sw/uiconfig/swriter/ui/optredlinepage.ui

"You can also choose a color to display each type of recorded change. When you choose the condition "By author" in the list, the color is automatically determined, then modified to match to the author of each change."


2) Seems we show redlines with colors depending on the author.
Comment 3 Olivier Hallot 2021-06-10 14:26:11 UTC
Cannot confirm in

Version: 7.2.0.0.alpha1+ / LibreOffice Community
Build ID: 7f49c4eea51c6c84ee7adacd5ba45e1e0fc4c1f7
CPU threads: 16; OS: Linux 5.11; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.2.0.0.alpha1+ / LibreOffice Community
Build ID: 7f49c4eea51c6c84ee7adacd5ba45e1e0fc4c1f7
CPU threads: 16; OS: Linux 5.11; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.1.4.2 / LibreOffice Community
Build ID: a529a4fab45b75fefc5b6226684193eb000654f6
CPU threads: 16; OS: Linux 5.11; UI render: default; VCL: kf5
Locale: pt-BR (en_US.UTF-8); UI: pt-BR
Calc: threaded
Comment 4 J22Gim 2021-09-21 21:33:35 UTC
Still the same, see
https://ibb.co/9rZQn3B

Version: 7.2.1.2 / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 1:7.2.1~rc2-0ubuntu0.20.04.1~lo3
Calc: threaded
Comment 5 Heiko Tietze 2021-09-22 05:12:21 UTC
Ross, are you interested?
Comment 6 Ross Johnson 2021-09-22 13:30:30 UTC
In relation to (1) %PRODUCTNAME:

Cannot confirm. That is, the product name is present and correct in:

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 2bcce8a815db0ece91d43854ed2af1d0e71b5448
CPU threads: 12; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: en-AU (en_AU); UI: en-US
Calc: threaded

And

Version: 7.2.1.2 (x64) / LibreOffice Community
Build ID: 87b77fad49947c1441b67c559c339af8f3517e22
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-AU (en_AU); UI: en-US
Calc: threaded

It does seem a little odd to have the product name in those hot tips, although with documents being shared between different vendor products it may be relevant.

In relation to (2): probably beyond me at this stage, Heiko.
Comment 7 Heiko Tietze 2021-09-22 14:22:32 UTC
(In reply to Olivier Hallot from comment #3)
> Cannot confirm in
> Version: 7.2.0.0.alpha1+ / LibreOffice Community

(In reply to Ross Johnson from comment #6)
> Cannot confirm. That is, the product name is present and correct in:

Me neither. Seems to be a question to the Ubuntu packagers. Björn, who is doing this job these days?
Comment 8 Buovjaga 2021-09-22 14:52:44 UTC
Not an Ubuntu problem, but a gtk3 problem. Anyway, the one doing the job at Canonical these days is Heather Ellsworth.

Arch Linux 64-bit
Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 504d2209e47ffeb223b2bcde9fc24e828cc5cd6f
CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: gtk3
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 21 September 2021
Comment 9 Heiko Tietze 2021-09-22 15:13:03 UTC
(In reply to Buovjaga from comment #8)
> Not an Ubuntu problem, but a gtk3 problem.

True, can confirming with 

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 70860345da26c5c0303e01f9d6fb93276b38aea1
CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: gtk3
Locale: de-DE (en_US.UTF-8); UI: en-US
Calc: threaded

but not when using kf5 (which doesn't wrap nicely, however).
Comment 10 Caolán McNamara 2021-09-22 15:22:57 UTC
Yeah, we're not substituting PRODUCTNAME in accessibilty descriptions under gtk.
Comment 11 Commit Notification 2021-09-22 18:20:31 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/c9b19f69e658f1114f1b8fc0ae62b6edd6d33e3f

Resolves: tdf#142704 %PRODUCTNAME shown in gtk3 extended tips

It will be available in 7.3.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.
Comment 12 Caolán McNamara 2021-09-22 18:21:13 UTC
Done in trunk, backport to 7-2 in gerrit. 7.1 is best to leave alone at this stage IMO
Comment 13 Commit Notification 2021-09-23 03:26:56 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/e163000fdb525b93d639aa9886365745439b2132

Resolves: tdf#142704 %PRODUCTNAME shown in gtk3 extended tips

It will be available in 7.2.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.
Comment 14 Commit Notification 2021-09-23 10:05:24 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/aeda71b3cf3aa4393b8367437be29c1722f97d4d

Related: tdf#142704 ReadStringHook may not be set in testing configurations

It will be available in 7.3.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.
Comment 15 Buovjaga 2021-09-23 10:52:00 UTC
Verified, thanks

Arch Linux 64-bit
Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: aeda71b3cf3aa4393b8367437be29c1722f97d4d
CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: gtk3
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 23 September 2021
Comment 16 Commit Notification 2021-09-24 09:34:17 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/7f1ded9d814f6558ae9b2e6e85063c355950200e

Related: tdf#142704 ReadStringHook may not be set in testing configurations

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