www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Progress on Adam Wilson's Graphics API?

reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
Is there any progress on the graphics API Adam Wilson is working 
on?
May 03 2014
next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Sat, 03 May 2014 02:56:37 -0700, Nordl=F6w <per.nordlow gmail.com> wr=
ote:

 Is there any progress on the graphics API Adam Wilson is working on?

Yes. There has been progress. I am currently finishing up the DirectX 11= = bindings. For now it will include everything but 3D. I am focusing on = Windows 2D for the moment because that is the environment I am most = familiar with. If you want to help with OpenGL for Linux or OSX, I will = = gladly pull requests! I'll have much more to say about Aurora at DConf. However, I am dealing = = with a work emergency all weekend. I'll be starting to build out the = immediate mode layer sometime later this week. You can follow all progress on GitHub here: = https://github.com/auroragraphics/ -- = Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
May 03 2014
next sibling parent reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
 You can follow all progress on GitHub here: 
 https://github.com/auroragraphics/

Ok. Now I know :) Thx.
May 03 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2014-05-03 at 22:34 +0000, "Nordlöw" via Digitalmars-d wrote:
 You can follow all progress on GitHub here: 
 https://github.com/auroragraphics/

Ok. Now I know :)

The repository is reported as being empty :-( -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 04 2014
parent Mike Parker <aldacron gmail.com> writes:
On 5/4/2014 4:53 PM, Russel Winder via Digitalmars-d wrote:
 On Sat, 2014-05-03 at 22:34 +0000, "Nordlöw" via Digitalmars-d wrote:
 You can follow all progress on GitHub here:
 https://github.com/auroragraphics/

Ok. Now I know :)

