On Sun, 2011-10-09 at 17:23 -0400, Matthias Clasen wrote: > On Fri, Oct 7, 2011 at 9:43 AM, Shaun McCance <[email protected]> wrote: > > I'd like to propose we push for better help menus and help buttons > > in 3.4. This is something I've talked about for about two years now. > > It's all part of the "more accessible help" big picture that we get > > with Mallard. > > > > http://live.gnome.org/ThreePointThree/Features/HelpMenus > > > > Thanks for writing this down. > > I will say that there is some inherent tension between this feature and > the 'Application Menus' feature, which is about simplifying menubars > and moving the remaining items to the appmenu in the shell. > > Can't have smart help search in the menus if you don't have menus anymore... > > So maybe we need to figure out how we can provide better help in > applications that don't have menus in their window - current examples > are gnome-contacts and gnome-documents. Pop up a help search window > when the user hits '?' ? Maybe... > > Other ideas ?
Yes, two ideas: 1) For some types of windows, a well-placed Help button can do the trick just fine. I'm thinking control-center here. The help button in my prototype can act as a menu button if there's more than one matching page. 2) I was putting the API for querying the help in GIO, not GTK+. I wanted it there exactly so that other non-GTK+ processes could use it. An application could expose its help info to the shell, and the shell could query the help. The interaction could be something like this: * Click the application menu on the top bar. * Click the Help item. * The whole menu changes into a help menu, with dynamically populated entries, and a search field. It might even be easier to do the search field in the help menu in St than it is in GTK+. -- Shaun _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
