New LDC beta came out, DConf proposal deadline passes, old DIPs get status updates. Adam rants about responsive design.
See more at the announce forum.
I added unix socket support to cgi.d's main http and cgi handlers. It was actually trivial - just a different command line arg, and then a slight change in the connection manager constructor - but may be fairly useful to reverse proxy users. In particular, nginx can do a scgi proxy with a unix socket and this may be easier to use with your firewall and filesystem permissions.
Otherwise, my week has been a lot of day job work and some helping people in the IRC channel. If you are stuck on a D problem and are making no progress after trying for like 20 minutes, stop by #d on freenode and ask us. I'm frequently keeping an eye on the channel and know a lot of D's quirks that trip people up, so - assuming me or one of the other experienced folks are online (don't trust the user list, I leave my user logged in while I'm not on the computer, so answers may not come immediately even if it shows us as in there) - asking in there might turn your hour of frustration into just a couple minutes of of chatting to get pointed in the right direction for a fix.
As for the upcoming week, I am considering adding macro support to adrdox. Yes, I have rallied against user-defined macros at length before, but there's a few small places where they are useful, and I think if I limit their capabilities, I can make it work for those without making a big mess like in normal, unconstrained ddoc. I'll let you know next week.
With responsive UIs being more popular than ever, including on native programs now, I feel the need to point out something I find very important that so many applications get wrong: responsive design should aim to enhance your site's usablity, not break it.
A common thing to do with responsive code is to hide elements when the window gets smaller. This may feel like you are preserving usability - sacrificing "unnecessary" detail in order to protect the core functionality of your application. But, what if one of those unnecessary details actually IS necessary to the user?
Without the responsive code, the user might be able to use viewport zooming or scrolling to access it. It would be awkward, sure, but it would work. On the other hand, if you just remove it, now instead of poor usability, you have no usability. That's a step backward.
(Similarly, I get annoyed with some websites that reorganize as I resize the window... there's times when I, as the user, resize and rearrange windows hoping to hide irrelevant stuff to me, especially in a non-rectangular manner. And this kinda annoys me sometimes, but... eh, I'd say overall my loss there is other users' gains, so I'm kinda ok with it. And in theory, a web browser UI could offer both worlds, but a native developer might need to keep it in mind.)
I suggest that instead of hiding or removing elements, instead try rearranging elements. I like to go more vertical and just let the user scroll to it if they want. (And actually, that isn't a bad design in general for a lot of applications; simple lists for data and forms is often more accessible for users with weaker vision or hand control difficulties too. Very predictable and easy to use with screen magnifiers and keyboard controls, as well as users on narrow screens.)
Of course, eventually I need to apply this to my arsd.minigui module. But I have a lot of work to do there anyway.