Lan Barnes wrote:
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.
Is there any better reason?
Are there drop in replacements for all those functions in Tcl/Tk?
Tcl/Tk (I'll assume Python, too) excels at user interface.
The only user interface Python has is the command line. Anything else is
an add-on. But it has lots of add-ons. The classic GUI is Tkinter (Tool
Kit Interface). Tkinter is pretty much deprecated because of its low
number of available widgets and non-native look. But because of good
separation between the the GUI widget set and the programming language,
you can get bindings to GTK (PyGTK), QT (PyQT), wxWidgets (wxPython) and
probably others I'm not aware of.
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.
As does QT.
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.
Do you mean that the data crunching should be done by routines written
in Tcl, or that you write the routines in C/C++ as it is now and expose
them as Tcl commands?
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.
I have never tried to argue for that. But maybe I should since you seem
to be in need of a good 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 so wrong it hurts. The QT widget set is one of the few things
that I would consider to be well written C++ code from people who
actually "get" Object Orient Programming. The KDE project uses QT as
its foundation, not only for the graphical interface but its support
routines as well. QTDesigner is a wonderful GUI builder. Fire it up and
you will get a program builder that rivals anything you can do in
Tcl/Tk. QT has all the things you need to build applications like MythTV
and has a large number of widgets plus the documentation is
outstanding. It is also relatively easy to build new widgets if you need
something more than what already exists either by extending classes,
combining classes, or directly grabbing the Paint routine. If you don't
like C++ you can still get to the functionality of QT by using some of
its bindings like PyQT for Python, PerlQt for Perl, etc.
I've been working with QT originally through Kylix (Borland Delphi for
Linux) and now Lazarus with FreePascal
<http://www.lazarus.freepascal.org> (an object oriented Pascal) and it
works great. In addition to QT I can also bind Lazarus to GTK, GTK2,
Carbon (on Macintosh), fpGUI (a GUI specialized for FreePascal),
Win32/Win64 and wince (Windows Compact Edition) which demonstrates that
your choice of GUI toolkit and programming language need not be tightly
coupled.
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.
Of course it is. Your problem is that you are in an abusive relationship
with your hardware and won't acknowledge where you are really getting
the segfaults from.
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.
The hard parts of the project had nothing to do with the UI. In fact,
the UI parts are rather trivial BECAUSE of using QT (see the source
code. I have). The hard parts would all have to be done in
C/C++/Fortran/some-compiled-language anyway because processing video is
something that requires performance and Tcl code (nor Python, Perl,
scripting-language-dejour) isn't going to cut it.
Gus
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
