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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015
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 2015