Questions / comments / feedback of any kind would be great, and will only help us make the project stronger.
However, except for a few examples (which look like convenience methods), I don't see anything that tells me what specifically this is for or how my code would benefit.
[2] https://github.com/mpw/MPWDrawingContext
[3] http://blog.metaobject.com/2012/06/pleasant-objective-c-draw...
The cosmos tutorial (www.c4ios.com/cosmos) is an end-to-end tutorial for building an app with C4. We are converting a lot of examples from V1 and are currently building new examples / tutorials, all of which will help with understanding what C4 can do and how it can be used.
We are always looking for improved ways to explain C4 and its benefits. We definitely welcome feedback from the community on how to improve our messaging.
As for MPWDrawingContext, it looks like a nice wrapper around CGContextRef. C4 sets itself apart because it handles interactivity (gestures, etc.) and audio / video. You can draw / animate, and build fully interactive interfaces.
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.
Our goal is to have C4 make life easier for people: 1) those who are interested in learning UIKit can start with C4 and dig into its open-source base to gain more transferable skills, 2) those who are not interested in learning UIKit or transferable skills but just want to put something together fast, 3) people who already know UIKit / Core Animation but don’t want to deal with some of the complexity.
MOAI is a cross-platform Game-engine/GUI-toolkit designed tot allow pretty fast depiction of games/GUI interfaces, specifically game-like interfaces. It is very easy to get a working game environment, of most of the most common forms, in 20 or 30 lines of code in MOAI, i.e. Pong, jump'n'run, shooter, etc.
On top of that, there are already 3rd-party frameworks which implement some sets of standardized "GUI" basics like sliders and buttons and scrolling scenes, and so on. So its possible to do a common GUI that runs exactly the same on all platforms - i.e. ignore native entirely and boldly forge ones own ecosystem of standards.
Which is actually kind of nice, to be honest.
So I'm wondering about the C4 side of things and your plans to embrace/wrap/extend the GUI world. Will you be a subscriber to the native world - and thus either have to do a lot of native host code (or find some way to make your developer-users responsible for the problem) - or do you think there is a future in non-native/runs-everywhere GUI development beyond that provided 'by the majors'?
I'm going to put C4 on the lab-bench some time in the next few days, looking forward to checking it out ..
Got the the site - got a frozen page with the above tagline against gray background for few seconds, then a very choppy video started to play. Couldn't make it past the second pageful, because the page had a massive lag scrolling and it was ultimately unusable.
Perhaps have a lighter version with just the content and no bells or whistles?
I know Firefox's implementation makes this its fault, but come on, it doesn't hurt to test the home page in it.
let bananaName = “Jimmy”.banana
After looking at your c4's different github repos, it appears you've started some c4 stuff for OS X as well. I'd be interested in this framework if some resources went into the OS X side as well.
Everyone is welcome to join: https://join-c4.herokuapp.com
