gavioto / playn

Automatically exported from code.google.com/p/playn
0 stars 0 forks source link

move graphics.createPath() to convas.createPath() #140

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
When I have methods that do painting on canvases, I can't paint paths because I 
have to have a graphics to create one.

Why?

What is the expected output? What do you see instead?
I can create a path with only a canvas at hand.

What version of the product are you using? On what operating system?
1.1

Original issue reported on code.google.com by alexande...@gmail.com on 22 Feb 2012 at 2:02

GoogleCodeExporter commented 9 years ago
I don't know what is the problem using graphics...

You just have to import the "playn.core.PlayN" class and use the static method 
"PlayN.graphics()" to retrieve the instance... You don't need to set the 
graphics instance as a parameter of your method, just make a call to 
"PlayN.graphics()" and that's it :)

Original comment by mbarbe...@gmail.com on 22 Feb 2012 at 7:41

GoogleCodeExporter commented 9 years ago
Yeah, right.
The long story is, I have tweaked the framework a bit to be able to have more 
than one instance of PlayN-app on one page. (*cough*) For that I tried to 
bypass the static PlayN all the way and it works quite well.

So my feature request is a special one, I agree. On the other hand, I think it 
makes more sense if it was placed in Canvas.

Original comment by alexande...@gmail.com on 22 Feb 2012 at 7:50

GoogleCodeExporter commented 9 years ago
(Duplicated from mailing list post, for posterity.)

Given that the only use of Path is in Canvas, and that I can't really imagine a 
scenario where Path might be used elsewhere in the future (it's not likely to 
be usable by Surface or any GL-backed abstraction), I agree that it's a 
reasonable change.

Unless I hear objections or good arguments to the contrary, I'll 
Canvas.createPath and deprecate Graphics.createPath.

Original comment by samskiv...@gmail.com on 22 Feb 2012 at 8:22