[gthumb-list] Does HELP actually work, anywhere, for anyone?

["Ronald F. Guilmette" <rfg tristatelogic com>]

(Paolo, there is a question for you down at the end.  If you can, I'd really
appreciate an answer to it.)

=-=-=-=-

So far, I've been thinking that all my troubles getting at the ``built in''
help files for gthumb might possibly all be due to my use of FreeBSD, rather
than, you know, Linux.  Now, I am less sure.

When the rest of you folks who use Linux and who have, in theory at least,
all of the little bits and parts and pieces of the whole GNOME environment
installed run gthumb and then click on "Help" and then proceed to also
click on either "Contents" or by "Keyboard Shortcuts", what exactly happens
for you?  Does a window pop-up for you that's got the one of the gthumb-
specific help pages in it?  Or does a window pop-up that has a title bar
across the top that just says "Desktop" (and where you seem to be looking
at the root page for _all_ available GNOME documentations files) ?

I am getting the latter behavior, and I think I may have figured out why.

On my system at least, clicking on Help->Contents (now, after fixing the
other problems I have described here) causes the yelp program to be
invoked thusly:

        yelp

Strangely, that seems to kind-of/sort-of work, as described above, even
though according to the yelp man page I found, at the very least, yelp
must, in theory be supplied with a URI as a command line argument.

It appears to me that when and if everything is working properly, that
in fact, gthumb should be causing yelp to be invoked thusly:

        yelp ghelp:gthumb

But that is quite certainly _not_ happening where I am, and I've just
spent the last two+ hours trying to figure out why.

What I believe I have determined is that various routines that are called,
directly or indirectly from `g_app_info_launch_default_for_uri' (which
i sitself called by `gtk_show_uri' which is called by gthumb when it is
asked for Help->Contents) and that these routines are now able to
map the original/starting URI given by gthumb (ghelp:gthumb) to the
name of an executable that should handle URIs with scheme "ghelp:",
namely the yelp program.  After than however, things start to get
ugly and run off the rails.

There seems to be some attempt to invoke yelp as if there had been some
specification for it somewhere that was written like:

        yelp %f

In effect, the code seem to say that if there is no known paramater at
all for the thing to be invoked, then the (macro expanded) equivalent of %f
should be inferred, implicitly.  The code which does this is located in
a routine called expand_application_parameters() which is itself inside
of gdesktopappinfo.c.  Here is the relevant code snippet:

      /* No file substitutions */
      if (uri_list == *uris && uri_list != NULL)
        {
          /* If there is no macro default to %f. This is also what KDE does */
          g_string_append_c (expanded_exec, ' ');
          expand_macro ('f', expanded_exec, info, uris);
        }

Digging further down through yet more layers of this onion, it becomes clear
later on that this implicitly-supplied %f thing should ultimately be replaced
with some absolute pathname in the local file system which is the physical
counterpart for the (logical?) URI "ghelp:gthumb".  But that never happens,
and instead the implicitly-supplied %f ends up getting replaced (on my
system at least) by absolutely nothing, so that in the end, yelp just
gets invoked as:

        yelp

which produces sub-satisfactory results.

The problem seems to be that in and among all of this code that constitutes
glib, libgio, and so forth, there does not even exist, as far as I have been
able to tell, even one sngle line of code that is dedicated to the purpose
of converting a "ghelp:..." URI into any kind of pathname relative to the
local (actual) file system.  Thus, I will be mystified if anyone tells me
that they can get directly to gthum-specific help files via Help->Contents
in gthumb.

For whetever it's worth, I _did_ file the place in the code where URIs
beginning with the scheme "file:" are properly converted into pathnames
relative to the local filesystem... a relatively straightforward mapping.
But as I say, I'm not finding anything even remotly like that in the case
of the "ghelp:" scheme.

Paolo?  What made you ever think that there even was such a thing as a
gehlp: URI scheme in the first place?  I've googled around a bit, and I
haven't found any documentation of any such a URI scheme anywhere.  So
where did your belief in the actual existance of this thing originate from?

Regards,
rfg


P.S.  As troubling as the apparent lack of documentation for the ghelp:
scheme is, what I personally find even more troubling is the way that some
of these glib/gio library routines are quite clearly just punting, silently,
in cases where they can't figure out the right thing to do.  It would be
a hell of a lot better to somehow push out at least _some_ sort of an error
in these cases.  Specifically, I've seen at least two places in the code
where if the code doesn't recognize the scheme name at the front of the URI,
it just throws up its hands and silently returns NULL or the equivalent of
"".

Where I come from, that's called bad engineering.  If a piece of code can't
properly figure out the right thing to do, doing the wrong thing instead is
not actually a solution.