Download it now!
Bug 80758 - TOOLBAR: empty values in button names not respected
Summary: TOOLBAR: empty values in button names not respected
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium trivial
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0 target:5.1.2
Keywords: needsDevEval, topicUI
Depends on:
Blocks: Writer-Toolbar-PrintPreview Toolbars-Labels
  Show dependency treegraph
 
Reported: 2014-07-01 14:19 UTC by Yousuf Philips (jay) (retired)
Modified: 2017-10-22 02:03 UTC (History)
4 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 Yousuf Philips (jay) (retired) 2014-07-01 14:19:36 UTC
If i have turned on 'icons & text' for a toolbar and i want a few of them to have labels and others not to have it, this wont work. This doesnt work because if i rename a button to null, it will show the default name, so the workaround i'm presently using is to name it ' '. This would be fine but it adds extra spacing next to the button that isnt needed, especially when limited space is available on the toolbar.
Comment 1 Yousuf Philips (jay) (retired) 2014-07-18 20:01:36 UTC
Steps:
1. Open Writer
2. Click Print Preview button
3. right-click on print preview toolbar
4. select customize
5. in toolbars tab, click 'toolbars' button and select 'icons & text'
6. click 'modify' button while 'previous page' icon is selected and click rename
7. erase the name

Expected: That the name would be erased in the toolbar
Comment 2 Jorendc 2014-07-18 20:16:30 UTC
Reproducible, tested using Mac OSX 10.9 with LibreOffice Version: 4.4.0.0.alpha0+
Build ID: eddd7646d672ea9b0561dacb09da224d098e531e
TinderBox: MacOSX-x86@49-TDF, Branch:master, Time: 2014-07-18_06:13:47
Comment 3 Rishabh 2015-02-14 19:30:41 UTC
why there is a special behavior towards the character "~" ? For example- rename the icon as ~Single Page Preview and the displayed text is only Single Page Preview.
Comment 4 Rishabh 2015-02-14 22:26:57 UTC
I have found a lame fix for the bug. Since the empty values are not respected , if we append "~" to each of values of button name (after renaming) , the renamed text will no longer be empty and the special behavior of "~" towards parsing will make sure that "~" is not visible to the user hence fixing the bug. But I am still apprehensive about the different behavior of "~" and the reason behind it. Any suggestions ?
Comment 5 Yousuf Philips (jay) (retired) 2015-02-14 22:37:08 UTC
'~' is used as an accelerator character in the menu, but is not displayed in the tooltips or text labels of buttons similar to '...'.

As an example, if you look at Insert > Image in Writer, you will see that the 'I' is underlined and the '...' are at the end of the word, the same UNO command is used in the standard toolbar and its tooltip shows just 'Image'.
Comment 6 Rishabh 2015-02-15 06:51:49 UTC
Patch submitted #809.
Comment 7 Yousuf Philips (jay) (retired) 2015-02-16 03:26:04 UTC
Rishabh's patch - https://gerrit.libreoffice.org/14498
Comment 8 Rishabh 2015-03-07 23:08:24 UTC
Is it right to replace empty string as "~" so that it is not actually treated as an empty value (no space is allocated for "~")? Or I should look for some other work around?
Comment 9 Yousuf Philips (jay) (retired) 2015-04-25 15:34:23 UTC
Lets see if we can get some code suggestions for this for you Rishabh.
Comment 10 Norbert Thiebaud 2015-08-16 04:24:22 UTC
Rishabh:

the code that mess with the behavior is in ConvertSvxConfigEntry
where it says:

// If the name has not been changed and the name is the same as
// in the default command to label map then the label can be stored
// as an empty string.
// It will be initialised again later using the command to label map.  

since that is in itself a 'hack' it may be better to build upon that:
in the 'else'
if the GetName() is empty, inject a '~' _there_
that should have the same effect, but at least we keep the crazyness at the same place

To keep the Reset to Default behavior working you need to be able to not set the bStrEdited bool of the associated pEntry in the case ID_DEFAULT_COMMAND

the easiest way to do that is to change the SetName(cosnt OUString& rStr) API
to SetName(cosnt OUString& rStr, bool bUserChanged = true)
{ aLabel = rStr; bStrEdited = bUserChanged; }

and in the ID_DEFAULT_COMMAND case call SetName(aSystemName, false)


Note: completely untested.. just from reading the patch and the code around it.. so reader beware :-D
Comment 11 Robinson Tryon (qubit) 2015-12-13 11:24:24 UTC Comment hidden (obsolete)
Comment 12 Commit Notification 2015-12-18 13:56:28 UTC
Rishabh Kumar committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b2e78fc73363d3ee43e3ee7bc90237d6d048aef7

tdf#80758:empty values in button name not respected

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Commit Notification 2016-03-11 11:01:30 UTC
Rishabh Kumar committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6f3ac91fabe1faa664aecfc535b49ee31fcb9beb&h=libreoffice-5-1

tdf#80758:empty values in button name not respected

It will be available in 5.1.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.