Created attachment 112980 [details] Incorrect tooltip in Export to PDF dialog box Incorrect tooltip for "View PDF after Export" checkbox in PDF Options dialog box in "File/Export to PDF". See attachment.
I don't have this tooltip in LO 4.4.0.3, Win 8.1.
Me neither. Win 7 Pro 64-bit, LibO Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Version: 4.5.0.0.alpha0+ Build ID: 309574394bd4ae3e9e10e5ff0d64bdd7bbbc8b83 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-29_23:44:46
Confirmed. But only if "Extended-tips" are enabled (Tools -> Options -> General: Help) On Windows 7 sp1, 64-bit en-US with Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Locale: en_US as well as Version: 4.3.6.2 Build ID: d50a87b2e514536ed401c18000dad4660b6a169e and the en-US local help installed. Looking at the source http://opengrok.libreoffice.org/xref/core/filter/uiconfig/ui/pdfgeneralpage.ui http://opengrok.libreoffice.org/xref/help/source/text/shared/01/ref_pdf_export.xhp Suspect this to be a residual of the conversion to GTK UI. There is no tool-tip assigned to the widget in the .ui configuration. But with "Extended-tips" active, the displayed tip--"Exports all defined print ranges. If no print range is defined, exports the entire document."--is drawn from Help files and is assigned to the All paragraph. But for some reason the extended-tip looks to be incorrectly assigned at multiple elements/locations on the dialog--where mouse over detects a component, but no tool-tip/extended tool-tip is defined. It is activating this extended-tip incorrectly. Not clear to me the assignment mechanism of these extended-tips when Local Help is installed--but at least for this Dialog it has gone wonky. @Caolán?
I think the bug is actually in the helpcompiler The help for this page is in helpcontent2/source/text/shared/01/ref_pdf_export.xhp and we look at the hunk of code of.... <bookmark xml-lang="en-US" branch="hid/filter/ui/pdfgeneralpage/range" id="bm_id2618793" localize="false"/> <bookmark xml-lang="en-US" branch="hid/filter/ui/pdfgeneralpage/pages" id="bm_id2676778" localize="false"/> <paragraph xml-lang="en-US" id="hd_id3154673" role="heading" level="3" l10n="CHG" oldref="6">Pages</paragraph> <paragraph xml-lang="en-US" id="par_id3147571" role="paragraph" l10n="U" oldref="7"><ahelp hid="filter/ui/pdfgeneralpage/pages">Exports the pages you type in the box.</ahelp></paragraph> then in the source of helpcompiler/source/HelpCompiler.cxx myparser::traverse the "hid" attribute of the ahelp tag is apparently ignored and instead it assigns the ahelp extended tip to the contents of extendedHelpText which is "every bookmark seen to date with a branch that starts with 'hid'" and then empties that list. so that's a complete horror if I'm reading this right
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cc464d1a94172ca28e9d962fa6e1ffadabc1dc79 Resolves: fdo#88970 fix Incorrect Extended-tips with dodgy ahelp tags It will be available in 4.5.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.
Oops, I forgot to mention that I have installed the US Local Help and activated the Extended Tips to help me with the learning curve to this version of LO. I run Windows 7 32 bit. Could the cause of my report on this bug be similar to the one I reported in bug 88971? Though the technical explanation provided by Caolan MacNamara and Stuart Foote here sounds fairly sophisticated to me. However, thank's a lot to both of you, Andy and Beluga too, for following up my report and finally for making a fix available in the next patch. I will try the Daily Builds as recommended.
*** Bug 88971 has been marked as a duplicate of this bug. ***
On Windows 7 sp1, 64-bit en-US with Version: 4.5.0.0.alpha0+ Build ID: 99c00b090533da9818444be2831b8da0e713e5f9 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-02-04_06:38:53 Locale: en_US with en-US local help installed. Reopening...not quite right yet. The general case is better now. But we now seem to lost some of the extended-tips. Easy example (tool tips and extended tool-tips set on) Writer: open insert section dialog Insert -> Section <Shift>+F1 to activate the extended tool-tip based help. Point at DDE, or Protect check box. So, while the breakage reported here and in bug 88071 is resolved (i.e. the "Type a name for new section" is no longer incorrectly shown a multiple locations) no tool-tip is now revealed for these elements. Although they do have help items defined in http://opengrok.libreoffice.org/xref/help/source/text/swriter/01/04020100.xhp
s/bug 88071/bug 88971/
http://cgit.freedesktop.org/libreoffice/help/commit/?id=1ff0bd652428824fdbd3a1650c8ec0c8ead4af4a fixes the section page anyway
(In reply to Caolán McNamara from comment #10) >... fixes the section page anyway Caolán, *, Thanks, will check it out next TB build cycle. Beyond that, does the entire UI now need to be scanned looking for these breakages in help (tooltips/extended tips)? Happy to do it by hand if need be, but could that review of the help system be done programmatically in some fashion?
I've tweaked the helpcompiler tool to warn about hid arrangements in the help that don't make sense. So looking for "helpcompiler" warnings in the build output will help. I'd love to move all the extended help out of "help" and into the widgets as a11y descriptions, but I'm afraid to have the translators shout at me again about disrupting a million strings.
(In reply to Caolán McNamara from comment #12) > I've tweaked the helpcompiler tool to warn about hid arrangements in the > help that don't make sense. So looking for "helpcompiler" warnings in the > build output will help. > > I'd love to move all the extended help out of "help" and into the widgets as > a11y descriptions, but I'm afraid to have the translators shout at me again > about disrupting a million strings. Hi, could you discuss this with Moggi and Kendy, in the move to port the help to the wiki the project was: - split the project in 3 parts: * UI as we have it today * Extended tooltips - currently in help files, are extracted and get its own .po project * Help content, managed in the wiki So extracting extended tooltips was something wanted, but yes, if we could avoid to have the translation of the tooltips to do again, that's a huge work. Sophie
@cloph, *, To take advantage of Caolán's enhanced helpcompiler warnings, would it be possible to post some form of the build logs for the help system. At least for a few build cycles so we can see how bad this is going to be. Just the Tinderboxes currently rolling the localhelp (en-US), maybe TB@62 and TB@46?
*** Bug 80974 has been marked as a duplicate of this bug. ***