Am 11.12.2012 22:13, schrieb Andrei Alexandrescu:
> On 12/11/12 3:54 PM, Rob T wrote:
>> On Monday, 10 December 2012 at 22:33:49 UTC, 1100110 wrote:
>>> On 12/10/2012 05:16 AM, Mr. Anonymous wrote:
>>>> On Monday, 10 December 2012 at 02:10:43 UTC, Ellery Newcomer wrote:
>>>>> Is anyone else noticing e.g. std.datetime taking upwards of 30 seconds to render the blob of links at the top? It's freakin freezing my entire browser.
>>>>
>>>> ddox* on dlang.org, anyone? http://vibed.org/temp/phobos/index.html
>>>>
>>>> * https://github.com/rejectedsoftware/ddox
>>>
>>> Man, how did I miss that? I like that.
>>
>> http://vibed.org/temp/phobos/std/datetime.html
>>
>> Wow, that's a HUGE improvement to what has been a very difficult read for std.datetime.
>>
>> I'd like to bookmark the Vibe Phobos reference page for use as my library reference. Will it remain there at least until the official web page reference is improved in a similar or identical way?
> 
> Do whom do we talk about Borging the vibe dox into dlang.org?
> 
> Andrei
> 

Okay, I have prepared a small repository which generates Phobos/Druntime documentation and integrates it into dlang.org (it currently needs vibe.d installed to build the ddox binary):

https://github.com/s-ludwig/phobos-docs


The paths are currently adjusted for working side-by-side with phobos, druntime and d-programming-language.org:

-----
/
	/dprogramming-language.org/
	/druntime/
	/phobos/
	/phobos-docs/
-----


There are some batch files that generate the documentation. Running the following sequence will yield HTML docs in ../d-programming-language.org/phobos/:

-----
cd phobos-docs
vibe build
generate_json
filter_json
generate_html
-----

Example generated site is here:

http://vibed.org/temp/d-programming-language.org/phobos/index.html


Is any further work on this desired? If so, what would be the next steps to integrate it into the general dlang.org workflow? (or rather, how is that workflow in terms of folder structure, build scripts etc.?)

It would also need a phase of bug fixing regarding some macros used in the Phobos ddoc comments.

On 12/21/12, Sönke Ludwig <sludwig@outerproduct.org> wrote:
> Is any further work on this desired?

The start of the code section needs to be moved a little bit to the right so the text doesn't appear to touch the edge: http://i.imgur.com/VuXE1.png

And maybe the color scheme should match the one before, dark text on light background, since that's the color scheme of the rests of the text. Personally I use a similar theme like yours, but for the website it might be better to match the way it already looks.

On 2012-12-21 13:24, Sönke Ludwig wrote:

> Example generated site is here:
>
> http://vibed.org/temp/d-programming-language.org/phobos/index.html
>
>
> Is any further work on this desired? If so, what would be the next steps to integrate it into the
> general dlang.org workflow? (or rather, how is that workflow in terms of folder structure, build
> scripts etc.?)

Nice. Now we need to just remove those ugly manually create tables. I'm thinking mainly on those on top of std.algorithm.

What also would be nice is to have the methods inline, expandable.

I get a JavaScript error when I'm selecting the search field:

SyntaxError: syntax error
[Break On This Error] 	

