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.
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
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
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.
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 ?
'~' 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'.
Patch submitted #809.
Rishabh's patch - https://gerrit.libreoffice.org/14498
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?
Lets see if we can get some code suggestions for this for you Rishabh.
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
Migrating Whiteboard tags to Keywords: (needsDevEval, topicUI) [NinjaEdit]
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.
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.