On Sun, 13 Feb 2005, Tim Freedom wrote: > --- Andrew Bardsley <[EMAIL PROTECTED]> wrote: > > Sorry to bail out before 2.0 is gold but I feel that an > > enthusiastic maintainer with a pressing need for a good waveform > > viewer could really make something of GTKWave 2. I'm afraid > > that I'm no longer enthusiastic enough or in enough pressing > > need.
Working on side projects and working at a startup sort of don't go hand in hand so that's an understandable position: I turned over maintenance of 1.3 (which his group forked off to 2.0) to Andrew back when I was working at a startup myself. =) > Hope a new maintainer steps forward, a number of us rely on GTKWave > to do 90% of our work (I have no programming skills else I would have > happily volunteered). The one area where GTKWave really needs lots of > work is its signal hierarchy viewer/selector which should try to mimic > signalscan's layout and functionality (as that seems to be the golden > model). Interestingly, signal hierarchy is probably the easiest function to code up as all the necessary structs and such are already in place for doing it as they're generated during trace initialization. Yeah, I do agree that signalscan has a decent layout. The most pressing need for GTKWave 2 as I see it is that LXT support does need to get fixed as VCD isn't really suitable for huge traces. I'm probably going to write a reader library (like exists for LXT2 and VZT in gtkwave-1.3's src/helpers) as the current reader is too tightly integrated to the viewer (legacy from the 1.3 days) and needs to be broken out. So a reader API would definitely simplify maintenance work. So obviously I can still work on/help integrate back end temporal database code. (Stuff outside the realm of visualization.) That's where all the black magic resides anyway. Besides, it appears that I might be the only person around doing that sort of thing open source anyway! Regards, -Tony
