> The GUI can look good and sexy, > however doesn't provide additional benefits with respect to the actual > xcircuit's version.
When I'm done, Xcircuit will compile, run and look half-decent on Windows (2000,XP,Vista,7), most Unixen, and OS X. If that's not an "additional benefit" enough, then I don't know what is. Before I started, Xcircuit was bound to X11. It would not run without X11, lest you used Michael Goffioul's unmaintained win32 port. Heck, it would not even run on a plain-Jane native Tk platform: there is native (non-X11) Tk available for both Windows and OS X. So it's not even a fully-fledged Tk-based application, it takes no advantage of Tk's portability. If you compile Xcircuit on OS X to use native Tk, it'll crash as expected. Note that you can access all of Tk's functionality from C++, thanks to the cpptk project <http://cpptk.sourceforge.net/> -- that's how Tk can (and should be, IMHO) used to build C++ applications. But once you're at that stage -- rewriting in C++ and using a GUI toolkit, it's silly not to go all the way and depend on a whole application C++ framework like Qt. The amount of work is the same, but the benefits are much bigger. I also think that you discount the displeasure I have of dealing with 80s-style C code. It's no fun. I like C++ better. I'm not forcing anyone to agree with me, nor am I forcing my code on anyone. But if I am to develop new features for Xcircuit, I won't do it unless the codebase is first leaned and cleaned, and that's my decision to make -- I'm sweating and holding the broom, after all. Chitlesh, if you wish to develop new features on existing Xcircuit codebase, there's no stopping you, and I can't but encourage you to do so. Heck, I'd be very pleased since then we can have a feature-competition and work even harder to out-feature the other developer. Sweet! Cheers, Kuba _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
