Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 17:00:05 UTC, default0 wrote: Aren't these usually called tutorials? Or am I misunderstanding what you mean here? Oh maybe, I've heard "tutorial" used in a lot of contexts and a lot of meanings though, so I wanted to be more specific. This is literally one of the things that bothers me most about the documentation. Mostly when I try figure out how to do something I use google. Google does a really bad job on the D docs... and the D docs don't have enough anchors for it to pick up anyway. (Even if I want to manually share a link, there aren't links to most the ddoc sections! Aaargh!) But the improved interlinking ideas will help with all of that, single pages or separate pages. templates and template constraints isn't always straightforward if you aren't too familiar with the language and its idioms (ie: if you're new to it and trying to learn). Yeah, I think there's three general levels of users: 1) those who don't speak D-ese at all and need to learn the language. D-ese includes more than D itself, but also phobos idioms, general layout, etc. These people really need higher level docs to make sense of it. Tutorials and conceptual overviews need to be written with these people in mind. 2) People who are conversational, but not fluent, in D-ese. They can basically get stuff done but don't know it all. The function-level docs should be good enough for them, but it should translate some of the harder stuff to plain English. Don't ask them to read a constraint mess, just say it in words and in examples. This is the target audience of the stdlib inline docs IMO. They know how to get there, but then need some assistance bringing it back home. 3) People who are fluent in D-ese. The docs aren't terribly important to them except to quickly refresh themselves. They are fully capable of reading the source, but like the docs for a quick outline. The actual content isn't really important to these folks, they just want a convenient index. Plus I'm probably biased since I'm coming from C# and thus am heavily used to the MSDN docs. Yeah, MSDN is great, I think it will be my main model.
Re: Mockup of my doc dream ideas
On Saturday, 26 December 2015 at 03:01:25 UTC, Israel wrote: This is exactly how i feel. You might see me as coming too weak because im used to C# and MSDN Docs holding my hand If it wasn't for Microsoft documentation (I didn't use MSDN per se, but a downloaded win32.hlp file - I didn't have the Internet at home until the last decade - from the Windows 95 era with basically the same content), I'm not sure I'd know half the stuff I know now.
Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 19:00:13 UTC, karabuta wrote: I strongly agree Markdown is simple to use, and well supported. I don't like Markdown personally, though I don't hate it either. A couple features in it are cool, but most of them are just meh to me and a few of them I actively dislike. However, the syntax the documentation is written in is of less relative importance to me than the content and the layout. I write ddoc every week and it annoys me a little... and I also think it has fundamental design flaws that put a hard limit on how much it can improve... but it is basically good enough. I also mostly like writing XML, it really isn't bad! But you'll notice the "dream doc" mock still had ddoc. Even if I were to change things, I'd change it for my new docs... I wouldn't want to go through and convert all of Phobos. (Besides, I'm not the only consumer of the phobos source.)
Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 22:26:46 UTC, bachmeier wrote: Filing a bug is a better approach. It's best to keep everything in one place. Bugzilla sucks hard though, on pretty much every level. It is separate from the page itself, people might not even know it is there, you have to log in, and then fill in a bunch of stuff manually. On the maintainer side, it is really hard to search, a pain to find new issues that are relevant to you, and it is just separate again from the PR process and all that. The suggestion box, on the other hand, would immediately alert me, it would tell me what page the suggestion came from, and the user doesn't have to jump through many hoops. Then, I can manage the backend however I like too. Heck, it could even open a bugzilla issue.
Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 17:00:05 UTC, default0 wrote: On Friday, 25 December 2015 at 14:50:06 UTC, Adam D. Ruppe wrote: Aren't these usually called tutorials? Or am I misunderstanding what you mean here? A single page really detailing what a function does and providing an example for how to use it is what I very much prefer. Plus I'm probably biased since I'm coming from C# and thus am heavily used to the MSDN docs. Thought, one page per function is ok at times too. :-) This is exactly how i feel. You might see me as coming too weak because im used to C# and MSDN Docs holding my hand but with the help of those docs and autocompletion, i learned a decent amount of C# in less than 2 weeks without rarely asking anyone for help. This isnt something you could say for C/C++ or even ruby and python.
Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 15:51:02 UTC, rcorre wrote: On Friday, 25 December 2015 at 14:24:34 UTC, Bubbasaur wrote: What happens when I see a DOC with comments is that sometimes the comments are more clear than the Doc itself, or there are tips or tricks that was not "well" documented. Bubba. If the comments are more clear than the Doc, then they should _be_ the doc. I agree with this. The PHP documentation is a mess because of the comments. Similarly, useful tips and tricks should probably be included as doc examples. In other words, I think we should encourage contribution to official documentation rather than dividing between official docs and user comments. I think there should be link to the wiki for tips and tricks and more examples. Sometimes you don't want 10 examples in the official docs, even if they will help some users. The main reason for using the wiki would be specialized examples. This does raise the bar to entry though, so maybe a suggestion box could be a nice middle ground. Filing a bug is a better approach. It's best to keep everything in one place.
Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 07:41:11 UTC, James Hofmann wrote: On Friday, 25 December 2015 at 05:06:47 UTC, Adam D. Ruppe wrote: I strongly agree Markdown is simple to use, and well supported. No need to do work that has already been done. Besides, Github is pretty popular nowadays. assert(false, "jQuery has a really good documentation.");
Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 15:51:02 UTC, rcorre wrote: On Friday, 25 December 2015 at 14:24:34 UTC, Bubbasaur wrote: What happens when I see a DOC with comments is that sometimes the comments are more clear than the Doc itself, or there are tips or tricks that was not "well" documented. Bubba. If the comments are more clear than the Doc, then they should _be_ the doc. Similarly, useful tips and tricks should probably be included as doc examples. In other words, I think we should encourage contribution to official documentation rather than dividing between official docs and user comments. This does raise the bar to entry though, so maybe a suggestion box could be a nice middle ground. I agree, but you know in a perfect world nothing always work as we imagine, but anyway I think the suggestion box is a good idea. Bubba.
Re: Redesign of dlang.org
On Friday, 25 December 2015 at 14:04:36 UTC, anonymous wrote: On 25.12.2015 12:51, Jacob Carlborg wrote: Most of the pages do not seem to be updated. I don't know what you mean. Could this be a cache thing? Can you give a specific example, maybe with a screenshot? The drop down in the search fields looks very bad in Safari on OS X. I think this is a general problem with bootstrap. This version doesn't use Bootstrap anymore. I just changed some details from the current dlang.org, the core mechanism should work the same. If the current dlang.org looks ok, but mine doesn't, then I must have messed up something. It looks fine for me, though, and I have no OS X around to check. Further assistance would be appreciated. I'm away from my computer atm, so I'll just point you to www.browserstack.com. It's also free for open source projects. Test to your heart's content.
Re: [Feature Request] Single name access when module name and content are same
On Friday, 25 December 2015 at 15:45:16 UTC, tcak wrote:
I only want to discuss an idea here. I am hoping see some nice
pros and cons from people.
---
We have this feature in D:
template something(T){
void something(T value){ writeln( value ); }
}
something("Hello");
Because the name of template and function match each other,
"something" is accepted as name of function.
---
Especially in Phobos, and also in my own libraries, there are
name duplications. The cause of this is that we want to define
things separately, hence defining a new module for them, but
the name of module and class name becomes same. My
thought/request is that, if the name of module and a
variable/constant/struct/class/template/enum that is in that
module matches each other exactly, as seen in the example
above, without name duplication, access should be passed to
that variable/con... etc.
Currently, by using package.d, this is supported in "made up"
way by putting programmer into duplication again while using
directories, but for module itself, I do not see any solution
currently.
Currently, I couldn't have found any issue about adding this
feature. So is the proposal.
module my.big.lib.createFile;
void createFile( string fname ){}
Somewhere else in the code universe:
my.big.lib.createLib("FSociety.dat");
Currently there are two problems about adding this feature:
1. If a class will be defined in the module that's name is same
as class, then, as class names are PascalCase, module name should
be made PascalCase as well, which is not used in Phobos, but at
least do not prevent other people to access a feature just
because Phobos is designed in that way.
2. If there will be two different classes in the module with one
of them named same with the module and other is different,
proposed method prevents being able to access the other class.
(Same problem for variables, consts, etc.)
Re: [Feature Request] Single name access when module name and content are same
On Friday, 25 December 2015 at 17:08:04 UTC, default0 wrote:
On Friday, 25 December 2015 at 15:46:23 UTC, tcak wrote:
On Friday, 25 December 2015 at 15:45:16 UTC, tcak wrote:
I only want to discuss an idea here. I am hoping see some
nice pros and cons from people.
[...]
My mistake at the end. It should be:
my.big.lib.createFile("FSociety.dat");
https://dlang.org/spec/module.html check the section on "Static
Imports" does this do what you want?
You misunderstood what I propose, please reread it again. One
example how the current problem is:
https://dlang.org/phobos/std_digest_digest.html
std.digest.digest.digest!MD5("The quick brown fox jumps over the
lazy dog");
See those 3 digest one after another. Haven't seen anything like
this in neither C# nor Java nor Delphi.
Re: [Feature Request] Single name access when module name and content are same
On Friday, 25 December 2015 at 17:08:04 UTC, default0 wrote:
On Friday, 25 December 2015 at 15:46:23 UTC, tcak wrote:
On Friday, 25 December 2015 at 15:45:16 UTC, tcak wrote:
I only want to discuss an idea here. I am hoping see some
nice pros and cons from people.
[...]
My mistake at the end. It should be:
my.big.lib.createFile("FSociety.dat");
https://dlang.org/spec/module.html check the section on "Static
Imports" does this do what you want?
I think he want something like:
new System.Collections.List!int;
against
new System.Collections.List.List!int;
If you have
module System.Collections.List;
class List(T) { ... }
If the module and class names match, remove one.
Re: [Feature Request] Single name access when module name and content are same
On Friday, 25 December 2015 at 15:46:23 UTC, tcak wrote:
On Friday, 25 December 2015 at 15:45:16 UTC, tcak wrote:
I only want to discuss an idea here. I am hoping see some nice
pros and cons from people.
[...]
My mistake at the end. It should be:
my.big.lib.createFile("FSociety.dat");
https://dlang.org/spec/module.html check the section on "Static
Imports" does this do what you want?
Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 14:50:06 UTC, Adam D. Ruppe wrote: This linked page is my dream for a narrow part of the docs: the function signature. The whitespace formatting can be worked into existing ddoc (I'm angry with existing ddoc and don't want to work with it for a while, but it isn't hugely difficult to do and I think will be a worthwhile incremental improvement), but my other vision is more revolutionary: docs that are written from a "how do I do this" viewpoint rather than a "how do I use this". Aren't these usually called tutorials? Or am I misunderstanding what you mean here? My ideal system would stay one step ahead of me or allow me to stay on the same page as often as possible. Yes. I'm actually a wee bit split on the one page thing: I like having a long, single page with all the info. I just think there's a *lot* of advantages to it and actually consider this a strength of dlang.org (well, until std.algorithm got split up into separate modules. Now it is a pain, and I updated my dpldocs.info search engine in response) This is literally one of the things that bothers me most about the documentation. Mostly when I try figure out how to do something I use google. Usually google picks out a couple of std module documentation pages for search queries I enter and then I have to Ctrl+F-guess my way through pages that make my scrollbar almost vanish or guess from function names (which are often somewhat abstract so it's hard to guess at what functions you should really check out). Then when you try to figure out if a function does what you want it to or not, often examples are missing and reasoning how to use it if it involves templates and template constraints isn't always straightforward if you aren't too familiar with the language and its idioms (ie: if you're new to it and trying to learn). A single page really detailing what a function does and providing an example for how to use it is what I very much prefer. I may also be a bit odd in this regard, since I use a pretty high zoom level in my browser, so scrolling down long pages (or navigations, such as the module list of std) is probably much more annoying to me than to everyone else (I often also want to hop through the documentation, like "oh okay I get how to use this function, but lets also check these two other things while Im here *scroll scroll scroll scroll*"). Plus I'm probably biased since I'm coming from C# and thus am heavily used to the MSDN docs. Thought, one page per function is ok at times too. :-)
Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 14:24:34 UTC, Bubbasaur wrote: What happens when I see a DOC with comments is that sometimes the comments are more clear than the Doc itself, or there are tips or tricks that was not "well" documented. Bubba. If the comments are more clear than the Doc, then they should _be_ the doc. Similarly, useful tips and tricks should probably be included as doc examples. In other words, I think we should encourage contribution to official documentation rather than dividing between official docs and user comments. This does raise the bar to entry though, so maybe a suggestion box could be a nice middle ground.
Re: [Feature Request] Single name access when module name and content are same
On Friday, 25 December 2015 at 15:45:16 UTC, tcak wrote:
I only want to discuss an idea here. I am hoping see some nice
pros and cons from people.
[...]
My mistake at the end. It should be:
my.big.lib.createFile("FSociety.dat");
[Feature Request] Single name access when module name and content are same
I only want to discuss an idea here. I am hoping see some nice
pros and cons from people.
---
We have this feature in D:
template something(T){
void something(T value){ writeln( value ); }
}
something("Hello");
Because the name of template and function match each other,
"something" is accepted as name of function.
---
Especially in Phobos, and also in my own libraries, there are
name duplications. The cause of this is that we want to define
things separately, hence defining a new module for them, but the
name of module and class name becomes same. My thought/request is
that, if the name of module and a
variable/constant/struct/class/template/enum that is in that
module matches each other exactly, as seen in the example above,
without name duplication, access should be passed to that
variable/con... etc.
Currently, by using package.d, this is supported in "made up" way
by putting programmer into duplication again while using
directories, but for module itself, I do not see any solution
currently.
Currently, I couldn't have found any issue about adding this
feature. So is the proposal.
module my.big.lib.createFile;
void createFile( string fname ){}
Somewhere else in the code universe:
my.big.lib.createLib("FSociety.dat");
Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 07:41:11 UTC, James Hofmann wrote: 1. There's more code than ever and more of a need for code to be well-documented on a conceptual/hand-holding level Absolutely. general idea of fitting the text into a certain container is similar to the API doc tradition of following the class-and-method structure of the code. I recently went to add some explanation to std.base64 on how to get a string out of it since someone asked here. But I actually stopped on the official website just because I couldn't find a place to put it. It didn't really fit in base64.d, the existing structure was all wrong and it was the wrong level. You can apply the concept using base64 but it isn't specific to it. It didn't fit on any of the existing pages. And adding a new page was just too painful for me. I ended up posting a couple quick sentences to the wiki - not even linked from anywhere - then running away. Everybody lost just because I felt blocked by the existing structure. (and I don't know wiki syntax, I felt like that was another blocker, and the dlang.org intralinking situation is terrible too) This linked page is my dream for a narrow part of the docs: the function signature. The whitespace formatting can be worked into existing ddoc (I'm angry with existing ddoc and don't want to work with it for a while, but it isn't hugely difficult to do and I think will be a worthwhile incremental improvement), but my other vision is more revolutionary: docs that are written from a "how do I do this" viewpoint rather than a "how do I use this". We still have the "how do I use this" sections, the existing pages basically fit that. But they feel written bottom-up. I want to do top down. I've said before that I currently have a contractor working on some docs. My instructions for her were simply "write something cool in D and document it for future newbies". What she's written so far is already very different than what we have, though there's still a lot of work to do. (In particular, I'm kinda struggling with how much editing I want to do. The point is to document a newbie's journey as a guide to other newbies but I also see her making a few mistakes that I kinda want to correct... but she's learning quite a bit from those mistakes too and so could the readers. I hate tutorials that assume everything works. Users need to get used to seeing error messages and understanding both what they mean and why they are there.) Once we get started, other things will follow. A friend of mine who is new to D just wrote something to save text to a google doc this week. The result is useful to him and his work and while it isn't super advanced D, the journey would be a good experience for others too. What libraries did he use? How did he overcome problems? From these results-driven narratives, I can go back and start linking in more things - related narratives (generic D REST api tutorial, JSON use), language feature discussions (what was that nested function used in the callback? why use `is null` instead of `==`? what's `opIn`?) and idioms, concepts like string encoding and type system wrangling, and, of course, library docs for the used pieces. Then link it back to the top level. Of course, this stuff is a lot of work. I only have so much money I can spend on hiring people to work with this for me, and I have even less time to spend writing it myself... which is one reason why I'm now working on my new automation code. The mockup is good in that it cleans up the messy look and feel of the current presentation, and suggests the potential for interactivity. My main concern from a presentation standpoint is high latency, which in these interactive help systems typically comes in the form of slow page loads every time I try to click on something. That's an issue of implementation. I'm literally in the same room as the server TWiD is on so I can't objectively judge its speed, but try clicking around the issues here: http://arsdnet.net/this-week-in-d/dec-20.html does it respond reasonably well? I made very little effort on optimization there... but also kept it simple and did all the processing ahead of time. The server hands out pre-built .html.gz files on demand, no dynamic parts. My D doc search engine has dynamic parts: http://dpldocs.info/findSkip though I also wrote it with a bit of an eye toward efficiency because waiting for docs drives me nuts. The static parts can all be downloaded in a bundle easily enough. Search could be a downloaded program too. Offline docs matter to me - I'm not always on the internet either! My ideal system would stay one step ahead of me or allow me to stay on the same page as often as possible. Yes. I'm actually a wee bit split on the one page thing: I like having a long, single page with all the info. I just think there's a *lot* of advantages to it and actually consider this a strength
Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 14:24:34 UTC, Bubbasaur wrote: On Friday, 25 December 2015 at 14:13:56 UTC, Adam D. Ruppe wrote: On Friday, 25 December 2015 at 09:18:45 UTC, Israel wrote: Why not take it to the next level while youre at it? Add user comments that can be rated by users and sorted by date. My dream does not include user comments. I don't think well-written documentation benefits from them... What happens when I see a DOC with comments is that sometimes the comments are more clear than the Doc itself, or there are tips or tricks that was not "well" documented. Bubba. Just one example that I said early, if you look here: https://dlang.org/dmd-windows.html#switch-L (-Llinkerflag) It's written: "pass linkerflag to the linker link.exe , for example, -L/ma/li". But at least on Windows, you need to put a space between -L and the PATH. Which It's weird, since with "-I" flag you don't need any space. It took me 30 minutes until I find why my program wasn't compiling. Thanks to the Forum. Bubba.
Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 14:13:56 UTC, Adam D. Ruppe wrote: On Friday, 25 December 2015 at 09:18:45 UTC, Israel wrote: Why not take it to the next level while youre at it? Add user comments that can be rated by users and sorted by date. My dream does not include user comments. I don't think well-written documentation benefits from them... What happens when I see a DOC with comments is that sometimes the comments are more clear than the Doc itself, or there are tips or tricks that was not "well" documented. Bubba.
Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 09:18:45 UTC, Israel wrote: Why not take it to the next level while youre at it? Add user comments that can be rated by users and sorted by date. My dream does not include user comments. I don't think well-written documentation benefits from them, and adding such a thing would surely include some kind of speed hit on the page, harm downloadability, etc.; the page would then have a dynamically loaded section. That isn't necessarily a dealbreaker, it just isn't a part of my dream. On the other hand, I do dream of a suggestion box on the page that contacts the authors so they can incorporate it... which isn't totally different than comments. So I'll put it down as a maybe.
Re: Redesign of dlang.org
On 25.12.2015 12:51, Jacob Carlborg wrote: Most of the pages do not seem to be updated. I don't know what you mean. Could this be a cache thing? Can you give a specific example, maybe with a screenshot? The drop down in the search fields looks very bad in Safari on OS X. I think this is a general problem with bootstrap. This version doesn't use Bootstrap anymore. I just changed some details from the current dlang.org, the core mechanism should work the same. If the current dlang.org looks ok, but mine doesn't, then I must have messed up something. It looks fine for me, though, and I have no OS X around to check. Further assistance would be appreciated.
Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!
On Friday, 18 December 2015 at 10:41:46 UTC, Claude wrote: Bottom line is, if you are competent enough, you can be successfull with D, just like you would be if you were using C/C++. D's superior compile-time meta programming allows you to express zero cost abstractions give you the edge that makes things more enjoyable. There are several open-source kernels written in D that are proof of the above: https://github.com/Vild/PowerNex https://github.com/Bloodmanovski/Trinix https://github.com/xomboverlord/xomb Adam Ruppe has a chapter about bare-metal programming with D in his Cookbook. I do think D may be a perfectly valid real-time language. And indeed, I believe that the GC is not an issue (you can disable it, question solved). However, is D a proper Embedded System language? I'm not pretty sure it's there yet. Plain C rules the world of embedded systems. All the RTES programmers I've met are reluctant to even use C++. If you cannot program a 16-bit PIC in D, then D will not replace C at all (but is it meant to?). The open-source kernels above are targeted at PC architecture. I know some work have been done to make bare-metal OS targeted at ARM. I don't know what's the state of those projects, and I'd love to make my own once I have time (based on Rasberry Pi for instance). To validate D as a proper Real-Time Embedded System, one would have to make a proper bare-metal OS a ARMv5 chip (for example). Write your Interrupt Service Routines in assembly calling D functions, program the MMU, the different hardware blocks (UART, INTC, USB etc). And the API of such an OS would benefit of the expressiveness power of D (templates, traits UDA etc) and not just be a C-style clone, with an efficiency similar to C (at least same CPU load). Hi, D should be used for low level/real-time programming. But there is a lot of exceptions in it and you cannot use entire D extensions like synchronized, array relocations, shared, and many operations on array like "string" ~ "join", etc. Im working on modular, microkernel "RTOS" based on sync messages passing in D and there is not any big problem with using D as a low level language for OS development. (Im creator of Trinix BTW)
Re: dmd without gcc depency
On Friday, 25 December 2015 at 12:57:50 UTC, Jardik wrote: Now that dmd is written in D language, is it possible to use dmd without the need to have gcc and its libraries installed? Or would it be possible, if I didn't need to call any extern C++ functions? If not, is it planned for dmd to be self hosting in the future? You don't need gcc to _use_ dmd now, only to build its dmc backend. Dmd calls your C compiler, usually gcc, to link objects on linux, but you could replace that with a direct call to your linker if you know what you're doing. If you don't want to use gcc to build dmd itself, there are plans to convert the dmc backend to D also, but not for a couple releases.
Re: dmd without gcc depency
On Friday, 25 December 2015 at 12:57:50 UTC, Jardik wrote: Now that dmd is written in D language, is it possible to use dmd without the need to have gcc and its libraries installed? Or would it be possible, if I didn't need to call any extern C++ functions? If not, is it planned for dmd to be self hosting in the future? DMD is the front end of the compiler. Where will the linker be coming from? I don't think DMD developers are writing a special linker as well. It only turns codes into object files.
dmd without gcc depency
Now that dmd is written in D language, is it possible to use dmd without the need to have gcc and its libraries installed? Or would it be possible, if I didn't need to call any extern C++ functions? If not, is it planned for dmd to be self hosting in the future?
Re: D Consortium as Book / App Publisher... ?
On Thursday, 24 December 2015 at 17:19:30 UTC, karabuta wrote: On Sunday, 20 December 2015 at 21:09:31 UTC, Jakob Jenkov wrote: Writing a focused book of around 100 pages can be done in 3-6 months. If more people chip in, it might even be faster. There are these books floating around where various programmers actually come together to write them. Each author take charge of a section. They go like: Problem: How to rename all files in a directory. Solution: .. They take advantage of common tasks and make them into a book. These books really sell. D community/Consortium can do similar if is worth it. Wrox Publishing uses this model. Not all their books are really good, but they can be decent. I was thinking the D Language Foundation could do the same. But I guess someone has to take the reigns, make a plan and mobilize people.
Re: Redesign of dlang.org
On 24/12/15 20:33, anonymous wrote: On 21.12.2015 14:58, anonymous wrote: http://d-ag0aep6g.rhcloud.com/ On GitHub if people want to play around with it: https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign That's a full clone of dlang.org in the new style. I just pasted it over the old style, and hacked around on top of it until it worked, more or less. It's a quick and dirty showcase. I touched everything, but polished nothing. There are more rough edges than smooth ones. Since Andrei and Jacob are having creative differences, I figured I'd just go ahead with this my way, without changes to the tooling. This is a more proper implementation of the redesign than what I showed before: http://d-ag0aep6g.rhcloud.com/ Most of the pages do not seem to be updated. The drop down in the search fields looks very bad in Safari on OS X. I think this is a general problem with bootstrap. I remember having the same problem when I used bootstrap. In general I recommend using either Boostrap Select [1] or a Bootstrap drop down button [2]. For this particular case I recommend using either a field with a button with a drop down [3] or placing a magnifier icon to the left inside the search field and make a drop down menu out of that icon. The latter option is usually how native search fields look like and work on OS X. [1] https://silviomoreto.github.io/bootstrap-select/examples/ [2] http://getbootstrap.com/components/#btn-dropdowns [3] http://getbootstrap.com/components/#input-groups-buttons-dropdowns -- /Jacob Carlborg
Re: Mockup of my doc dream ideas
On Friday, 25 December 2015 at 05:06:47 UTC, Adam D. Ruppe wrote: I wrote this manually as a mock of what I really want the docs to look like. I only marked up the top box and a wee bit of the bottom. The body text of the doc is written by us and is OK, but the function signature is a mess. [...] Why not take it to the next level while youre at it? Add user comments that can be rated by users and sorted by date.