if(this.value ==

github...769e.js (line 3, col 17)

-- 
/Jacob Carlborg

Am 21.12.2012 15:20, schrieb Andrej Mitrovic:
> On 12/21/12, Sönke Ludwig <sludwig@outerproduct.org> wrote:
>> Is any further work on this desired?
> 
> The start of the code section needs to be moved a little bit to the right so the text doesn't appear to touch the edge: http://i.imgur.com/VuXE1.png
> 
> And maybe the color scheme should match the one before, dark text on light background, since that's the color scheme of the rests of the text. Personally I use a similar theme like yours, but for the website it might be better to match the way it already looks.
> 

Done. (I forgot about the code styling all together)

Btw. is there a good syntax highlighter written in D, ideally with multi-language support? Currently I'm using a modified version of Google Prettify (JavaScript). But it would be nice to have the highlighting baked into the static HTML.

12/21/2012 4:24 PM, Sönke Ludwig пишет:
> Am 11.12.2012 22:13, schrieb Andrei Alexandrescu:
>> Do whom do we talk about Borging the vibe dox into dlang.org?
>>
>> Andrei
>>
>
[snip]
>
> Example generated site is here:
>
> http://vibed.org/temp/d-programming-language.org/phobos/index.html
>

Like it!



-- 
Dmitry Olshansky

On 12/21/12 10:43 AM, Jacob Carlborg wrote:
> On 2012-12-21 13:24, Sönke Ludwig wrote:
>
>> Example generated site is here:
>>
>> http://vibed.org/temp/d-programming-language.org/phobos/index.html
>>
>>
>> Is any further work on this desired? If so, what would be the next
>> steps to integrate it into the
>> general dlang.org workflow? (or rather, how is that workflow in terms
>> of folder structure, build
>> scripts etc.?)
>
> Nice. Now we need to just remove those ugly manually create tables. I'm
> thinking mainly on those on top of std.algorithm.

s/remove/integrate/
s/ugly/awesome/

The cheat sheet in std.algorithm is unnecessary (though I liked the brief examples), but there's a lot of value in the symbols grouped by category (searching, comparison, ...) at the top. So we need to have a means to group things in the new interface.

> What also would be nice is to have the methods inline, expandable.

That would be awesome!

Andrei

On Fri, Dec 21, 2012 at 12:05:47PM -0500, Andrei Alexandrescu wrote:
> On 12/21/12 10:43 AM, Jacob Carlborg wrote:
> >On 2012-12-21 13:24, Sönke Ludwig wrote:
> >
> >>Example generated site is here:
> >>
> >>http://vibed.org/temp/d-programming-language.org/phobos/index.html
> >>
> >>
> >>Is any further work on this desired? If so, what would be the next steps to integrate it into the general dlang.org workflow? (or rather, how is that workflow in terms of folder structure, build scripts etc.?)
> >
> >Nice. Now we need to just remove those ugly manually create tables. I'm thinking mainly on those on top of std.algorithm.

We need a way to group methods by (manually-assigned) category.


> s/remove/integrate/
> s/ugly/awesome/
> 
> The cheat sheet in std.algorithm is unnecessary (though I liked the brief examples), but there's a lot of value in the symbols grouped by category (searching, comparison, ...) at the top. So we need to have a means to group things in the new interface.

+1. The blob of links generated by JS at the top of the current pages is
(1) ugly, and (2) useless. Grouping symbols by category is by far more
useful. We need to keep that.


> >What also would be nice is to have the methods inline, expandable.
> 
> That would be awesome!
[...]

That would be nice, but could we make that optional please? As in, I'd still like to be able to scroll down to read the perhaps longer and more detailed description.

Alternatively, have the method signature and perhaps first paragraph or two in the expandable header, which links to the full description further down the page.


T

-- 
Try to keep an open mind, but not so open your brain falls out. -- theboz

On Friday, 21 December 2012 at 17:23:41 UTC, H. S. Teoh wrote:
> +1. The blob of links generated by JS at the top of the current pages is
> (1) ugly, and (2) useless. Grouping symbols by category is by far more
> useful. We need to keep that.

Yes, a category list is far more useful. The best the blob serves is as an appendix for the module, but it should be at the bottom of the page not at the top, and perhaps make it hidden requiring a click to view it.

--rt

On Fri, Dec 21, 2012 at 07:20:16PM +0100, Rob T wrote:
> On Friday, 21 December 2012 at 17:23:41 UTC, H. S. Teoh wrote:
> >+1. The blob of links generated by JS at the top of the current pages
> >is (1) ugly, and (2) useless. Grouping symbols by category is by far
> >more useful. We need to keep that.
> 
> Yes, a category list is far more useful. The best the blob serves is as an appendix for the module, but it should be at the bottom of the page not at the top, and perhaps make it hidden requiring a click to view it.
[...]

This is a good idea. Put it at the bottom of the page as an index of some sort.


T

-- 
Береги платье снову, а здоровье смолоду.

Am 21.12.2012 18:05, schrieb Andrei Alexandrescu:
> (...)
> 
> The cheat sheet in std.algorithm is unnecessary (though I liked the brief examples), but there's a lot of value in the symbols grouped by category (searching, comparison, ...) at the top. So we need to have a means to group things in the new interface.

Ideally, we would invent some standard DDOC syntax to specify groups then. But generally an ungrouped list also has its advantages when you try to look something up _by name_. I've found myself in the past, skimming over the category table multiple times, looking for a certain function, until deciding that I had to guess the category first, which may not always be obvious.

So maybe keeping the manual category quick index table (and maybe putting it in a separate "Categories:" section) is a viable option for the time being? Most modules probably wouldn't need one anyway.

>> What also would be nice is to have the methods inline, expandable.

Would that mean the Classes/Structs/... tables as f.ex. in std.datetime?
So there would be a small clickable thing and all members would fly out below it as direct links?
and possibly with the short description?
What about different kinds of members? Only methods, all grouped by type or all in one list?

I'm just asking because I don't have any preferences for how such a thing should look like.