On Wed, Aug 4, 2010 at 1:17 AM, Christopher Wright < [email protected]> wrote:
> > Hmm, this is the only way we can currently see what the data actually is. > Does this really need to be "fixed"? The reason behind the difference in > data type representation should be clear if one takes the time to look at > the port type. > > But do you care what the data actually is (other than for curiosity)? > Generally, you're more interested in whether or not the data "speaks your > language" (i.e. had keys/indices if it's a structure, has components if it's > a color, has a length if it's a string, etc). Note how the strings in the > shot are NSCFStrings -- what are those, exactly? a private class with no > documentation. But they're useful because they _act_ like NSStrings (they > have a length, and characters, and all the other stringy properties that > make NSString useful). > > QC could plausibly abstract away structures and strings and number and > colors behind an opaque "QCObject" type, and it'd be pretty useless to see > their type in tooltips (you'd just see "QCObject <0x12345000>"). [note: > if I do that, please vote me off the island for being insane ;] > > (This philosophy is known as "duck typing" -- for better or worse, it's > here to stay, and plays a major role in modern objective-C > applications/frameworks). > > Since it's pretty trivial to figure out what the data is on a virtual port, > I think it'd be nicer if the tooltips always showed the pretty version (to > me, seeing "title" = "Breakfast at Tiffany's" is dramatically more useful > than "title" = "<NSCFString - 0xBADBEEF0>"). > > -- > Christopher Wright > [email protected] > > 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. Tooltips have some weaknesses, for me, that are more glaring than this issue. 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?). -George Toledo
_______________________________________________ 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]
