Re: Initial work on a help API

[Rodrigo Moya <rodrigo gnome-db org>]

On Thu, 2011-04-21 at 16:16 -0400, Shaun McCance wrote:
> Hi all,
> 
> I had a project called Squawk I was working on last year.
> I chatted a bit with Ryan Lortie about it at the recent
> help hackfest, and decided to work on it again, but this
> time directly in GLib and GTK+.
> 
> The basic idea is that GLib has a help provider API that
> knows about your application's help. It knows more than
> just that the help exists. It actually knows about all
> the topics in your help, their URIs, titles, tags, etc.
> 
> Then there's a set of GTK+ widgets that consume this.
> If you want to make a help button in a dialog, instead
> of just making a button and attaching a static URI to
> it, you'd make a help button and give it a tag. Then
> it's up to help authors to tag topics for that button.
> 
> Then do menus the same way. We can kill off the crappy
> Help->Contents item, and have the Help menu display
> whatever topics help authors feel are worth promoting
> to the menu. You can change widget tags at run-time to
> make them reflect UI state or what the user is doing.
> 
I was looking at reducing the number of patches some Ubuntu packages
carry over, and one of them (in several packages) is about
launchpad-integration, which adds several items to the Help menu ("Get
Help online", "Translate this application" and "Report a problem"), so I
was thinking on writing some GtkHelpMenu widget or something similar
that does this automatically.

Would that be helpful for upstream GTK? I guess it could do what the
launchpad integration thing does (pointing to GNOME bugzilla and
translations pages, of course, so that Ubuntu would just have to patch
that to point to Launchpad) plus what your code does.

So, what do GTK maintainers think about it?