On Wed, October 24, 2007 1:37 pm, Gus Wirth wrote: > Lan Barnes wrote: > [snip] >> MythTV (which is on my mind a lot these days) could probably have been >> done faster and with fewer segfault defects in Tcl/Tk. My hat's off to >> them for what they've done in C, but I can't help but think it would >> have >> been easier and more robust in a scripting language. > > MythTV is written in C++ and uses the QT widget set. It needs to solve > several hard problems that are directly related to hardware interaction. > One is getting the full OSD (On Screen Display) to work which QT handles > nicely. Another is getting the player to work, although I think a > wrapper around mplayer or xine-lib could have worked just as well. Not > sure if there is a Tcl/Tk ability to do OSD. Other things include doing > the commercial marking which requires some fairly impressive data > analysis, doing the video capture off a device, and transcoding. > Although transcoding could also be handled by some external program like > mencoder or transcode, mythtranscode has better abilities than these > programs for MPEG2 editing. > > The project has also been going on for quite a few years now and was > started by one developer whose tools of choice were C++ and QT. >
Yup. That's all too often exactly how a tool set is chosen. > Are there drop in replacements for all those functions in Tcl/Tk? Tcl/Tk (I'll assume Python, too) excels at user interface. It has excellent facilities for exec'ing processes. It has integrated interfaces to just about every back end available (including Isaac's choice, mySQL). And it's fully extensible with facilities for tying in C/C++ routines as new Tcl commands. It's also cross platform FWIW. The low level data analysis not handled in external binaries like mythtrancode (easy to exec to that) could, indeed, be made Tcl commands giving the app programmers a flexible way of experimenting and advancing the program w/o needing to refactor or even recompile the C. As for the scheduling logic, if you want to try to convince me that that sort of programming challenge is easier in C than a scripting language, I will gratefully lie on the floor and have a good, loud, long laugh. As for "the project has also been going on for quite a few years now," well, DUH! Isn't that what I'm saying? I'm betting if they had ditched QT and done the user interface in a scripting language with a good Tk, they could have cut at least one of those years off. They'd have been able to concentrate at the high end on the program flow, and at the low end on perfecting the C/C++ code that does the actual data capture and manipulation. But that's just my sense of it, and to repeat, I'm very appreciative of the job they've done with the tools they're familiar with. > You > are always welcome to fork the project :) > I think I'm on record as having the opinion that this kind of comment is gratuitous snarkiness. In fact, I'm toying with the idea of starting my own project to compete with an established C/C++ project that will IMHO never get done and be the wrong thing (and too brittle to fix) when it finally stops crashing on alternate keystrokes. But it isn't Myth, and frankly, because I'm not a developer, I shy at the challenge. As for Myth, Isaac and Co have done a wonderful job with their tool set of choice, and I'm hardly arrogant enough to try to improve on that. But I feel quite free to cite it as an example of a project that missed an easier, more robust path to success. -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