The repository is reported as being empty :-(

All of the work so far is going on in the DX11 repository.
May 04 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Saturday, 3 May 2014 at 19:45:38 UTC, Adam Wilson wrote:
 Yes. There has been progress. I am currently finishing up the 
 DirectX 11 bindings. For now it will include everything but 3D. 
 I am focusing on Windows 2D for the moment because that is the 
 environment I am most familiar with.

Just a word of advice, don't make a big distinction between 2d and 3d. If anything, it should be matrix based, at that point the difference between 2d and 3d is just a different view matrix. This is how most modern hardware accelerated graphics works today. It is fine to have helper functions to do 2d specific tasks later on, but they should be fairly thin.
May 03 2014
prev sibling parent reply "Jonas Drewsen" <nospam4321 hotmail.com > writes:
Just had a quick look at the source code.

If this is to be something like the official gfx library wouldn't 
it make sense to follow the phobos coding style?
For example "struct Size" instead of "struct SIZE"

/Jonas
May 04 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 04/05/14 20:26, Jonas Drewsen wrote:
 Just had a quick look at the source code.

 If this is to be something like the official gfx library wouldn't it
 make sense to follow the phobos coding style?
 For example "struct Size" instead of "struct SIZE"

To me, most code there looks like bindings. -- /Jacob Carlborg
May 04 2014
next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 04 May 2014 23:22:27 -0700, Jacob Carlborg <doob me.com> wrote:

 On 04/05/14 20:26, Jonas Drewsen wrote:
 Just had a quick look at the source code.

 If this is to be something like the official gfx library wouldn't it
 make sense to follow the phobos coding style?
 For example "struct Size" instead of "struct SIZE"

To me, most code there looks like bindings.

Yes. DX11 is just bindings. I've got code for Immediate sitting on my HD that's as yet unpushed. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
May 06 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 04 May 2014 23:22:27 -0700, Jacob Carlborg <doob me.com> wrote:

 On 04/05/14 20:26, Jonas Drewsen wrote:
 Just had a quick look at the source code.

 If this is to be something like the official gfx library wouldn't it
 make sense to follow the phobos coding style?
 For example "struct Size" instead of "struct SIZE"

To me, most code there looks like bindings.

Yes. DX11 is just bindings. I've got code for Immediate sitting on my HD that's as yet unpushed. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
May 06 2014
prev sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sun, 04 May 2014 23:22:27 -0700, Jacob Carlborg <doob me.com> wrote:

 On 04/05/14 20:26, Jonas Drewsen wrote:
 Just had a quick look at the source code.

 If this is to be something like the official gfx library wouldn't it
 make sense to follow the phobos coding style?
 For example "struct Size" instead of "struct SIZE"

To me, most code there looks like bindings.

Yes. DX11 is just bindings. I've got code for Immediate sitting on my HD that's as yet unpushed. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
May 06 2014
prev sibling next sibling parent reply "Bastiaan Veelo" <Bastiaan Veelo.net> writes:
On Saturday, 3 May 2014 at 09:56:38 UTC, Nordlöw wrote:
 Is there any progress on the graphics API Adam Wilson is 
 working on?

Adam Wilson's DConf '14 talk [1] was an interesting and promising one. After that there were some commits a month later, but nothing after that. I haven't seen discussions or other activity on the graphics front since. Now another DConf has passed, and I wonder what happened to Aurora? Were there technical reasons that it hasn't progressed much further, and if so, can these be addressed? [1] https://youtu.be/PRbK7jk0jrk
May 30
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 30/05/2015 10:28 p.m., Bastiaan Veelo wrote:
 On Saturday, 3 May 2014 at 09:56:38 UTC, Nordlöw wrote:
 Is there any progress on the graphics API Adam Wilson is working on?

Adam Wilson's DConf '14 talk [1] was an interesting and promising one. After that there were some commits a month later, but nothing after that. I haven't seen discussions or other activity on the graphics front since. Now another DConf has passed, and I wonder what happened to Aurora? Were there technical reasons that it hasn't progressed much further, and if so, can these be addressed? [1] https://youtu.be/PRbK7jk0jrk

To my knowledge, it was just too large of a project so was abandoned.
May 30
parent reply "Bastiaan Veelo" <Bastiaan Veelo.net> writes:
On Saturday, 30 May 2015 at 10:29:44 UTC, Rikki Cattermole wrote:
 On 30/05/2015 10:28 p.m., Bastiaan Veelo wrote:
 On Saturday, 3 May 2014 at 09:56:38 UTC, Nordlöw wrote:
 Is there any progress on the graphics API Adam Wilson is 
 working on?

Adam Wilson's DConf '14 talk [1] was an interesting and promising one. After that there were some commits a month later, but nothing after that. I haven't seen discussions or other activity on the graphics front since. Now another DConf has passed, and I wonder what happened to Aurora? Were there technical reasons that it hasn't progressed much further, and if so, can these be addressed? [1] https://youtu.be/PRbK7jk0jrk

To my knowledge, it was just too large of a project so was abandoned.

But was it a conscious decision to drop it, or did it just die? Would different design decisions have made a difference? What are the lessons that can be learned from Aurora for any future graphics initiatives?
May 30
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 31/05/2015 1:18 a.m., Bastiaan Veelo wrote:
 On Saturday, 30 May 2015 at 10:29:44 UTC, Rikki Cattermole wrote:
 On 30/05/2015 10:28 p.m., Bastiaan Veelo wrote:
 On Saturday, 3 May 2014 at 09:56:38 UTC, Nordlöw wrote:
 Is there any progress on the graphics API Adam Wilson is working on?

Adam Wilson's DConf '14 talk [1] was an interesting and promising one. After that there were some commits a month later, but nothing after that. I haven't seen discussions or other activity on the graphics front since. Now another DConf has passed, and I wonder what happened to Aurora? Were there technical reasons that it hasn't progressed much further, and if so, can these be addressed? [1] https://youtu.be/PRbK7jk0jrk

To my knowledge, it was just too large of a project so was abandoned.

But was it a conscious decision to drop it, or did it just die? Would different design decisions have made a difference? What are the lessons that can be learned from Aurora for any future graphics initiatives?

From what I can tell, just not enough man power so it just stopped. But the lesson is pretty simple. Start small and dream big. What I'm saying is we really don't have the basic infrastructure for such an amazing project. One day, just not today. Great example, if you wanted to play some music cross platform what D library what you use? Hint good luck, none really exist. What about window creation? Well Devisualization.Window (author) but what would about integration into OSX's menu or Windows notification area? Again you've got a problem.
May 30
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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. ;-)=
May 30
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
May 30
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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. ;-)

=20 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,=20 for example. ;-)=
May 30
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
May 30
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 31 May 2015 02:35:22 +1200, Rikki Cattermole wrote:

 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.

while you are right about windows GDI, with GNU/Linux you can find, for=20 example, wayland or DirectFB setup without X11 emulation layer at all. so=20 assuming that X11 is always there is not exactly right.
 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.

