The chances of me filling a formal request on that are slim to none. It irritates me to drop requests into the black hole, and would actually probably irritate me even more to see it implemented without my input.
-GT On Wed, Aug 4, 2010 at 1:47 AM, Alastair Leith <[email protected]>wrote: > I think this is an idea with merit and could be filed under the improved > (and multiple) inspector palettes banner. A scrollable palette window with > flip-triangles to open up levels and two buttons to open all and close all > levels inside the currently selected object (in the window list). > > > On 04/08/2010, at 3:40 PM, George Toledo 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/qc.student.au%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]
