>From my experience, this problem parallels 'Styles' in desktop drawing apps. Can be very confusing.
Optimally the UI would illustrate — When you're editing the 'archetype'; ie when your changes will propagate — VS When you're just editing a copy — What Styles/Macros are available, and how to reuse them and edit them — Some method to see where other copies reds — Some way to describe the Reusable Macro. Can we add a description to them, like Apple patches have? Keith. On Fri, Apr 30, 2010 at 3:41 PM, Christopher Wright <[email protected]> wrote: >> You might have missed the point. All the parameters you want to tweak are >> published up to the macro patch itself. The engine stays the same, you give >> each macro a different filename etc. > > From a programmer's point of view, Toby's suggestion perfectly mirrors the > idea of subroutines. If I make a function (doStuff()), and then use it in > a hundred places, I'd expect a single change to doStuff() to "propagate" to > all uses instantly (that's just how programming works). If it didn't, > programming would be one of the most awful professions ever. > > QC, on the other hand, currently has all its functions "inlined" -- the only > subroutine-like reuse is in Virtual Macros, which require a separate editing > step to change (unlike programming -- doStuff can be in the same source file > as all the uses of it). > > I don't think it always makes sense in QC for a macro copy to be a mirrored > copy, but I'd definitely find it handy in some use cases as well (think of > them as a light virtual macro -- not necessarily file-backed). As with > most things, the trick is finding a good design that makes this as seamless > as possible, to accommodate both schools of design. > > There are definitely workflows that tip their hats to both, depending on > design styles. This also reflects programming -- some developers will > copy/paste chunks of code instead of refactoring, and then they run into the > same problem George mentioned, but in reverse: if you want all instances of > a chunk to simultaneously change/update their behavior, you've got an > exciting hunt-and-find ahead of you (and if you miss one, it's nigh > impossible to find it). There are also times where you _want_ a copy/pasted > chunk to be distinct for tweaking. QC in its current form _only_ allows > the latter case; Toby was saying it should provide both. (in principle I > agree. Not sure if I can think of a good/seamless way to expose it though). > > -- > [ christopher wright ] > [email protected] > http://kineme.net/ > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Quartzcomposer-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/quartzcomposer-dev/songcarver%40gmail.com > > This email sent to [email protected] > _______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
