This is an inserting question in general, first for the specific: A. I took a quick look at the code:
https://github.com/zyedidia/SFML.jl/commit/2e6ebee0a6dca85486563ea6f99decc595e831fa type Color r::Uint8 g::Uint8 b::Uint8 a::Uint8 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 and: https://github.com/JuliaGraphics/ColorTypes.jl/blob/be848d6777c71ef36a619be7218083183d0f0d7e/src/types.jl#L269 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: http://docs.julialang.org/en/release-0.4/stdlib/arrays/?highlight=reinterpret " 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). -- Palli. 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? >
