The linux user ended up heading the art team so we didn't test on that environment.
Ideally the Linux user would like D support in KDevelop. Monodevelop is acceptable but a bit clunky.



On Sun, Sep 1, 2013 at 7:57 PM, Jacob Carlborg <doob@me.com> wrote:
On 2013-09-01 04:05, Manu wrote:

Naturally, this is primarily a problem with the windows experience, but
it's so frustrating that it is STILL a problem... how many years later?
People don't want to 'do work' to install a piece of software. Rather,
they expect it to 'just work'. We lost about 6 hours trying to get
everyone's machines working properly.
In the context of a 48 hour game jam, that's a terrible sign! I just
kept promising people that it would save time overall... which I wish
were true.

Was this only on Windows or were there problems on Linux/Mac OS X as well?


Getting a workable environment:

Unsurprisingly, the Linux user was the only person happy work with a
makefile. Everybody else wanted a comfortable IDE solution (and the
linux user would prefer it too).

I can understand that.


IDE integration absolutely needs to be considered a first class feature
of D.
I also suggest that the IDE integration downloads should be hosted on
the dlang download page so they are obvious and available to everyone
without having to go looking, and also as a statement that they are
actually endorsed by the dlanguage authorities. As an end-user, you're
not left guessing which ones are good/bad/out of date/actually work/etc.

I completely agree.


Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the
only realistic choices available.

There's also DDT with Eclipse. It supports auto completion, go to definition, has an outline view and so on.


The OSX user would have preferred an  XCode integration.

This one is a bit problematic since Xcode doesn't officially supports plugins. But it's still possible, as been shown by Michel Fortin with his D for Xcode plugin.

One more thing:
I'll just pick one language complaint from the weekend.
It is how quickly classes became disorganised and difficult to navigate
(like Java and C#).
We all wanted to ability to define class member functions outside the
class definition:
   class MyClass
   {
     void method();
   }

   void MyClass.method()
   {
     //...
   }

It definitely cost us time simply trying to understand the class layout
visually (ie, when IDE support is barely available).
You don't need to see the function bodies in the class definition, you
want to quickly see what a class has and does.

Sounds like you want an outline view in the IDE. This is supported by DDT in Eclipse. Even TextMate on Mac OS X has a form of outline view.

--
/Jacob Carlborg