Adam D. Ruppe: > I believe so, yes, but I haven't tried it and wouldn't mind if > it didn't. If you need to use multiple windows at the same time, > it'd probably be better to use DFL, DWT, GTK, Qt, etc. etc.
It's better to support multiple windows, otherwise you have to split the single window "manually" if you want a window with a simulation and a window with a graph about the simulation. > Heh, I used to call it box in my DOS programs. But, the functions > it forwards to are called Rectangle() and XDrawRectangle(), so > I want to be consistent with them so it's not a surprise to > someone already familiar with with the other APIs. I don't agree. line(), box(), circle(), etc are so easy to remember and common that I don't see the need to keep the names of the functions under them. > The reason I went with drawShape instead of just Shape is that > functions are verbs, so generally, I like their names to be > verbs too. There's exceptions, of course, but I don't these > fit. I don't agree. It's _very_ easy to understand that p.line() is to add a line, there is no chance of confusion here, the verb of p.drawLine() is implied. > But, here, the idea was to keep it simple, so I went with just > color. I guess that might be too simple. In this module shaded pens are less important than usage simplicity. I suggest to keep things simple here. > A note: since I posted last, I changed my mind on something, and > bearophile, I rather doubt you'll like it... I think it's acceptable :-) ---------------------------- > This one's use of recursion caused me to hit what I think is a > compiler bug. Not in the recursion itself, but in a struct's > copy constructor when it had a significant mixin. Where is the updated display module? This doesn't seem to be updated yet: http://arsdnet.net/dcode/simpledisplay.d In your little program drawTree() is better "static" (or better, moved out of the main). window.eventLoop(0, (dchar){ window.close(); }); ==> Default arguments? window.eventLoop(); > Comparing to the Python version, mine is a little shorter, PyGame is also quite more powerful than your simpledisplay module, you can write small video games with it. So its API is a little more complex. > All in all, I'm very happy with this approach so far. It's simple, > it's short, it's readable, it's reasonably efficient, and the > implementation is moderately lean. Everything I was hoping for! Before freezing the API design I suggest to implement many more quite different examples. Designing APIs is something that can't be done in a hurry :-) Two features are quite important: Mouse position, mouse clicks, keys pressed: http://processingjs.org/learning/topic/pattern Text: http://processingjs.org/learning/topic/tickle --------------- Few more useful features for later: Transparency: http://processingjs.org/learning/topic/follow2 Antialiasing: http://processing.org/learning/topics/penrosetile.html Polygons, curves: http://processing.org/learning/topics/softbody.html Image loading: http://processingjs.org/learning/topic/blur Save screen: http://processing.org/learning/topics/saveoneimage.html Sprites: http://processing.org/learning/topics/unlimitedsprites.html Bye, bearophile
