On 04-08-17 17:24, Gerald wrote:
> On Friday, 4 August 2017 at 15:08:27 UTC, Mike Wey wrote:
>> Improving the documentation is something i want to do but there are always some more important things to do. Like the Questions/Issues you posted earlier.
>>
>> So unless somebody volunteers it won't happen anytime soon.
> 
> Mike I had contributed the makeddox.sh script awhile ago, it generates much nicer documentation then candydocs in my IHMO and includes a nice search box. If there is something lacking in it that needs to be improved before it can be used let me know and I'll do the work.
> 
> The only issue with it that I am aware of is you need to manually copy the public ddox css into the generated folder. I didn't see an easy way to determine it's location automatically.

One issue is the shear size of the generated documentation, though the current version of ddox no longer generates a ton of unused files bringing the size down from 15-20GB to a mere 2GB.

So it has at leased become manageable to host it on the VPS that hosts gtkd.org.

Now remains figuring out setting up the proper redirects on the server, and a few personal preferences about ddox:

The need to go trough the empty module page when browsing the documentation. For a lot / most? functions the complete documentation is in the overview defeating the purpose of the one page per artifact.
And im not a big fan of the one page per artifact style of documentation.

-- 
Mike Wey

On Saturday, 5 August 2017 at 14:02:09 UTC, Mike Wey wrote:
> One issue is the shear size of the generated documentation, though the current version of ddox no longer generates a ton of unused files bringing the size down from 15-20GB to a mere 2GB.

what?! I'm not actually sure how much gtk alone takes, but my entire doc folder is 4 GB, including a good chunk of the dub repo, phobos, druntime, my stuff, search indexes, archives, etc.

I guess it is possible the gtkd is 2 GB of that, but at least it isn't 20.


> The need to go trough the empty module page when browsing the documentation. For a lot / most? functions the complete documentation is in the overview defeating the purpose of the one page per artifact.

If you guys are interested, I can do a custom adrdox for gtk that:

* reads more of the gtk syntax https://developer.gnome.org/gtk-doc-manual/stable/documenting_syntax.html.en

* recognizes the one-item-per-module pattern and skips the empty pages

* has a style more like https://gtkd.org/index.html

* Maybe a few other little things?

> And im not a big fan of the one page per artifact style of documentation.

Oh, it is so much better in a lot of ways.

On 10-08-17 15:57, Adam D. Ruppe wrote:
> On Saturday, 5 August 2017 at 14:02:09 UTC, Mike Wey wrote:
>> One issue is the shear size of the generated documentation, though the current version of ddox no longer generates a ton of unused files bringing the size down from 15-20GB to a mere 2GB.
> 
> what?! I'm not actually sure how much gtk alone takes, but my entire doc folder is 4 GB, including a good chunk of the dub repo, phobos, druntime, my stuff, search indexes, archives, etc.
> 
> I guess it is possible the gtkd is 2 GB of that, but at least it isn't 20.

The problem was that there are a few large classes at the start of the hierarchy, and with the old version of ddox the function pages would not only be generated for the base class, but also for all the derived classes.

So when you have a base class with 264 functions, and you have 385 classes that are directly or indirectly derived from it.
Things start to add up, That is 101_640 html pages just for this one case, and there are more.

Luckily this is fixed, especially because ddox never actually linked to these pages.

>> The need to go trough the empty module page when browsing the documentation. For a lot / most? functions the complete documentation is in the overview defeating the purpose of the one page per artifact.
> 
> If you guys are interested, I can do a custom adrdox for gtk that:
> 
> * reads more of the gtk syntax https://developer.gnome.org/gtk-doc-manual/stable/documenting_syntax.html.en 
> 
> 
> * recognizes the one-item-per-module pattern and skips the empty pages
> 
> * has a style more like https://gtkd.org/index.html
> 
> * Maybe a few other little things?

That would be great.

>> And im not a big fan of the one page per artifact style of documentation.
> 
> Oh, it is so much better in a lot of ways.

I don't use the documentation myself so this isn't really a problem.

-- 
Mike Wey

On Thursday, 10 August 2017 at 14:55:06 UTC, Mike Wey wrote:
> The problem was that there are a few large classes at the start of the hierarchy, and with the old version of ddox the function pages would not only be generated for the base class, but also for all the derived classes.

Oh, I see. My generator lists them on the index, but doesn't recreate it each time, it just links. For example:

http://dpldocs.info/experimental-docs/gtk.ApplicationWindow.ApplicationWindow.html

it lists inherited members again, but not all their docs.

> That would be great.

kewl

> I don't use the documentation myself so this isn't really a problem.

It is a lot easier to link to individual pages from the outside which means search is more reliable, the back button works, stuff like that.

On Thursday, 10 August 2017 at 14:59:52 UTC, Adam D. Ruppe wrote:
> On Thursday, 10 August 2017 at 14:55:06 UTC, Mike Wey wrote:
>> [...]
>
> Oh, I see. My generator lists them on the index, but doesn't recreate it each time, it just links. For example:
>
> http://dpldocs.info/experimental-docs/gtk.ApplicationWindow.ApplicationWindow.html
>
> it lists inherited members again, but not all their docs.
>
>> [...]
>
> kewl
>
>> [...]
>
> It is a lot easier to link to individual pages from the outside which means search is more reliable, the back button works, stuff like that.

Hi,

The way valadoc.org exposes the docs makes them very easy to read and find things (at least for me).

A. Corbi