Comment 14 for bug 294182

Thanks to Shaun McCance for comment #12. I see what the trouble is. Yelp is setting itself up to display its full glorious range of capabilities before it starts drawing to the screen. Hence the long delay with nothing happening on screen. Make it draw its window, menu bar and the content of the help file as the first thing it does. Defer other processing until after the window and content are there on screen. Do the minimum possible amount of processing before starting to draw. Most users just want to see their help content as soon as possible, then do a bit of scrolling, go to the next page and that is about it. Make the common things fast and on the critical path. Defer processing for the uncommon things.

It is quite possible the user may never use some advanced features, such as search. It is wasteful to go to the trouble of setting something up, then throw away all that work when Yelp quits. Do not set advanced features up at all, until the user first asks to use them. On the subject of advanced features to defer or cut, I never use bookmarks, man and info pages or text search. Help Topics is used rarely.

I agree that it is a pain that GTK+ 3 is different from GTK+ 2. Further, I agree that GTK+ 3 gets used for new development. However, is it not the case that GTK+ 3 is a superset of GTK+ 2? So it should not be too difficult to use only GTK+ 2 for common actions, with advanced features which use GTK+ 3, simply left out. That would give a cut-down version of Yelp suitable for Lucid and Maverick. Fix this bug, at the cost of some features regressions. That would be a better option for most users than sticking with the present buggy version of Yelp. Yes, a few might be unhappy. Give those people instructions on how to go back to Yelp 2.30.0. I look forward to the next contribution by Shaun McCance.