installing wide-known libraries is very easy on most modern OSes. the=20 biggest mistake community can do is start rewriting *everything* in D for=20 the sake of "some user might need that so we have to have that, written=20 in D". that is what C interop does: allows us to reuse already written=20 and debugged code. but i can agree that more wrappers and more system API coverage in=20 distribution bundle will be fine. now, for example, one can't do more or=20 less serious windows programming with DMD "out of the box". *that* is the=20 problem, not absense of some 3rd-party library.=
May 30
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 31/05/2015 9:56 a.m., ketmar wrote:
 On Sun, 31 May 2015 02:35:22 +1200, Rikki Cattermole wrote:

 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.

while you are right about windows GDI, with GNU/Linux you can find, for example, wayland or DirectFB setup without X11 emulation layer at all. so assuming that X11 is always there is not exactly right.

In most cases it is and will be for a while yet. Although you are right in saying it should also support others.
 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.

installing wide-known libraries is very easy on most modern OSes. the biggest mistake community can do is start rewriting *everything* in D for the sake of "some user might need that so we have to have that, written in D". that is what C interop does: allows us to reuse already written and debugged code. but i can agree that more wrappers and more system API coverage in distribution bundle will be fine. now, for example, one can't do more or less serious windows programming with DMD "out of the box". *that* is the problem, not absense of some 3rd-party library.

I agree completely, but we do need good abstractions in e.g. phobos that we all agree upon. It doesn't matter what implementations go in however. As long as there is enough for out of the box experience.
May 30
prev sibling parent reply "lobo" <swamplobo gmail.com> writes:
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
May 30
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
May 30
parent reply "lobo" <swamplobo gmail.com> writes:
On Sunday, 31 May 2015 at 02:14:53 UTC, Rikki Cattermole wrote:

 You're missing a large part of what I'm saying.

I understand what you're saying, I just disagree ;) I'd argue well tested and maintained dependencies are more important than what language they are written in.
 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.

s/bindings/wrapper/ Sorry, I should be more specific, but as I said in my earlier post; slap a nice D interface over the top of the C library. In D this is trivial.
 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.

Again, I wonder why would you reimplement what you get from libpng? Think of all the real world tests, tweaks and optimization you're throwing away by not using libpng. As for libcurl, well if a pure D curl impl is written for Phobos it will be 100s to 1000s of additional LOC that require testing and maintaining. The effort of that alone would be greater than what is currently required from Phobos devs and end-users with a 'C' dependency. If dub supported compiling C that would be awesome for my own bindings/wrappers. bye, lobo
May 30
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 31/05/2015 4:46 p.m., lobo wrote:
 On Sunday, 31 May 2015 at 02:14:53 UTC, Rikki Cattermole wrote:

 You're missing a large part of what I'm saying.

I understand what you're saying, I just disagree ;) I'd argue well tested and maintained dependencies are more important than what language they are written in.
 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.

s/bindings/wrapper/ Sorry, I should be more specific, but as I said in my earlier post; slap a nice D interface over the top of the C library. In D this is trivial.
 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.

Again, I wonder why would you reimplement what you get from libpng? Think of all the real world tests, tweaks and optimization you're throwing away by not using libpng. As for libcurl, well if a pure D curl impl is written for Phobos it will be 100s to 1000s of additional LOC that require testing and maintaining. The effort of that alone would be greater than what is currently required from Phobos devs and end-users with a 'C' dependency. If dub supported compiling C that would be awesome for my own bindings/wrappers. bye, lobo

I think you are thinking of it a little too much as being mutually exclusive. It's not. There is no reason not to use e.g. libpng for an image implementation. But the important thing atleast for phobos is to have an out of the box will work for most people implementation. Dub would be the amazing way to distribute more image format implementations. So it would be opt-in for e.g. libpng. I'm atleast trying to hit a middle ground to make everyone happy. A nice interchangeable image interface, some common image implementations ready to go and of course the ability to add better implementations on the fly. It's a lot better then the alternatives. Where by you must know the type to use the format or you must have c libraries to make it of any use at all.
May 30
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 31 May 2015 at 04:46:51 UTC, lobo wrote:
 Again, I wonder why would you reimplement what you get from 
 libpng?

I've actually had people ask me what magic I did with my png.d because it often generates smaller files than libpng. It is easier to use an leaving out unnecessary bits made it faster and more efficient! (for our use cases, the full lib is surely useful for other cases) The thing with those libraries is they do everything, which makes them bigger and more complex. There's a place for that, sure, but it isn't necessarily better.
 As for libcurl, well if a pure D curl impl is written for 
 Phobos it will be 100s to 1000s of additional LOC that require 
 testing and maintaining.

