Re: Adding analysis to Devel::Cover reports

2004-06-08 Thread Ricardo SIGNES
* Michael Carman <[EMAIL PROTECTED]> [2004-06-07T23:13:02] > On 6/7/2004 9:20 PM, Andy Lester wrote: > > > > The "ALT attribute as tooltip" thing isn't portable, though. > > I don't use ALT, I use TITLE. That's the "right way" according to the W3C and > supported by at least IE and Mozilla-based b

Re: Adding analysis to Devel::Cover reports

2004-06-07 Thread Michael Carman
On 6/7/2004 9:20 PM, Andy Lester wrote: > > The "ALT attribute as tooltip" thing isn't portable, though. I don't use ALT, I use TITLE. That's the "right way" according to the W3C and supported by at least IE and Mozilla-based browsers. Or did you mean something else by "isn't portable?" -mjc

Re: Adding analysis to Devel::Cover reports

2004-06-07 Thread Andy Lester
When you hover the mouse over one of the percentages, you get a little pop-up that gives the numbers used to calculate the percentage. ("Tooltip" probably isn't the right name for this situation, but that's what I'm used to calling them.) The "ALT attribute as tooltip" thing isn't portable, thou

Re: Adding analysis to Devel::Cover reports

2004-06-07 Thread Michael Carman
On 6/7/2004 11:26 AM, Geoffrey Young wrote: > >> The only thing I don't like about this approach is that some of the data is >> available only in the tooltips, which of course don't print. > > sorry I need this kind of explanation, but what are the tooltips? When you hover the mouse over one of

Re: Adding analysis to Devel::Cover reports

2004-06-07 Thread Geoffrey Young
> Before I get too deep into an implementation, I'd like to poll the group about > how you would use this feature and like it to behave. My thoughts and plans follow. > > For the coverage summary, the numbers represent actual coverage, but the colors > are based upon actual coverage + analysis. S

Adding analysis to Devel::Cover reports

2004-06-06 Thread Michael Carman
On 5/27/2004 9:31 AM, Paul Johnson wrote: > On Fri, May 21, 2004 at 12:50:55PM -0400, Geoffrey Young wrote: >> >> if [a missed path] represents a condition we would explain away (D::C >> limitation, or whatnot) then it would be nice to have some way to track it >> within the tool itself. > > It