Sugesting the possibility to define path parameter instead of the old way

[tudborg]

Sugesting the possibility to define path parameter instead of the x1,y1 -> x2,y2 -> x3,y3 way.
Old way still supported, and will be used if path is undefined.

[tudborg]

This is debug. Write it out ofc.

[austinbv]

Another way I think would be cool I can implement if needed is to take just an args list as a splat and all even indexes of the args will be x values all odd will be y

So something like this

path(1,2,1,3,1,4,1,5)

That could be split and handled really cleanly

[caleb531]

I could do that, but I'm still not sure. I've been thinking about how to
best implement this. If I implement this, it would only be available to
drawLine(), while not available to the other path methods (drawQuad() and
drawBezier()). If I did implement the same functionality for those methods,
I'd have to give and document a specific order for the values, which is
somewhat contradictory to what makes jCanvas so easy and usable (the
principle that order does not matter in jCanvas).

Currently, you already can construct the object with a loop:

var obj = {
strokeStyle: "#000",
strokeWidth: 10
};
for (i=1; i<10; i+=1) {
obj["x" + i] = i_10;
obj["y" + i] = i_i;
}
$("canvas").drawLine(obj);

So if I did implement this, you'd have to construct the array/object for
whatever values you use anyway.

I hope you understand; It's an interesting idea; I just need more time to
think over how I'd go about this. By all means, feel free to correct me or
enlighten me if I misunderstood your point.

-Caleb

On Tue, Nov 22, 2011 at 5:22 PM, Austin <
reply@reply.github.com

wrote:

Another way I think would be cool I can implement if needed is to take
just an args list as a splat and all even indexes of the args will be x
values all odd will be y

So something like this

path(1,2,1,3,1,4,1,5)

That could be split and handled really cleanly

---

Reply to this email directly or view it on GitHub:
#1 (comment)

[austinbv]

Honestly why not have a convient line method, even if it's not portable to all the other methods it makes one just that much easier to use

[tudborg]

I actually have to agree with caleb on this one. If you really need a convenient line method, you could implement it yourself. If it is not usefull for the entire library, then why add it?
Also, the (x,y,x,y,x,y,x,y.....) argument style seems a little dirty to me. But that is a matter of opinion i guess.

[austinbv]

I just like the option to structure params depending on how your application needs. I have no problem doing what I need in a fork, just throwing my 2cents in on a great plugin.

On Nov 27, 2011, at 3:57 AM, Henrik Tudborgreply@reply.github.com wrote:

I actually have to agree with caleb on this one. If you really need a convenient line method, you could implement it yourself. If it is not usefull for the entire library, then why add it?
Also, the (x,y,x,y,x,y,x,y.....) argument style seems a little dirty to me. But that is a matter of opinion i guess.

---

Reply to this email directly or view it on GitHub:
#1 (comment)