Semi-related note: In the WWDC session stuff there is clearly an option for globals w/ OpenCL, but it wasn't included in the final QC4, seemingly.
-GT On Wed, Dec 8, 2010 at 7:55 AM, Adrian Ward <adr...@clayinteractive.co.uk>wrote: > > I'm not sure QC could ever fully satisfy strict MVC design requirements due > to the inherent nature of it (execution is driven by consumer/rendering > patches, for a start), so I think the Controller/Viewer blur is a common > difficulty that may be inevitable. > > That said, I'm convinced MVC can certainly help structure big Quartz > Composer projects. I don't consider there to be one perfect methodology, and > we've spent years experimenting with different approaches. > > Currently in our projects we tend to have lots of discrete 'scenes' that > are either shown or not shown. We tend to encapsulate those as separate QTZ > files (which helps the team to work on them concurrently) and then have a > top-level QTZ with an all-in-one controller JS patch that is responsible for > logic and storyboard flow, triggering those scenes, etc. Data is loaded and > processed by a separate section (again, usually in an external QTZ) and > currently I'm favouring bundling all data, settings and values in a single > Structure that gets passed along to whatever needs it, like a poor-man's > global object. > > There are downsides to this of course. For example, our recent installation > at Imperial War Museum in London (did I mention we have a big QC powered > exhibit in the new Lord Ashcroft Gallery there?) passes about 4000-6000 > values and objects (even images) in a single nested Structure object. Kind > of mad but it works efficiently and massively reduced our noodle usage. So > yes, it got difficult keeping track of what was *actually in* that > Structure, especially as it's a royal pain to inspect them at runtime, but > it made it very easy to separate model, view and controller into individual > parts. > > Best, > > > A. > > > > > On 8 Dec 2010, at 12:20, Alastair Leith wrote: > > "Also consider that this technique could help encourage a MVC paradigm > within Quartz Composer." > > It's apt that you mention that^ because MVC is *exactly* the reason I made > this JS patch suggestion. Currently I'm trying to model a prototype a MVC > set-up in a QC comp or even perhaps 2 or 3 comps (one for each part). (Happy > to share it when I get somewhere I'm modelling that Simon musical > button game for a case study). In QC it's a special challenge to do this as > it's a functional environment with no resources specifically devoted to MVC > like *Cocoa* has. > > Say one has 3 JavaScript patches for each of *Model*, *Controller* and * > Viewer*, does one pass messages between the JS patches with codified > constants (eg: var k_play_an_A_ON = new Number(); k_play_an_A_ON =1; > result.Message_to_Viewer = k_play_A_ON; ) to get parsed whenever the other > Module is ready to do so. Or could one have live 'State' booleans that > determine if, say, the *Viewer* module should be accepting Inputs and live > Structures that are immediately interpreted to, say, display particular > Output states. > > I've been reading a fantastic book of interviews with well known > programmers (Coders at Work) and one take-away I got was not to over > generalise my code, only bite off what I need to do — don't over-engineer > for expansion/more function than required; leave that for later. I'd like to > have a go at MCV inside QC because I have made an Application in QC that > drives other .qtz compositions. I'll probably use *Quartz Builder* to > distribute the App, at this stage. > > My Javascript patch for parsing the 28+ on screen button inputs is becoming > a bit unwieldy in terms of adding functionality without breaking existing > functionality — it's *Viewer* and *Controller* all in one, and then I have > another JS patch (hooked to tons of structure patch noodling) for the * > Model* which is not talking to any other JS patches yet just responding to > manual inputs. > > The idea of separating into MVC seemed like a good organising principle as > much as a code beautifying / rationalising one. Communication between the > MVC parts / modules is what I am probing / flailing around with at present. > Any advice welcome. > > Best to all > Alastair > Useful Design > > > > > On 08/12/2010, at 9:51 PM, Adrian Ward wrote: > > > Hear hear. > > rdar://8743194 > http://openradar.appspot.com/radar?id=953401 > > > > On 8 Dec 2010, at 06:14, Alastair Leith wrote: > > Would it be possible to implement composition/application wide globals for > the Javascript patches in a future QC revision? > > > I know graph evaluation and free global variables could create a headache > if used unwisely, but it would be kind of neat at times to have a > composition-wide layer to read/write get/set to. Couldn't it just operate on > an ad-hoc basis read to whenever (whatever JS patch is being evaluated) > write whenever (same). > > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/quartzcomposer-dev/gtoledo3%40gmail.com > > This email sent to gtole...@gmail.com > -- George Toledo gtole...@gmail.com www.georgetoledo.com The information contained in this E-mail and any attachments may be confidential. If you have received this E-mail in error, please notify us immediately by telephone or return E-mail. You should not use or disclose the contents of this E-mail or any of the attachments for any purpose or to any persons.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
