Tiny Front-End Engine / News: Recent posts

The other day, someone sent me an e-mail asking about the design of tfe
and whether they could use some of it. I sent a reply and, after thinking
about it, decided to post a copy (edited) of my reply here (the original message
I received is not included because the sender might not want it posted):

>Well, the status is that it's in a pretty early stage. I haven't worked
>on it in a while, partly because I didn't think there was much demand
>for it and partly because my next step would be do change/undo some of
>what I've done because I'm not satisfied with the direction it's going.
>
>It's GPL-ed so if there's no licensing conflict you can go ahead and
>copy anything useful off the sourceforge CVS. I'd also be willing to get
>back to work on it and re-target it toward whatever you're trying to do.
>Better yet, I could bring you into the project and let you work on it too.
>Don't worry about being new to Python, I think it's the design itself
>that's most challenging.
>
>Anyway, right now the basic approach is to have a "messenger" object
>and a bunch of processing objects. Each processing object has an "in"
>queue, an "out" queue, and one or two threads. Most of them have one
>thread that reads from the "in" queue, processes the data, and writes to
>the "out" queue, but some are wrappers around external child processes.
>Those have two threads: one that copies data from the "in" queue to the
>child's standard input and one that copies from the child's standard
>output to the "out" queue.
>
>There's also a special processor that displays and updates "widgets,"
>changing their values when the user edits them or one of the other
>objects sends the right messages, then sending widget values to other
>objects at the user's request. This one is not complete.
>
>I'm not satisfied with the mechanism for translating between widget
>name-value pairs and streams of text or the configuration mechanism
>(also not complete). They're related of course, since the main purpose
>of the configuration will be to parameterize the the translation for a
>particular back-end child.
>
>The problem is that I want it to work with nearly any backend, so you can
>grab a command-line program and slap an interface on it. After starting
>an Xdialog-like set of flags, I've realized that it's just not the right
>way to go. Basically, I have a choice between creating a configuration
>mechanism that allows the user to define an entire grammar for the backend
>or offloading the processing completely. I like the second one because
>it's less work for me and probably less for the user--they can pipe the
>data through a small script instead of doing configuration that's arcane
>because it has to cover every possibility.
>
>I haven't looked at the code in a while, but now that I know someone is
>interested, I'm willing to get back into it.
>
>--
>________________________
>Brian Jaress
>brian_jaress@users.sourceforge.net... read more

This is mostly a reminder to myself, but the plan is:

command-line only + core features: pre-alpha
add curses: alpha
add wxwidgets: beta
complete documentation: stable

All the development is being done in CVS. (Stats aren't working, so it says 0 commits even though there's code in there.)