Fun fact: curl is actually pretty buggy... and a pain to use too. I like it and use it for a lot of things, but I also replaced it (and again, like with the png, a lot of the things it does aren't necessary for me anyway)
May 30
parent reply "lobo" <swamplobo gmail.com> writes:
On Sunday, 31 May 2015 at 05:17:27 UTC, Adam D. Ruppe wrote:
 On Sunday, 31 May 2015 at 04:46:51 UTC, lobo wrote:
 Again, I wonder why would you reimplement what you get from 
 libpng?

I've actually had people ask me what magic I did with my png.d because it often generates smaller files than libpng. It is easier to use an leaving out unnecessary bits made it faster and more efficient! (for our use cases, the full lib is surely useful for other cases) The thing with those libraries is they do everything, which makes them bigger and more complex. There's a place for that, sure, but it isn't necessarily better.
 As for libcurl, well if a pure D curl impl is written for 
 Phobos it will be 100s to 1000s of additional LOC that require 
 testing and maintaining.

Fun fact: curl is actually pretty buggy... and a pain to use too. I like it and use it for a lot of things, but I also replaced it (and again, like with the png, a lot of the things it does aren't necessary for me anyway)

I know cURL has numerous bugs, I work with them everyday :) But so do many many others and that's partly my point; the majority of bugs are exposed pretty quickly with that many users. I'm also not convinced that a D PNG or cURL (or whatever) implementation, used en masse, wouldn't grow to include all those 'missing' features and end up just as bloated. But now without lots and lots of users to help report all those bugs. Anyway, it's a moot point given that I probably won't ever have the time to really contribute more than bug reports for D ;-) I just finished your book by the way and thought it was a terrific read. Nice work! bye, lobo
May 30
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 31/05/2015 6:56 p.m., lobo wrote:
 On Sunday, 31 May 2015 at 05:17:27 UTC, Adam D. Ruppe wrote:
 On Sunday, 31 May 2015 at 04:46:51 UTC, lobo wrote:
 Again, I wonder why would you reimplement what you get from libpng?

I've actually had people ask me what magic I did with my png.d because it often generates smaller files than libpng. It is easier to use an leaving out unnecessary bits made it faster and more efficient! (for our use cases, the full lib is surely useful for other cases) The thing with those libraries is they do everything, which makes them bigger and more complex. There's a place for that, sure, but it isn't necessarily better.
 As for libcurl, well if a pure D curl impl is written for Phobos it
 will be 100s to 1000s of additional LOC that require testing and
 maintaining.

Fun fact: curl is actually pretty buggy... and a pain to use too. I like it and use it for a lot of things, but I also replaced it (and again, like with the png, a lot of the things it does aren't necessary for me anyway)

I know cURL has numerous bugs, I work with them everyday :) But so do many many others and that's partly my point; the majority of bugs are exposed pretty quickly with that many users. I'm also not convinced that a D PNG or cURL (or whatever) implementation, used en masse, wouldn't grow to include all those 'missing' features and end up just as bloated. But now without lots and lots of users to help report all those bugs. Anyway, it's a moot point given that I probably won't ever have the time to really contribute more than bug reports for D ;-) I just finished your book by the way and thought it was a terrific read. Nice work! bye, lobo

I would recommend you reading png's 1.2 spec[0]. It wouldn't be hard to add the "missing" features as free-functions if done right. [0] http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html
May 31
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 30 May 2015 at 14:28:57 UTC, Rikki Cattermole wrote:
 On 31/05/2015 2:27 a.m., ketmar wrote:
 SDL audio. ;-)

Okay lets ignore libraries that is not D. Like that one.

I think that is unnecessarily limiting. I do see your point about distribution, but using C libraries is a common thing with solutions (packaging the DLLs with you, instructing users to install it, using system package managers, etc.) and their availability is one of D's strengths.
May 30
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 31/05/2015 3:07 a.m., Adam D. Ruppe wrote:
 On Saturday, 30 May 2015 at 14:28:57 UTC, Rikki Cattermole wrote:
 On 31/05/2015 2:27 a.m., ketmar wrote:
 SDL audio. ;-)

Okay lets ignore libraries that is not D. Like that one.

