Now, I need a Venkman-like tool regardless, and the UI as it was presented to the end-user was fairly well defined. The problems I had were really about how to make improvements on an architecture that’s over ten years old and has been abandonware for years. When
I need something and no one else is building it, I’m likely to build it. So I’d like to start a new project that looks like Venkman, but works with jsd2 and has a clean, truly XUL-based UI implementation.
I’m looking for volunteers to help me kick-start a new Mozilla Debugger Developer Community. Who out there is interested?
(P.S. The company I work for is looking to hire developers who are familiar with FF extensions. For anyone who’s not experienced enough, a project like this is a great way to get into the field… )
13 thoughts on “R.I.P., Venkman”
Can you tell us what Venkman had that Firebug doesn’t? I only vaguely remember the tool 🙂
(From Alex: Well, for one, Venkman can debug FF chrome code. Chromebug can too, but rumor has it not as well.
Venkman also runs in its own window. Firebug may be better / more practical in this respect, but when you have a full window, you have more real estate to play with.
I actually have almost never used Firebug. Sacrilege, I know, but I haven’t built many web pages in the last five years. It’s all been Mozilla development for me.)
No! I love Venkman! I don’t want it to go away!
I too have a full-time job so I don’t know how much time I’d be able to devote to building Venkman’s successor. But if you’re making a list of people who are interested in helping, please put me on it!
I too am sad to see Venkman dying a slow death, but have not enough time/interest to actually go hack on it 🙁
Last I tried Chromebug, a month or two back, it still doesn’t actually _work_ for me; the window came up but it failed to things to debug, and generally chewed CPU and made everything slow. Venkman was good in that it usually kind of worked (even now, at least it catches the debugger; keyword most of the time). It was especially important for anything that isn’t a webpage sitting in Firefox (i.e. Firefox chrome, non-Firefox apps).
Make sure that XUL is the way you want to go – it’s definitely what would be the easiest, but with the direction things are going you may want to consider HTML + box model (via CSS) instead?
Firebug can pop into its own window. Just sayin’
I used and use venkman as THE debugger and therefor gecko as the primary platform since years. Now, that everyt browser goes to firebug looking debugger, I switch more and more to webkit.
But I also have to second Jamies’s question: What can venkman do what firebug cannot do. I think of conditional breakpoints and variables which can be defined in the console. But all are items which lead me to the question if it’s not more efficient to add these missing features to firebug instead of creating a new debugger from scratch.
(From Alex: The point is definitely a valid one. I already said I do not use Firebug, though. It cannot work with files inside Firefox’s user interface. ChromeBug is supposed to do that. I haven’t used ChromeBug either…
I was about to say “it can’t work outside of Firefox, in another Mozilla application”, but its install.rdf says it can, via the firstname.lastname@example.org target application. Ironically, I’m the guy that implemented that target.
I guess the only fair way to answer this question would be to list Venkman’s features, and ask for someone to fill in a table for Firebug’s equivalent features.)
As far as I know, Venkman only has two advantages over Firebug:
1. Venkman can debug chrome code which makes it really valuable for extension developers.
2. I’ve gotten very familiar with the Venkman UI, so I like it much better than Firebug’s.
For #1, how hard would it be to make Firebug work in Chrome code? Easier than writing a whole new Venkman replacement from scratch? I don’t know the answer.
For #2, that may just be something that Venkman fans (including myself) need to get over.
At the moment, Venkman is being shipped with every build of SeaMonkey (and for anyone who wouldn’t know, SeaMonkey is the community-built continuation of the former Mozilla Application Suite, see http://en.wikipedia.org/wiki/SeaMonkey and http://www.seamonkey-project.org/ ). I’m sending the following to SeaMonkey developers:
I came across this post in Planet Mozilla, under the title “R.I.P, Venkman”: http://weblogs.mozillazine.org/weirdal/archives/020974.html
Now I think the SeaMonkey community will be faced with the following choices:
– if and when the Firefox guys remove from mozilla-central the JSD1 code on which Venkman relies, maintain it ourselves by wrapping it in #ifdef and/or moving it to someplace else where we can keep it (and, possibly, Venkman if abandoned by Gijs and WeirdAl) under perfusion for shipping with SeaMonkey
– if and when Venkman is definitively abandoned by Al and Gijs, or earlier, find some other Venkman-like tool that can be shipped with SeaMonkey.
Is it possible that software is not like anything else, that it is
meant to be discarded: that the whole point is to always see it as a
„The only people currently working on the code are Gijs Kruitbosch and myself, to my knowledge.“ – Well, are you sure? 😉
One of Venkman’s biggest problem is getting patches reviewed, because there’s only one official reviewer …
I don’t quite agree that Venkman “is” dead, but of course it’ll need to change to reflect JSD2 reality. I’m not sure „yet another debugger project“ is going to get us anywhere — we do have Venkman and its … aged codebase, we do have Firebug and its scarce chrome abilities.
I do think that writing a new debugger from scratch is probably a waste of time and may end in desperation, given the amount of people who already don’t hack the current debuggers. 😉
I’d rather like to see a renewed effort to fix Venkman, but we need to get a handle on the reviewing situation …
As many have pointed out so far, the difficulty comes from ignorance of what Firebug actually offers. This is not for lack of trying; Firebug’s inability to debug chrome-level code makes it a non-starter. (Literally so in the case of Chromebug; none of the panels will start up, including the script panel.)
I have used Firebug on a few occasions to attempt to debug content-level scripts, as well as just poking around at it.
I’d have to say that the second factor in Venkman versus Firebug is that Firebug just has a terrible UI, worse than Venkman. Some would say, “Are you serious? Have you seen Venkman?” Yeah, that’s how bad it is. I’m not talking about prettiness here (although I suspect a fair number of people are referring to this when they speak of Venkman). I’m talking about intuitiveness and other pain points. Venkman has its fair share of the latter, for sure.
In light of the latter issue (among other reasons), if the Venkman effort were rebooted, I’d rather see the effort go into creating a new debugger, instead of an attempt to hoist Venkman’s power into Firebug. Controversial? Maybe. Divisive? Maybe, but I hope not.
If the Venkman replacement really gets off the ground, I would advocate for it being—from the start—a project oriented towards meeting the needs of both those doing chrome-level development and those doing web development.
I am interested in helping. I’ve been looking for a good project to get into for awhile.
Hi, I will be excited to have opportunity help develop Venkman project. I familiar with developing of firefox extensions and do it on present job.
Is there a way to move Venkman from SeaMonkey to ordinary mozilla-central code base? (I am a little confused: TB trunk uses comm-central, and mozilla-central code is used within it. I saw venkman directory in extension directory under mozilla, but I am not sure if this is equivalent to “SeaMonkey” version. I suspect it is not.)
Comments are closed.