https://bugs.documentfoundation.org/show_bug.cgi?id=43020
V Stuart Foote <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #16 from V Stuart Foote <[email protected]> ---
(In reply to Heiko Tietze from comment #14)
>
> Stuart's statements assume that the help browser is an internal window which
> is wrong, IMHO. At least most programs I know run help in an extra browser
> window. If help content goes internal, which makes sense on the other hand,
> it needs a default look and feel like any other document.
>
> In sum I wouldn't put too much effort in removing an annoyance for a few
> users from a feature that needs to get reworked completely. If we continue
> with the current workflow/UX we should move all sidebar navigation from the
> help form into the Navigator to become consistent.
>
Hmm, not sure I'd agree--adjustments to Navigator is not the issue. The real
*issue* is the behavior of the F1 "built-in" Help as a component of the GUI (a
Writer/Web instance), and to some extent the derived media-wiki "online" help.
So it is not the F1 help for any one pop-up dialog window (Navigator in this
case)--but rather the help article that is being displayed in response to an F1
action (as indexed and linked). I do not find getting F1 help for the Navigator
when it has focus to be incorrect--and when focus is shifted back to the
document the element from the document becomes the F1 target.
So in this case for Navigator linked articles are correct, but the user has the
wrong element active in GUI--a user error, yet they complain. While for the
Tools -> Macros related dialogs the F1 linked articles are what the user needs,
so no complaint. In short the help system is behaving correctly in both
instances.
And yes we could probably send the associated Help articles to a system default
HTML browser rather than our own pop-open viewer, but our existing help viewer
is functional--its search capability is superior to the current web delivered
media-wiki content. And as Oliver notes it is XSLT parsed from associated XHP
the HTML "style" could be adjusted--even brought current with CSS3 and HTML5 if
that facilitates a better match between "built-in" local and "online" web
delivered help.
So the ongoing *issue* is assuring the correct XHP (or its replacement as for
bug 97629) is authored and is indexed/linked to the GUI element we need F1
response for. IMHO we have always done this correctly here and this should be
closed NOTABUG or WONTFIX.
The dialog introduced for bug 103391 now alerts that the "built-in" help is not
installed and that they can read help online. But the help system must still
have correct index and linkage for the element receiving F1 action.
Additionally, we are missing appropriate F1 linked articles for the Sidebar
elements introduced since this bug was submitted, and lately for the new
Notebook Bar elements of MUFFIN--so the help system (built-in and online) has
degraded in that sense.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
