One thing to consider, since I was impacted by this when writing a WPF app a while back, is the difference between a 2-Vector and a Point.  In particular, Vectors typically have some very useful methods on them, like addition, rotation, transformations, etc. which frequently are not associated with the Point type.  I don't know if you have or plan to support this data type, but at least having simple transforms to/from Vector would be nice.<div>
<br></div><div>- Cliff<br><br><div class="gmail_quote">On Sat, Apr 9, 2011 at 5:58 PM, Adam D. Ruppe <span dir="ltr"><<a href="mailto:destructionator@gmail.com">destructionator@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">bearophile wrote:<br>
> The length=150 too is better to be set as immutable.<br>
<br>
</div>Yeah, I made that change after copy/pasting the code into my<br>
newsgroup post. win, painter, angle, and angular velocity were<br>
the only things left mutable in the end.<br>
<div class="im"><br>
> The delegate inside eventLoop doesn't need the ().<br>
<br>
</div>I put it there for consistency with other events. While there<br>
are no other handlers in this example, there can be, and all the<br>
other ones take arguments.<br>
<div class="im"><br>
> Color(255, 255, 255) ==> Color.white<br>
</div>> painter.clearAll(Color.white)<br>
<div class="im">> auto win = new SimpleWindow(512, 512, "Pendulum");<br>
<br>
</div>Yeah, those are reasonable.<br>
<div class="im"><br>
> win.eventLoop(10, {...})  does this semantics work with more than<br>
> one window too?<br>
<br>
</div>I believe so, yes, but I haven't tried it and wouldn't mind if<br>
it didn't. If you need to use multiple windows at the same time,<br>
it'd probably be better to use DFL, DWT, GTK, Qt, etc. etc.<br>
<div class="im"><br>
> drawRectangle => rectangle or even "box"<br>
<br>
</div>Heh, I used to call it box in my DOS programs. But, the functions<br>
it forwards to are called Rectangle() and XDrawRectangle(), so<br>
I want to be consistent with them so it's not a surprise to<br>
someone already familiar with with the other APIs.<br>
<br>
The reason I went with drawShape instead of just Shape is that<br>
functions are verbs, so generally, I like their names to be<br>
verbs too. There's exceptions, of course, but I don't these<br>
fit.<br>
<br>
> outline => pen?<br>
<br>
Pens do more than just color. I guess the real question is how<br>
complex should it be able to get?<br>
<br>
In the underlying APIs, you can make a pen with a color, a<br>
width, and a style (solid, dashed, etc). Since they both can<br>
do it, I think I will add it.<br>
<br>
(Some more advanced APIs can even do things like gradient pens. I<br>
hope the image manipulation functions we write will eventually<br>
be able to do this too, but since plain old X can't, it won't<br>
happen for the display painter.)<br>
<br>
Perhaps:<br>
<br>
painter.pen = Pen(Color(r, g, b), 1, Pen.Style.solid);<br>
<br>
(Or maybe new Pen()... have to think about that.)<br>
<br>
And offer an overload for the simple case where you only care<br>
about color. (or keep the current fillColor property.)<br>
<br>
Then, of course, something similar for Brush, which is used<br>
to fill the background.<br>
<br>
But, here, the idea was to keep it simple, so I went with just<br>
color. I guess that might be too simple.<br>
<div class="im"><br>
> This is not so nice...<br>
<br>
</div>I'm sympathetic, but I don't agree losing the struct would be good.<br>
<br>
Even if the struct proves to be unnecessary (which it might be - I<br>
think you can hold on to a window HDC as long as you like, but it's<br>
not something I see often so I think it's discouraged), I'd still<br>
keep it.<br>
<br>
Having an automatic constructor and destructor available gives<br>
some flexibility on the implementation side without inconveniencing<br>
the user beyond a single function.<br>
<br>
For example, the implicit double buffering done here. You don't<br>
have to think about flipping it. It just works. Better yet, the<br>
implementation can disable it at will. BitBlt is slow over Remote<br>
Desktop on Windows, making double buffering laggy. But, you, the<br>
user, don't really need to know that, since it wasn't your problem<br>
in the first place. The ScreenPainter can make it's own decision<br>
about it.<br>
<div class="im"><br>
> Reading keyboard chars, and mouse clicks & movements is very<br>
> useful.<br>
<br>
</div>For that, you can pass other handlers to eventLoop. I still intend<br>
to define a few more you can use.<br>
<div class="im"><br>
> Another useful thing is to plot a matrix of rgb or int or ubyte<br>
> in grey shades, to speed up some basic usage. In PyGame/Numpy<br>
> there is surfarray for this.<br>
<br>
</div>Sounds like what you'd use the Image class for, so I think we're<br>
good on that too.<br>
<br>
<br>
====<br>
<br>
A note: since I posted last, I changed my mind on something, and<br>
bearophile, I rather doubt you'll like it...<br>
<br>
Before, it was drawRectangle(int x1, int y2, int width, int height);<br>
<br>
Now, it is drawRectangle(Point upperLeft, Size size);<br>
<br>
So, at the usage, you now need to put in some more parenthesis<br>
and say what you mean:<br>
<br>
painter.drawRectangle(Point(0, 0), Size(win.width, win.height));<br>
<br>
<br>
Why did I do this? Well, consider the following:<br>
<br>
drawRectangle(int x1, int y1, int x2, int y2);<br>
<br>
(This is, in fact, the signature in Windows GDI, whereas Xlib<br>
 user width/height.)<br>
<br>
<br>
The types there are no different than the above, but meaning has<br>
changed. I'd be ok with saying "RTFM" to avoid having to use<br>
the structs.<br>
<br>
But, RTFM doesn't let you overload it, whereas the types do. Now,<br>
it can offer both<br>
<br>
drawRectangle(Point upperLeft, Size size);<br>
<br>
*and*<br>
<br>
drawRectangle(Point upperLeft, Point lowerRight);<br>
<br>
I'm sure you were thinking about named arguments for a moment<br>
there about width/height vs x2/y2. I did too. But, named arguments<br>
don't really exist in D (you can do them via library magic but not<br>
without) so it's moot, and I don't believe named arguments would<br>
offer the overloading possibilities, which I like. It can save<br>
some math while being quite natural.<br>
<br>
The Point struct also makes drawPolygon look a lot better, so<br>
it's of general use.<br>
</blockquote></div><br></div>