fails to open valid links

[Matthew East]

Binary package hint: yelp

Yelp fails to open a number of valid links, giving an error "The requested URI is invalid".

An example is "ghelp:desktop-effects" (from the yelp front page) - the document /usr/share/gnome/help/desktop-effects/C/desktop-effects.xml is present and correct

Another example is any document called from a terminal with a relative path, e.g.:

yelp /home/matt/example/example.xml - works
yelp example/example.xml - doesn't work

[Albert Damen (albrt)]

I can confirm this in Gutsy, yelp version 2.19.90-0ubuntu3

[Pedro Villavicencio (pedro)]

Thanks for your report.

[Don Scorgie (don-scorgie)]

2 separate problems.

First, the desktop effects: Is there a desktop-effects omf file? I can't find one on my (gutsy) system. This means Rarian / Yelp doesn't know where to look. (technically, it shouldn't have worked in previous yelps, but for a strange quirk in libgnome)

Second, the relative paths. This is a known upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=396892

[Matthew East (mdke)]

On 12/09/2007, Don Scorgie <email address hidden> wrote:
> 2 separate problems.
>
> First, the desktop effects: Is there a desktop-effects omf file? I
> can't find one on my (gutsy) system. This means Rarian / Yelp doesn't
> know where to look. (technically, it shouldn't have worked in previous
> yelps, but for a strange quirk in libgnome)

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?

--
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF

[Don Scorgie (don-scorgie)]

> 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

[Matthew East (mdke)]

Hi,

On 13/09/2007, Don Scorgie <email address hidden> wrote:
> 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

Thanks for such a clear explanation. a) is totally the best option.

I'm interested in this dbus business, perhaps we can sort that out for
the next release, and wash scrollkeeper out of our system.

--
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF

[Albert Damen (albrt)]

The desktop-effects link is now working.
An omf file has been installed: /usr/share/omf/desktop-effects/desktop-effects-C.omf provided by ubuntu-docs 7.09.2.
Yelp is still 2.19.90-0ubuntu3

[Sebastien Bacher (seb128)]

The bug seems to be fixed, closing, feel free to reopen if you think there is still an issue though

[Matthew East (mdke)]

The second type of link (docs called with relative path), which is the subject of the upstream report, is still broken in current gutsy.

[toobuntu (toobuntu)]

still a problem in karmic

$ apt-cache policy yelp
yelp:
  Installed: 2.27.4-0ubuntu1
  Candidate: 2.27.4-0ubuntu1
  Version table:
 *** 2.27.4-0ubuntu1 0
        500 http://us.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

[Matthew East (mdke)]

This is fixed in Lucid.