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.
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.
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
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 ..
I definitely think there’s a future for non-native, but right now the lock on hardware drives the current climate of software development (for mobile). The current animation/media/interaction core of C4 is just a first step towards a lot of other integrations, add ons and components that we want to build out. So, for now I’m a subscriber to native because I think that it’s still a lot of work to build out C4 to something mature and stable for a single platform.
> Looking forward to hearing your experiences with using C4 for the first time.
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.”