On Dec 10, 11:05 am, cthoday <[EMAIL PROTECTED]> wrote: > After two years of development I have recently made the first general > release of Luke-SDK ...
> There is a Smart Terminal that allows interactive shells to operate > within a wx.TextCtrl. On Unix such programs need to be connected to a > pseudo terminal if they are to operate in interactive rather than > batch mode. However, the easy way to connect a Python program to > another process is by pipes. I have solved this by writing a small C > program to copy to and from the subprocess via the pseudo terminal. ddd and Emacs typically work this way - using a subprocess via a pseudo terminal. There exists class of gdb-like debuggers, namely pydb (for Python), rdebug (for Ruby), bashdb (for bash), remake (for GNU make), and of course gdb for C, C++, Fortran, etc. Issuing commands and parsing output for any of these is largely the same. So ddd figures out what commands exist by issuing commands, like "help", and parsing output. It also does this to figure out what's settable and the type -- integer, boolean, string -- of that variable. For these kinds of settings, a custom dialog widget is created to allow one to modify the settings. Also, for all of the debuggers mentioned except "remake" there another kind of interaction possible by using what's called in gdb "annotations". When an "annotation level" of 3 or above is set, those debuggers tag bits of output to make parsing by such a front-end easier. So local program output (as opposed to debugger output) is tagged; the names of local variables and their values is tagged; and so on. Some of the annotated output may be triggered by debugger events. For example if one moves up or down a frame, this may trigger listing the local variables for this frame. In this way, the UI can update information it may be saving without having to poll the debugger for the information. "annotations" in gdb is a little bit deprecated though and there is newer interface between the debugger side and the UI. However since it's a bit more complicated none of those debuggers except gdb use it. And even there in GNU Emacs, the "annotations" are still supported and used more frequently. > The class containing the wx.TextCtrl implements most, but not all of > the xterm (VT100) control sequences. The advantage of running the > shell in the interface, rather than in a separate application, is that > you can do so much more with the results than a xterm clone. > > In order to enable the user to add tools and wizards with interactive > front-ends I have implemented a set of functions for creating a dialog > without using wxPython directly. This idea is not fully worked out > but is sufficient for basic requirements. With further development it > might be worth considering as a separate Python package. > > There is a built-in method of running commands via sudo so tha Linux > system administrators can use it to edit configuration files or i > install software.
