In QC now, if one makes a queue of images, you can tell if the queue is hooked and working correctly by monitoring a node. You can see that each of the images is different in the queue because the pointers are constantly changing.
With the proposed change, all you are going to see is a list of values that say <Image>, whether or not the queue is working or not. Unplug the queue from the chain, monitoring a virtual out shows that all of the "pointers" aren't "moving" anymore. Monitoring a structure port reveals no useful info about this condition. It looks the same either way. "Change" is a way more appropriate description of the proposal than "fix". -GT On Wed, Aug 4, 2010 at 2:36 AM, Christopher Wright < [email protected]> wrote: > > I see your points, but if anyone uses that for some reason, it's > ultimately taking away functionality. That said, I'm not against lopping off > functionality for good reasons, but this is a bit of an empty aesthetic > reason... I usually tend towards ways to smoothly integrate levels of > detail. There are more important hurdles to achieve with tooltips. > > It's not just aesthetic -- I can vividly remember cases where i _wanted_ to > know what was inside one of those elements, and was kindly informed that it > was an NSCFString. Not helpful. On the other side, I can think of exactly > zero times where I've thought "hmm, if _only_ I knew if that number was > really a number, and not a string... that'd change Everything!". Not once. > Never. > > Do you have any instances of seeing "NSCFString" and it being more useful > than "Some string inside a parsed XML tree that's unwieldily large"? > > I ask this with complete sincerity. I, as a programmer who daily pokes and > prods at stuff at the object level, haven't ever found a use for it; I'm > interested to hear how other users have found that "feature" beneficial. > (Particularly from you, since you're so adamant that it shouldn't be fixed > -- if changing it will disrupt your workflow, I'd love to hear how so I can > try to keep your use case in mind). > > > Tooltips have some weaknesses, for me, that are more glaring than this > issue. > > There are lots of dynamics at play. If this particular issue took 8 lines > of code to fix, I'd fix it before something harder, even if it's more severe > (there are limits to this, of course). I'm confident that the more glaring > issues are several orders of magnitude more difficult to fix; at some > point, it breaks down to "would you rather have 0 fixes, composed of 0 > glaring issues and 0 small issues, or 2 fixes, composed of 0 glaring issues > and 2 small issues?" -- everyone wants the glaring issues number to be > larger, but it's not always that simple, and if that's the way it's going to > be, I'll take this highest number of absolutely fixes possible (within > reason, keeping in mind things like security and user exposure and all that > jazz -- this is a fairly exposed feature, so it's not some obscure thing > that only a couple people experience). > > > It is near impossible to actually inspect all tooltip data in > sufficiently large structures. There are many reasons why one would want to > keep tooltip open, and/or resize (sticky tooltips), or rip the tool tip off > and peg it to the side of the editor, with it being resizable and with > scrollbar. We also can't gain access to the namespace info in the tooltip, > which is another missing link. In the case that tooltips ever get ramped up, > maybe the user could see the data represented in different ways. Seeing a > "reduced" version akin to the what happens now, and having everything > represented as Structs makes sense... in an "sticky expanded tooltip" mode, > niceties like actually being able to see the images in a queue might be able > to happen? > > > > So, to add to "whacky ideas" that people have, I'm basically thinking of > tooltips as something that you "pull off" and then it's a windowed document, > that you can minimize into something like the Dock (which is "in QC"), or > back into the tooltip origin depending on your pref (ala how the Dock and > minimizing app windows works). > > > > I'm not stating that all of those aspects are necessary, but being able > to keep a tooltip open while not hovering, and being able to resize and > scroll the info would be particularly useful (and dare I say, obvious?). > > This perfectly illustrates the above: implementing any of this will > require more code than I care to estimate (i.e. more than half an hour of > effort). They'd be nice, sure, but it's incredibly difficult to estimate > when it'll get done. On the other hand, nicely expanding tooltips can be > done in about 30 minutes before I go to bed tonight. If there were only 30 > minutes left to code "the next version", your choice suddenly becomes "do > nothing" or "at least get this one last fix in" -- not optimal, but > hopefully illustrates the point :/ > > -- > Christopher Wright > [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]
