This is an inserting question in general, first for the specific:

I took a quick look at the code:

type Color

Then Colors.jl seemed overkill and maybe not with what you wanted, seems 
ColorTypes.jl is it (split off from Colors.jl?); and it by default uses 
floating-point, but I also see:

typealias U8 UFixed8


RGB24(r::UFixed8, g::UFixed8, b::UFixed8) = _RGB24(reinterpret(r), 
reinterpret(g), reinterpret(b))


`ARGB32` uses a `UInt32` representation of color,

[I didn't see RGBA, only alpha in upper bits.. so unless I overlooked, may 
not work, since bits not in the same order:]

So you're thinking if you can have a wrapper that does:

" reinterpret(type, A)

    Change the type-interpretation of a block of memory. [..]"

for the 32-bit pixel values?

Maybe you can do just that without any wrapper, if that is only needed, to 
get the new type-name (assuming you can and there are no name classes with 
importing two packages that define say Color..)?

B. If you want a new wrapper, then in essence you have a new API, and I'm 
not sure it's advised (or to fork the library..) here (or in general); most 
would not know of the other API and/or understandably assume the official 
wrapper is the best.. If you could change the API in SFML.jl (in 
cooperation with the author), I guess that is best. Then you brake code for 
others (unless you that packages keeps two APIs, at least for a while).


On Friday, August 26, 2016 at 8:10:33 AM UTC, jw3126 wrote:
> I want to use a julia package (SFML.jl), which defines its own types for 
> lots of basic things like 2d vectors, rectangles colors etc. 
> It would be cool however if one could use its functionality with "standard 
> types", like colors from Colors.jl, StaticArrays.jl vectors, 
> GeometryTypes.jl rectangles etc.
> Now SFML.jl is an interface to the C++ library SFML with zero julia 
> dependencies and its types mirror that of SFML. So I guess changing SFML.jl 
> is not the way to go here. Instead I am thinking about wrapping SFML.jl 
> such that function inputs and outputs are automatically converted between 
> "standard types" and "SFML.jl types.
> I guess using meta-programming it should be possible to loop over all 
> methods defined in SFML.jl and compose them with the appropriate 
> conversions? Is this the way to go? Is there an example, where such a thing 
> was applied to another package?

Reply via email to