Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||[sidebar]: Extended tooltips shown in normal tooltips mode in Line and Area Decks|
|Product:||General||Reporter:||Rainer Bielefeld <rainerbielefeld_ooo_qa>|
|Component:||ui||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||awf.aoo, issues, rb.henschel|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
|Issue Blocks:||122257, 122364|
Description Rainer Bielefeld 2013-06-01 17:50:20 UTC
Steps how to reproduce with server installation of "AOO 4.0.0-Dev – English UI / German locale [AOO400m2(Build:9701) - Rev. 1485784 Rev.1485289 (2013-05-24)]" on WIN7 Home Premium (64bit)", Common 4.0 Trunk User Profile In a new Draw document draw a smiley shape, expand Line and Area deck, try toolitps and compare with those in Format Toolbar: * Toolbar shows normal Tooltips ☺ * Sidebar shows Extended Tooltips ! (trivial problem) Activate menu 'Tools -> Options -> OOo -> General - Tips - Extendedtips' Now try again * Toolbar shows Extended Tooltips ☺ * Sidebar shows NO item related Tooltips, only the general sidebar related info ! (ugly problem) I think best solution would be to show the same element related Tooltips a the Toolbar, though the situation in the sidebar is mor similar to the situation in the Format dialogs (where no to tooltips are shown, may be because the headings about the dropdowns / spinbuttons already explain for what function they are)
Comment 1 Regina Henschel 2013-06-01 18:37:22 UTC
Hi Rainer, are you sure the extended tooltip option is unchecked in the first case? I cannot reproduce the problem with my own build. The second case has this reason: These helpIDs used in the sidebar do not have associated texts in the help files. Therefore the extended tip of the underlying sidebar window is shown. I'm working to correct that, but it will likely not be finished until release. You need to remove the newly introduced helpIDs and use the text ".uno:command" (with the right command), if the control acts exactly like that in the toolbar, at least from a user point of view. The implementation might be different, for example in case of uno.CharFontName.
Comment 2 Rainer Bielefeld 2013-06-01 19:31:34 UTC
> are you sure the extended tooltip option is unchecked ... @Regina: Yes, I switched between ET on/off several times. But I only see that with that particular build, Rev. 1484333. Rev.1483903 was ok. Might have been a slip with Rev. 1485784 Rev.1485289? I will test with a new build tomorrow
Comment 3 Regina Henschel 2013-06-01 19:47:59 UTC
I have not tested a German version and cannot install the current buildbot version (see mail in dev). Have you tested it with an English version too?
Comment 4 Rainer Bielefeld 2013-06-02 09:09:49 UTC
@Regina: It was the English version, only Localization (decimal separator, currency, ...) was German. Currently I can't test with latest versions because of "Bug 122435 - CRASH at first launch"
Comment 5 Andre 2013-06-03 09:26:24 UTC
The reasons for this behavior all come from the fact that the Symphony property panels do not use the toolbar controllers that the AOO toolbars use. Instead the panels implement the functionality of every toolbar button themselves. They bring their own help text and do not reuse the existing help text that is bound to slots/commands. In some cases that is a positive thing. The extended tooltips make sense because panels show more contextual information than toolbars. Take for example the control for modifying the line width in the "Line" property panel. The panel is called "Line", the control is labeled "Width". The default tooltip text "Line Width" would not add any new information. "Select the width of the line" is not much better but at least does not simply repeat title and label. For the extended tooltips the situation is different. The panels don't bring their own help text. Like for the normal tooltip, there is no reuse of existing extended help text from slots/commands. The fallback is the general help text for sidebar panels. There are several ways to improve this: 1. The best solution but also the most time consuming would be to drop the duplicated code and use the AOO toolbar controllers. That would solve not only the tooltips but other problems with handling UNO commands as well. The only downside of this approach would be that the standard tooltips would be too short. In our example above it would be "Line Width" and not be very helpful. 2. Add UNO command URLs to the toolbar button descriptions in the resource files. I think this is basically what Regina has proposed above. This is a requisite for 1. 3. Add the UNO command URLs to the button controllers in the panel implementation.
Comment 6 SVN Robot 2013-06-03 12:42:54 UTC
"af" committed SVN revision 1488976 into trunk: 122433: The sidebar ControllerItem can now give access to the extended help t...
Comment 7 Andre 2013-06-03 14:23:41 UTC
I have changed the sidebar ControllerItem so that it gives access to the extended help text of uno commands. This should take care of the "Text" property panel. For most controls in other panels more work is necessary: a) Add the UNO command URL to the initialization of ControllerItems objects in constructors of panel implementations. I have to check whether that information could be supplied by 2) (see earlier comment). b) Add calls to ControllerItem.SetupToolBoxItem() for all relevant panel controls.
Comment 8 SVN Robot 2013-06-04 07:15:18 UTC
"hdu" committed SVN revision 1489303 into trunk: #i122433# fix build breaker: invalid use of incomplete type 'struct Help'
Comment 9 Andre 2013-06-04 08:51:55 UTC
I just experimented with the Calc "Alignment" panel with mixed results. For the four buttons for horizontal alignment there exist different UNO commands. Adding those to the SRC file (option 2, see above) results in help texts taken from the command descriptions. No such luck with the three button for vertical alignment. There are no individual commands. Using the general command ".uno:VerticalAlignment" did not lead to a display of a specific help text. Reason for this is probably that no such text is defined in helpcontent2/. The third experiment had the "Wrap text" check box as target. There exists a UNO commmand for it but adding a line Command = ".uno:WrapText" is not a valid syntax for CheckBox entries. Looks like only toolbox items understand this. Tried to use ".uno:WrapText" as HelpId instead. This is accepted by the resource compiler but does not show any control specific help text. So, the precedence between helpid and command of one control and helpids of a control and its child(ren) is unclear to me. Help text seems to be missing for some controls. I don't think that this can be fixed for 4.0.
Comment 10 Andre 2013-06-17 12:02:33 UTC
Setting this as blocker of bug 122364 so that it does not not get lost.