Just let us know which of these great ideas you would like tackle first. We'll do our best to help you get started.
jib On Dec 28, 6:55 am, Sebo <[email protected]> wrote: > In my opinion the "Script" panel and especially the menu containing > the page's scripts should be overhauled completely. It's good for > watching and debugging external JavaScripts, but when it's about > having to deal with inline scripts defined through the <script> tag or > code created dynamically it's very confusing. > Maybe the menu button could be replaced by a tree view containing all > the scripts seperated by domains and folders. Furthermore all inline > scripts should be joined in one entry 'Inline'. Same for dynamically > created functions, which will then be joined in 'Dynamically created'. > By this change menu entries like 'test.htm/event: function onclick > (e...Selected"); if(oldsel) {' would be a thing of the past. In > this case the appropriate script could be found under 'Inline' resp. > 'Dynamically created' under the HTML element, for which they were > defined and when clicking on it jumping to the HTML panel showing > where exactly. Also the static HTML and CSS, which is currently shown > when selecting a HTML output from the menu, is just disturbing as this > has nothing to do with the JavaScript. So the only thing you should > see inside the "Script" panel is actual script and the info, that > belongs to it, nothing else! > Some other some other main features for the panel would be syntax > highlighting, the possibility to change code inline, a switch between > formatted and unformatted display of the JavaScript code, an option to > unminify packed scripts. Besides that there are little things, that > could be improved like adding a possibility to jump from function > calls to their definition, from the ID defined in getElementById() to > element in HTML panel and from a variable name to the DOM panel by > holding down Ctrl and clicking on it. Every variable should have a > context menu entry for putting it to the watch list and by double- > clicking on a breakpoint inside the "Breakpoints" tab you should also > jump to the breakpoint instead of just being able to use the link. At > the moment conditional breakpoints can't be distinguished from normal > breakpoints and could be made inline editable like the styles in the > CSS tab. Besides the features mentioned there are also some bugs, that > should be fixed: For variables, that are undefined, there is no sense > to give the possibility to jump to the DOM panel. And the title and > the script in the "Breakpoints" panel are overlapping when the tabs > frame is resized. > Maybe not all features described can be implemented into Firebug resp. > are fitting to Firebug's philosophy or maybe are already described in > the issues to it, but I just wanted to give an idea of how to improve > it to make it even more useful than it already is. :-) > > Greetings from Germany and a Happy New Year to all! -- You received this message because you are subscribed to the Google Groups "Firebug" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/firebug?hl=en.
