GNOME Bugzilla – Bug 313569
Use css to position the top and bottom navbar
Last modified: 2005-12-13 09:30:31 UTC
Application toolbar stay where they are. Likewise it would be cool if the navbars in gtk-doc html output would be fixed.
Created attachment 50744 [details] [review] implements the feature I'vetested the results with mozilla and devhelp. Looks good in both. Unfortunately I had to remove the white border around the header and footer. If I had left the boder there, one would see the content scrolling under there. If the border should survive, I would need to pack another box around it.
I guess we should test this with at least opera and IE as well.
And more important is to check it against W3C standards. Use http://validator.w3.org and http://jigsaw.w3.org/css-validator/ for convinience.
Created attachment 50773 [details] example page example html page (also download style.css)
Created attachment 50774 [details] example style sheet also download BtPattern.html
I've tested it under IE and it causes no harm (apart from that IE can't do fixed positions and thus ignores it). If have no opera browser though. Would be nice if others caould test the attached files. Furtermore it like add local anchor links (like shown in the example). This would obsolete: http://bugzilla.gnome.org/show_bug.cgi?id=313558 The attached example is already generated by gtk-doc. If there is agreement that this lloks good I'll complete it for other sections and attach a patch.
I couldn't get the stylesheet to work with the html file. It would probably be better to create a tarball with everything together.
These two files are all I just copied to my win-pc to try under IE. Of cource the navigation-images are missing. Which browser did you tried. What is not working?
It works nicely here with firefox. I like it, although it makes the "too much blue" problem even more severe. I don't see any reason to have both the header and the footer permanently visible though, since the links in the footer are also in the header. I think for fixed positioning it looks more natural to not have the white border anyway.
I've got the stylesheet loading now, but with epiphany it is showing lots of weird characters in the header and footer (capital A with ^ above it). I agree that we don't need both header & footer. Just the header is OK.
Created attachment 50792 [details] [review] implements the fixed top navigation bar the bottom navbar is gone now, more section types are implemented
Created attachment 50793 [details] example style sheet
Created attachment 50794 [details] example page
@damon: here it works with epiphany (1.6.4) the bottom navbar is gone now. I now also set a vallid doctype to make the w3c validator happy. Both HTML and CSS passing the validation services without errors/warnings. One issue I am thinking about is, hoow to propagate the new css to the projects. gtkdocize only updates the make-file. Updating the css is a bit tricky, as one can have multiple docs packages under 'docs/reference'. Maybe gtkdocize should copy images and the css to the docdir and if the package has multiple docs, the maintainer should use links.
A quick follow up: The look of the section links can be customized. I can e.g. colorize then '|' delimiters to be gray or same color as the links. Further the font-size of the nav-links can be made a little smaller to avoid wrapping. Right now I don't have links to property description and signal description. One problem here is that for properties both sections have the name "Properties". So which one should I rename? The first to "Property Overview" or the second to "Property Details".
Fixed title, and confirmed bug.
The last gtk-doc patch isn't working for me, with epiphany 1.4.4 and GTK+ docs. The top navigation bar is fixed, but only the title and icons appear, plus just a single '|' on the line below it. (That is all that is in the HTML.) The bottom navigation bar has disappeared completely. Did you intend to do that?
Created attachment 51184 [details] [review] implements the fixed top navigation bar the new patch has gotten more love. the bottom nav-bar has been removed (as suggested by M. Clasen http://bugzilla.gnome.org/show_bug.cgi?id=313569#c9). I've tested it with gtk and gstreamer. all that left is that I should check if there are any local links at all and omit that one '|' if there are none.
I think "Description" should go first, if possible, as that is the most important. Also I don't think you need "Details" and "Property Details". They just add clutter and aren't that useful. Similarly I think "Signals" should link to the list of signals and the other link isn't needed.
So, you recommend to exclude all links before the Description. That would be okay. What I would find confusing is if we only omit a few of them. I'll make a new patch tonight.
I don't think you need 2 links for each item, e.g. "Properties" and "Property Details". I think just a link to the short list of "Properties" is enough. People can then select the property they are interested in. And the same goes for signals and the others.
Created attachment 51281 [details] [review] implements the fixed top navigation bar now we only have links to description and summary subsections
I've committed the patch, with minor changes. I added a "Top" item to go to the top of the page, and rearranged the code a little so that the '|' is only shown between items and not at the ends of the line, or when there are no links in the navigation bar. I renamed "Signal Prototypes" to just "Signals" to make it simpler. Let me know if anyone spots problems with it.
This patch is causing some problems for me. Since the navbar is always visible now, it covers part of the text when you jump to an anchor. This problem is not always visible depending on the size of the font you're using, so if you can't reproduce, try changing the font to a smaller or larger one. For smaller screens (like a laptop) it's a bit annoying to use up such a big the top section for the navbar as well, when it could be used for the actual page content instead.
Richard, is the stylesheet in use by the html rendering component under your control? If so, we could even have another version of the css, that does not show the headers at all. For devhelp this should make sense as one navigates differently (search and browse). Furthermore if we can extract a meaningful title from the document and show that one in the window title, the header becomes more useless.
Oh, right, I might be able to supply a stylesheet with devhelp. I'll look into that.