On 31/05/2015 1:26 p.m., lobo wrote:
On Saturday, 30 May 2015 at 14:35:29 UTC, Rikki Cattermole wrote:
On 31/05/2015 2:31 a.m., ketmar wrote:
On Sun, 31 May 2015 02:28:51 +1200, Rikki Cattermole wrote:
On 31/05/2015 2:27 a.m., ketmar wrote:
On Sun, 31 May 2015 01:35:41 +1200, Rikki Cattermole wrote:
Great example, if you wanted to play some music cross platform what D
library what you use?
SDL audio. ;-)
Okay lets ignore libraries that is not D. Like that one.
i bet Devisualisation is using Xlib/XCB, so it's out of competition too,
for example. ;-)
Well then lets call a spade a spade and start writing our own
operating system shall we?
Personally I think it is more reasonable to assume certain libraries
will be installed. Such as for Windows user32 and GDI.
Where by there is no real alternatives. Like X11 for *nix.
In other words, system libraries are fine to use. As you have no real
choice in the matter.
Now SDL on the other hand, you cannot assume will be installed or
available. Unless you want to go bundling that or using static
libraries. Still defeats the purpose of expanding D's library base.
Why do people always want to reinvent such well tested libraries? Slap a
nice D API over the top and reuse the hard work of others.
Besides SDL is pretty much ubiquitous on all platforms D supports. You
could even package up dependencies with your bindings and the end-user
wouldn't have to worry.
Honestly though if someone isn't willing to learn how to obtain SDL for
their chosen platform, even if it requires building from source. then
they should probably forgo programming as a career or hobby.
bye,
lobo
You're missing a large part of what I'm saying.
For people just learning the language and getting started, saying go
download x for your platform won't be enough. Look at how we are
handling curl right now.
No, for any e.g. library or window creation libraries and likes. Must
have an agreed interface that is not specific to e.g. SDL.
SDL may implement them. But out of the box experience must not rely on
3rd party.
E.g. such an image library there wouldn't be a JPEG implementation but
would be a PNG one. Because of the complexity of implementing a JPEG
reader/writer. Which is ridiculously hard compared to PNG which is
actually really simple.
