Month: October 2012

Embedded terminal in Python/Tk window

This is something I intend to add to pytextedit sometime in the future; an terminal embedded in a Python/Tk window. This is ridiculously simple to do; using xterm, all you have to do is get the id of the Frame it will be embedded in, and use the -into option.

I’ve only tested this on Linux, currently. (Though I’m almost certain it will work on BSD or other Unix-based systems. Not so certain about OSX [I have no idea if it includes xterm], and I know it won’t work on Windows without Cygwin.) This uses xterm simply because it will be installed on just about every Linux system, and my goal with pytextedit is to have as few dependencies (other than Python and Tk, of course) as possible.

If you’re wondering how having a terminal embedded in a text editor would be useful, I’d implement it the same way Kate does:

Having a terminal in the same window is very useful for coding, as it allows you to test whatever it is you’re doing without needing to have a separate window open (which can get annoying if you have to keep switching between them when you’re trying to edit the code based on some output in the terminal).

This is only semi-related to the rest of this post, but it might be a while before pytextedit 0.2 is finished, due to some problems I’m having setting up tkinter on my Python 3 installation on my new computer. I was going to work on improving and simplifying Unicode support, but I can’t do that without testing in Python 3, and I can’t test in Python 3 without tkinter.

pytextedit 0.2: multi-document interface

(I’ve been kind of busy recently, and I haven’t been able to work on any coding or anything, so I don’t have any code or changelog update to post, sorry.)

One of the biggest changes in pytextedit 0.2 will be the addition of a multi-document interface (or MDI, because I love acronyms and I’m too lazy to type out the whole thing every time). The UI won’t have many changes; a new “Documents” menu, and two toolbar buttons, but that’s it. The code, however, will have quite a few changes.

The way I’ve decided to implement the MDI is to use a global list called gbl_mdi to hold all the info. Inside of this array are more arrays, for each document. The list items will be, in order, the title, the short title, the lock state, the modified state, the cursor position, the starting selection position, the ending selection position, and finally the text.

Example:

gbl_mdi = [
           ["/home/adam/pytextedit/pytextedit.py", "pytextedit.py", False, True, "1.0", None, None, "this would be the text"]
           ["/home/randomuser/Documents/randomfile", "randomfile", True, False, "23.11", "3.4", "23.11", "this would be the text"]
]

‘

As you can see it’s pretty simple. If the selection values are set to None, then there is no selection to restore when switched.

Creating/opening a document will add that document onto the end of the list. Pretty simple.

Additionally, gbl_mdi can have values that are None; when switching these will simply be skipped. Having None values are my way of implementing the “Close Document” feature. The list will just be set to None when the document is closed. This actually allows for simpler and more efficient code, as I don’t have to update the whole list every time.

To remember the current document’s position in the list, there is another global variable called gbl_mdi_current that is used to store the index. This is updated on every switch.

As you can see, the implementation is fairly simple. Actually creating it, however, might not be. There will be quite a few other things that will have to be modified as well; the exit dialog will have to check every document for changes, loading files from the command line or from the last session will have to use the MDI as well, and so on.

I hope to have this all done by November, but due to my rather annoying ability to get distracted quite often I don’t know if it’ll be done by then.