Right, time for a new announcement from me.

First off the library I have been talking about called DWC has been renamed. It is now Under the banner of Devisualization, window[0] project.

Devisualization.window otherwise known as de_window is a window and context creation for Windows, Linux and Mac OSX.
It does need a good bit of testing especially on Linux.

In short, the goal of Devisualization Github organization is to promote game development and the libraries to facilitate it in D.

Projects I want made:
- Events/controls abstraction + GUI controls
- Native GUI controls (such as the menu for OSX)
- Virtual File System
- OpenGL wrappers and tooling
- Image loading/exporting (currently working on png)
- 3d model loading/exporting (.3ds .obj at the minimum)
- Scenegraph
- Audio loading/exporting
- Unity like interface
- Scripting
- Entity modeling

Not in any particular order and can very easily be added to. I'm sure there is a lot of code already available that can do some of these things, but to make it all work together nicely would be a challenge.

I did write up on my blog about all this [1], but you don't need to read it. It just goes into a bit more depth.
About Cmsed and my web dev stuff, I haven't stopped working on it per-say. I'm waiting on e.g. [2].

[0] https://github.com/Devisualization/window
[1] http://blog.alphaglosined.tk/2014/11/window-creation-d-initiative.html
[2] https://github.com/D-Programming-Language/dmd/pull/3921

Nice work, it's basically the SDL replacement I wished for! I like that its scope is well defined.

I don't get why it depends on DerelictGL. AFAIK SDL, GLFW and friends do not depend on GL function loaders.

On Friday, 7 November 2014 at 10:48:46 UTC, Rikki Cattermole wrote:
> - Native GUI controls (such as the menu for OSX)

D native or OS native?

On 8/11/2014 12:46 a.m., ponce wrote:
> Nice work, it's basically the SDL replacement I wished for! I like that
> its scope is well defined.
>
> I don't get why it depends on DerelictGL. AFAIK SDL, GLFW and friends do
> not depend on GL function loaders.

It depends because of OpenGL context creation. And it requires a reload to work properly when activating.
Might be better as an optional dependency.

On 8/11/2014 12:48 a.m., Kagamin wrote:
> On Friday, 7 November 2014 at 10:48:46 UTC, Rikki Cattermole wrote:
>> - Native GUI controls (such as the menu for OSX)
>
> D native or OS native?

Short answer:
Basically it should use the native implementation if possible otherwise it should use the non native version.

Long answer:
I'll use the example of OSX with the menu.
OSX has a specialized menu as part of its UI which all applications are meant to use.
On this case it should use this. But on a platform such as Windows, if there is no context it can freely use the native menu system. But if it has a context it should emulate it via e.g. OpenGL like it wasn't native.
Then of course is X11 which case it would be OpenGL as their is no native version of it.