Hotcocoa Graphics

[benilovj]

Mark, what are your thoughts on removing the hotcocoa/graphics classes from hotcocoa?

The code seems to have been forked and developed further here (https://github.com/drtoast/macruby_graphics) and I'm not sure whether logically these classes make sense within hotcocoa.

[ferrous26]

Actually, I was planning to merge updates into HotCocoa.

While the code has been forked from HotCocoa, it seems to have been abandoned. The classes don't fit HotCocoa like a glove, in fact, some of it contradicts HotCocoa mappings; but I think they still simplify working with (Core)Graphics and still fit the overall goal of HotCocoa.

@mattetti, could shed some light on what happened with hotcocoa/graphics?

I think whether or not graphics is worth keeping is up for debate still, but I am leaning towards keeping it around, even though it will take work to make it work smoothly with the rest of HotCocoa.

[benilovj]

mm, you may be right, I've just had a look on rubygems.org and couldn't even find anything to suggest that macruby_graphics has been released as a gem.

[mattetti]

The reason why I extracted back the Graphics abstraction layer is because I don't want HotCocoa to be a hard dependency to use the Graphics helpers. I used the lib in many XCode based projects and having to use rubygems and load all of HotCocoa is just unacceptable to me.

On Oct 16, 2011, at 13:48, Mark [email protected] wrote:

Actually, I was planning to merge updates into HotCocoa.

While the code has been forked from HotCocoa, it seems to have been abandoned. The classes don't fit HotCocoa like a glove, in fact, some of it contradicts HotCocoa mappings; but I think they still simplify working with (Core)Graphics and still fit the overall goal of HotCocoa.

@mattetti, could shed some light on what happened with hotcocoa/graphics?

I think whether or not graphics is worth keeping is up for debate still, but I am leaning towards keeping it around, even though it will take work to make it work smoothly with the rest of HotCocoa.

Reply to this email directly or view it on GitHub:
https://github.com/ferrous26/hotcocoa/issues/33#issuecomment-2422962

[mattetti]

That is correct, I don't think anyone released it as a gem, I don't think that would be a problem tho. The fact is just that I don't use rubygems for the large majority of my Cocoa projects, so I never bothered creating a gem, same thing for my other libs.

On Oct 16, 2011, at 13:51, Jake [email protected] wrote:

mm, you may be right, I've just had a look on rubygems.org and couldn't even find anything to suggest that macruby_graphics has been released as a gem.

Reply to this email directly or view it on GitHub:
https://github.com/ferrous26/hotcocoa/issues/33#issuecomment-2422979

[ferrous26]

Thanks for the input, Matt.

I guess you are referring to the overhead during development? After deployment rubygems doesn't factor into things and you don't need to load the rest of hotcocoa to load graphics, but having to hotcocoa take up space in the app bundle and not being used is annoying.

Hmmm...

[mattetti]

What do you mean by "After deployment rubygems doesn't factor into
things", don't you still need to load rubygems to require bundle gems?
(I haven't checked the latest deployment scripts).
But yes, having hotcocoa sitting there in your app when you don't need
really need it, isn't optimum. I'd prefer a more modular approach.

On Sun, Oct 16, 2011 at 6:01 PM, Mark Rada
[email protected]
wrote:

Thanks for the input, Matt.

I guess you are referring to the overhead during development? After deployment rubygems doesn't factor into things and you don't need to load the rest of hotcocoa to load graphics, but having to hotcocoa take up space in the app bundle and not being used is annoying.

Hmmm...

Reply to this email directly or view it on GitHub:
https://github.com/ferrous26/hotcocoa/issues/33#issuecomment-2424010

[ferrous26]

You should not need to require rubygems to load bundled gems. The deploy script simply copies the lib dirs from the gem into the site_ruby directory so that the files show up in the default LOAD_PATH.

A more modular approach sounds nice, but since you can only add graphics by using a git submodule or manually copying the code to your project, it is less than ideal. Hmm....