I think that is unnecessarily limiting. I do see your point about distribution, but using C libraries is a common thing with solutions (packaging the DLLs with you, instructing users to install it, using system package managers, etc.) and their availability is one of D's strengths.

As I've already said, out of the box experience should not rely on 3rd party. But nobody is stopping you for using an implementation that does use it ;)
May 30
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 31 May 2015 at 02:16:02 UTC, Rikki Cattermole wrote:
 As I've already said, out of the box experience should not rely 
 on 3rd party.

Rely on, no. But package? Sure. I'd be ok with built-in etc.c.sdl bindings and such. Perhaps dub obsoletes this idea, but if someone is willing to use a C xml lib or sdl or whatever, sufficiently popular (defined simply by "someone took the time to write the bindings and open the PR") libs having bindings in there would be nice in a C-batteries included sense.
May 30
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 31/05/2015 2:38 p.m., Adam D. Ruppe wrote:
 On Sunday, 31 May 2015 at 02:16:02 UTC, Rikki Cattermole wrote:
 As I've already said, out of the box experience should not rely on 3rd
 party.

Rely on, no. But package? Sure. I'd be ok with built-in etc.c.sdl bindings and such. Perhaps dub obsoletes this idea, but if someone is willing to use a C xml lib or sdl or whatever, sufficiently popular (defined simply by "someone took the time to write the bindings and open the PR") libs having bindings in there would be nice in a C-batteries included sense.

The way I view it is (lets use image as example). Phobos would include an abstraction, a set of implementations and creation hooks. The creation hooks would allow converting to and importing certain formats. Basically global AA full of e.g. delegates to do so. Now a dub library could implement the abstractions, register there hooks and wala. You can now read a png image, jpeg or what ever and not really care about the implementation and it just works. But if you need to you could convert it to an SDL image and use it with SDL. So now a very low entry point for new implementations and usages but also a high gain in interoperability between implementations.
May 30
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 30 May 2015 at 13:35:47 UTC, Rikki Cattermole wrote:
 Great example, if you wanted to play some music cross platform 
 what D library what you use? Hint good luck, none really exist.

I'm slowly getting through my simpleaudio.d....
 What about window creation? Well Devisualization.Window 
 (author) but what would about integration into OSX's menu or 
 Windows notification area? Again you've got a problem.

My simpledisplay.d can do the Windows notification area. But there's a lot more that needs to get done that I haven't gotten around to yet. If I can ever quit my day job, I'll start going nuts on this again :)
May 30
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 31/05/2015 3:08 a.m., Adam D. Ruppe wrote:
 On Saturday, 30 May 2015 at 13:35:47 UTC, Rikki Cattermole wrote:
 Great example, if you wanted to play some music cross platform what D
 library what you use? Hint good luck, none really exist.

I'm slowly getting through my simpleaudio.d....
 What about window creation? Well Devisualization.Window (author) but
 what would about integration into OSX's menu or Windows notification
 area? Again you've got a problem.

My simpledisplay.d can do the Windows notification area. But there's a lot more that needs to get done that I haven't gotten around to yet. If I can ever quit my day job, I'll start going nuts on this again :)

I sorta excluded your work on purpose. Even though it is damn good work!
May 30
parent "Bastiaan Veelo" <Bastiaan Veelo.net> writes:
On Sunday, 31 May 2015 at 02:08:30 UTC, Rikki Cattermole wrote:
 On 31/05/2015 3:08 a.m., Adam D. Ruppe wrote:
 On Saturday, 30 May 2015 at 13:35:47 UTC, Rikki Cattermole 
 wrote:
 What about window creation? Well Devisualization.Window 
 (author) but
 what would about integration into OSX's menu or Windows 
 notification
 area? Again you've got a problem.

My simpledisplay.d can do the Windows notification area. But there's a lot more that needs to get done that I haven't gotten around to yet. If I can ever quit my day job, I'll start going nuts on this again :)

I sorta excluded your work on purpose. Even though it is damn good work!

Should any of these be on http://wiki.dlang.org/List_of_Libraries_and_Frameworks?
Jun 01
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
Maybe it would be a good idea for someone to take a closer look 
at Google's Mojo and Sky which is for writing portable GUIs:

https://github.com/domokit/mojo
https://github.com/domokit/sky_sdk

Seems to have the right kind of scope to be doable as an 
open-source D project.
May 31