> 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]
