Think about using colour.Color instead of the color class I wrote.

[kalekundert]

No description provided.

[benmoran56]

Sorry to just jump in here, but I've been following glooey for a while, and think it's a great project. One of dislikes, however, is the number of external dependencies. This is just my personal opinion, but I feel that glooey would be awesome if it could be used in a drop-in fashion. I think this complements pyglet's batteries included approach.

From a technical side, what do you think is missing from your own class that would benefit from the colour module? And on a related note, it would be nice if the color attributes could mimic the 3 or 4 tuple style that pyglet uses. I think it would feel more natural for people used to the way pyglet sets colors.

-Ben

[kalekundert]

No worries. I haven't thought much about this at all, I just saw that Color class while I was looking for something else on PyPI, and I generally try to use external packages where I can, because they simplify my code and they're often more well thought out than what I would write anyway. (Clearly we have different philosophies on external packages 😃)

In this case, my thoughts were that colour.Color could be a drop-in replacement for my class, plus it would add support for HSL colors. It would also be tested (presumably), which my Color class currently isn't. Small benefits, but from my perspective they were basically for free.

I'm glad you pointed out that external dependencies are inconvenient for some people, so it's not really for free. I'll keep that in mind. In any case, at the moment I'm just trying to finish the documentation so I can start advertising the library, so I probably won't make any changes like this in the near future.

And on a related note, it would be nice if the color attributes could mimic the 3 or 4 tuple style that pyglet uses.

I'm not totally sure what you mean by this. Glooey should accept 3- or 4-tuples anywhere it expects a color, and you can get a tuple for any color via Color.tuple. Is this what you meant? Or were you suggesting that the color class should try to mimic the tuple interface a little (e.g. by adding methods like __getitem__ and __iter__)?

[benmoran56]

Ah, sorry I completely missed the from_x_tuple methods in your Color class.

About dependencies, I actually do agree with you. It's only for libraries that I make an exception, because I feel that they work best as standalone, and that it's OK to duplicate a bit of code when it's necessary to achieve that. I like your drop-in replacement idea.

On the topic of promotion, I'm currently in the middle of cleaning up the pyglet documentation (I'm one of the contributors). I was thinking to add a section, such as "Projects using pyglet", or "Useful libraries". If you like, we can add glooey as well. Basically, just a name, link, and few sentence description.

[kalekundert]

The drop-in replacement seems like a good approach. When/if I get around to it, I'll do that.

Yeah, I've been paying attention to that while lurking on the pyglet mailing list. I'd love to have glooey included in a list of projects using pyglet!