I'm not sure I agree with this. The current way makes it possible to type gtk_cell_renderer for example and have the list of hits visible while poking around in the html view. If we have an entry with a combo, the combo is a one shot thing that goes away once you pick a hit. The current way actually has some thought behind it, it's not just thrown together...

Thank you for the nice summary string by the way, that really warms my heart, and makes me want to help you a lot.

Richard,
the point is that currently if you press CTRL-S and you're browsing the documentation tree the focus will move to the search tab so you're either searching or you're browsing the documentation tree. Having it this way makes it more difficult to have a global view of the stuff. If dockable windows are an option, maybe choose this over my suggestion and the current layout?

Regarding the summary: I have to admit the summary is a bit rough, and I must apologise for that, but if you want to change the layout of devhelp great, if you don't, you don't. Just don't try and make it look as if you're the one loosing time by lending a hand.

Apology accepted of course, sorry that I reacted so strongly. I had a bad day, and hearing that your software is useless doesn't make a bad day any better... :)

I'm trying really hard not to make the content view much smaller, but how about if we make the left pane split vertically and show the tree and search list above one another? It would leave less space for each but at the same time wouldn't steal space from the actual content. We probably need to try it out and see how if feels, at least. I have a feeling that the tree will get a bit too small.

hmmm if using the toolbar, similar to what Firefox address bar looks like, for a search combo doesn't make the browsing area any smaller. The toolbar is huge anyway and it only has 3 buttons on it.

Either way, any change certainly feels as an improvement so please try do your ideas :-)

I have played around a bit with this to come up with alternatives. The current design is designed for use case patterns like those:

* You are looking for a function, you know roughly what it's called, and type get_style.
* You see about 15 hits, in various libraries. You know it's in gtk so you focus on those (about 8 of the hits).
* You click them all in turn to read about them and see which one is right.

or this:

* You know you are looking for something related to style, and type style.
* You get loads of hits, and you try to filter it down by adding a word, get (ie you now have "style get"). Still there are many hits.
* But you know it's in gtk so you add gtk, (ie yo have "style get gtk"). Now you get 10-15 hits which fit nicely in one screen and you can go through them or directly spot the right one.

or this:

* You know the exact function you are looking for and start typing it, you use the word completion to help you spell it right and do it fast. You find the single hit you wanted.

In other words, in the 2 first cases it's meant to be a persistent list, not a transient one that just pops up when you search, you pick something and then it's gone. If is also not supposed to cover the content area because you use them together. The last case is more transient in nature.

The two first are more important imo. The latter should be done instead by using editor integration, where you press some key in emacs/vim/gedit/whatever when the cursor is t that function name.

The compromise I suggested, to put the search hit list above the content tree could work, but it would leave little space for the two lists. I haven't dropped that idea completely.

So, I will close this for now. We can still keep thinking about other ways to layout the UI, of course.