On 5/19/09 10:27 PM, David Humphrey wrote: >> * 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.
It might be sufficient to have a link within the popup "open this in new window". The other problem I see with the popup is that it often obscures the very code I'm trying to read, hence my suggestion about permanent sidebars/footers/whatever. Have we got a UI designer we can tap to help sort through this? > 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. I figured you could probably categorize the results: TYPES: <a href="link-to-typeinfo">nsString</a> (<a href="link-to-declaration">source</a>) ... USED AT: links to source code locations... >> 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?). No, I agree that the full diagram each time is probably overkill. Although I'm hoping we can still end up statically creating most of this so it doesn't involve a lot of webserver work to fetch it. >> * 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. Argh, if I said that I am truly sorry! The use-case I'm trying to solve is: I see NS_ENSURE_SUCCESS in the code. Clicking on it tells me the full macro expansion, but doesn't tell much about why I would use it. Linking back to the original location lets me see the surrounding header. Does the DB store each instance of the macro separately? I figured it would just map NS_ENSURE_SUCCESS to a location once, or at most a few times if there are multiple macro definitions. > 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. This is because we call NSPR `make install` to install those headers. I can look to see if there's a hack which would cause them to be symlinked. --BDS _______________________________________________ dev-static-analysis mailing list [email protected] https://lists.mozilla.org/listinfo/dev-static-analysis
