> My understanding was that the ghelp link should point to
> /usr/share/gnome/help rather than requiring an omf file. There are
> several documents we install which don't have omf files... Is that
> seriously not going to be supported anymore?
Not having omf files has several drawbacks:
1. The docs won't appear in the TOC (not a concern for Ubuntu)
More importantly: The documents won't be searched (using basic search). This
has never worked (and probably never will).
There are several other problems (involving installing new packages and
using the default libgnome). These problems (IMO) are severe enough
that solving them isn't worth while.
We [1] are trying to move away from using ghelp: URIs in general for
various reasons involving it not being a registered protocol, as well as
the above. Instead, the use of identifiers will be encouraged (e.g.
sending a dbus signal asking for the identifier "org.gnome.epiphany").
There are a couple of options at this point:
a) the omf's can be created.
b) I can cook up a (quick and dirty) yelp patch to check the existance of the
file path if the current ghelp method falls through
Each has an advantage and a disadvantage:
a) + The correct solution
- Requires a (small) bit of work for translators
b) + Quick and easy (for people that aren't me)
- Docs still won't appear in search results
The work for translators isn't too much as only the title and URI will
need translated. The description can be basically anything (as it's
never shown), but adding the omf's to the build system may be a bit of
work (?)
So, I leave the decision up to you. Any alternatives I haven't thought
of are also welcome.
[1] and, obviously by we, I mean I
--
fails to open valid links
https://bugs.launchpad.net/bugs/138770
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
