* Personally I'm not a fan of the DHTML popup windows. Especially when I'm
switching between an editor and this page, the popups go away right when I
want them most. I'd prefer either a "real" popup window, a sidebar iframe
that stays permanently open, or even just clicking the link to open in a new
tab.
Let me ponder this a bit and see if I can fix your issues, yet still
have the pop-ups. I can understand your use case.
* I'd like to be able to get to a page with just type information, e.g.
right now I click on nsIImageLoadingContent and there's a popup which lists
the members/etc. But I'd like to be able to link to that type itself (in
IRC, or in docs, etc), or even a particular declaration within the type.
This raises a question for me. I end up with two sorts of things:
1) Source code
2) Type, statement, inheritance, etc. info
Right now I'm merging the two as best I can, layering 2) over 1) by
means of these pop-ups. I've struggled with the same issue when I do
searches. For example, if I do a search for 'nsString' I can show you
the type info, places where it's used (statements), the string itself in
source (e.g., what mxr does).
How should I deal with these two worlds? You're going to want to flow
between them pretty easily, but sometimes concentrate on one or the other.
* The "bases" of nsIImageLoadingContent are confusing.
nsIImageLoadingContent derives from imgIDecoderObserver, which derives from
imgIContainerObserver, which derives from nsISupports. But this isn't clear
from the plain list of bases
What I'd really like is an inheritance diagram, much like the ones I made
for nsAString. Otherwise I recommend only listing the direct base, not any
"grand-bases".
For every base type, I record all concrete types, and I know if each is
direct or not. In other words, I can build a tree like you want, if I
do a recursive set of selects.
I'm not sure I want to pay for this every time I get type info, so what
if I do a dynamic tree, where you see direct bases, but can expand each
one to get its bases (and maybe its other derived types too?).
* Types which cannot have bases/derived (such as enums) still have tabs for
them in the type view.
Yeah, I'll fix.
* #include "foo" lines are linkified, but the popups don't have any information
Yeah. I was thinking just to take you directly to the file vs. popping
something up, and haven't bothered with links until I do the rest of the
tree. Coming...
* When clicking on a macro, it's important to say where it was defined.
I wish I kept irc logs! When I complained at the size of the macros
info I generated with loc info, *you* told me that you didn't care where
a macro came from as long as you knew its value. The trouble with
keeping track of where things come from is that I'll get a crazy amount
of repetition, bloating the db, making lookups slower.
* Class member declarations such as nsLinkableAccessible::GetStateInternal
currently say:
Name: GetStateInternal(PRUint32*, PRUint32*)
Type Info: nsLinkableAccessible
This is incorrect, or confusing. It should say:
Name: nsLinkableAccessible::GetStateInternal(PRUint32*, PRUint32*)
Member of: nsLinkableAccessible
Return type: nsresult
Yeah, known, and I'll change.
* You think nsresult comes from zipstub.h... this may be technically true
for some small piece of code, but it's not very useful
* The NSPR types (PRBool) come from obj-foo/dist/include instead of a source
location.
This seems to be the result of prtypes.h being copied vs. symlinked into
dist/sdk/include like other things in there. Why is that? Same issue
for things in dist/sdk/include/obsolete/protypes.h.
I think I would need links in place to comment more.
I'll do a version of the whole tree next so people can look around more.
Thanks a lot for the feedback. I'll fix some more things and throw
another version up for scrutiny. I'd love input from others too, so I
don't get too far down the wrong path with this stuff.
Dave
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
