When I say "windowed document", I didn't mean an actual document, I was using an analogy of what is closest in already existing paradigms.
-GT On Wed, Aug 4, 2010 at 1:40 AM, George Toledo <[email protected]> wrote: > > > 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]
