| > As for MPWDrawingContext, it looks like a nice wrapper around CGContextRef. Exactly (for now). It has a clear problem statement (the functionality is great but the API is awful) and then demonstrates how it solves the problem. > C4 sets itself apart because it handles interactivity (gestures, etc.) and audio / video.
> You can draw / animate, and build fully interactive interfaces. That cannot be what sets C4 apart, because the APIs that C4 is built on top of let you do all of these things. It's as if I wrote that what sets MPWDrawingContext apart is that it lets you draw beautiful graphics. While it is true that you can draw beautiful graphics with MPWDrawingContext, you can draw those same beautiful graphics with CGContext, so that is not the distinguishing feature. The distinguishing feature is that doing so is just much more painful with CGContext and much more pleasant with MPWDrawingContext. Framing it this way makes it immediately clear whether you might want to look at MPWDrawingContext (you don't find the CG API very pleasant to use) and helps you evaluate it (looks more pleasant to me, I'll give it a try vs. that looks worse than CG, close the window). For C4, the first guess is that it's like Processing, but then I see that there's no interactive app, which to me is the key distinguishing feature of Processing. Since you don't currently have an interactive app, my guess would be that you are saying you have libraries that are "Processing-like", is that correct? I personally always thought those particular libraries were fairly nondescript/generic graphics libraries, so possibly that's what I don't understand and maybe what you might need to explain. The two examples you have on the home page don't make a very compelling case for the fairly grand claims, width vs. size.width is at best questionable, and CA/UIKit have both implicit and block-based animations that look just as good as the example you give. |
C4 address many issues across a variety of frameworks, while at the same time tries to make working across those frameworks feel more consistent. This makes a clear problem statement more difficult to nail down, but we’re definitely trying to find that description. For example, in my practice I use C4 for commercial work (building apps for clients), I use it for experiments, I build artworks with it, I teach / lead workshops, I have made print works with it, and a lot more. Describing C4 as a “drawing tool” or “wrapper around UIKit and Core Animation” would do the project disservice because its intention is to be bigger than that.
> That cannot be what sets C4 apart, because the APIs that C4 is built on top of let you do all of these things.
You raised the point about MPWDrawingContext to which my response was aimed, C4 can handle interaction / media / etc. where it seems MPWDC cannot. I fully acknowledge that C4 is built on top of frameworks that handle animation and interaction, and didn’t mean to imply that it sets itself apart from UIKit, Core Animation, etc.
> For C4, the first guess is that it's like Processing
C4 is definitely inspired by Processing and OpenFrameworks, I used both of those projects extensively in the past. I learned immensely from both of them and I hope that C4 will provide the same kinds of opportunities for other people.
> ...but then I see that there's no interactive app, which to me is the key distinguishing feature of Processing. Yes, the app is a fantastic tool for working with Processing, learning the language, exploring examples and building projects. However, you can use Processing outside of its app. Similarly, OpenFrameworks is very Processing-like, yet it doesn’t have an app either, and that doesn’t limit the project.
> Since you don't currently have an interactive app, my guess would be that you are saying you have libraries that are "Processing-like", is that correct?
Yes. But they’re also UIKit, Core Animation and AVFoundation-like as well, so claiming C4 is only Processing-like would be misleading.
> I personally always thought those particular libraries were fairly nondescript/generic graphics libraries, so possibly that's what I don't understand and maybe what you might need to explain.
From a software architecture perspective you might be right, but the purpose of those projects are bigger than their apis / libraries. The point is to enable people who would otherwise be unable to use programming for creative expression, and to promote “software literacy within the visual arts and visual literacy within technology.”