As I said before - it's the box not the docs code ... I think (don't
quote me) it was an xsltproc version thing but it's been (as you can see
by the Dec 2007 date) a LONG time.
xsltproc version issues happened and were fixed before, but when is a different matter.
You have time to kick someone with root on y1 steph?
Not without diagnosis...
As for the phpdoc stuff - Steph really I do prefer the OO markup for the
PHP docs - the stuff for inherited methods and such is nice, but it
won't do signals,
Yeah...
and the properties support isn't as good so no matter
what we'll still need a .dtd just for phpgtk.
We always did, always will, because DocBook doesn't actually stretch to our needs. I can't believe we're the only people on the entire www with a need to describe event-driven objects, but there you go...
Depends on how close we
want to stick to the actual php format for those kinds of things (also
will influence how many of their tools we can use - the new online doc
editor comes to mind)
'new' as in 'still under development' I assume, since Philip's been fairly quiet about it :)
Livedocs took a fair amount of hacking to work with phpgtkdoc.dtd. I think phd will be the same, because it relies on pure DocBook (which is relatively new for phpdoc also). The amount of work needed just to find out whether that's so is scary, since it means rewriting the php-gtk doc scripts and dtd all over again and either search/replacing a bunch of tags throughout the manual source, or else generating from scratch. Upgrading is also likely to break Christian's nice hierarchy generation (I don't know how he even did that in the first place).
I'd be inclined to branch php-gtk-doc now and adapt the current serverside scripts to use that branch while work's in progress on upgrading to v5 in HEAD. In that case, it'd be best to get the sysadmin to hit on everything at the same time rather than pester him twice over.
Thanks,
Elizabeth