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]
