Keyword wxpython

Writing specialized text editors in wxPython

2006-12-07 wxpython text-editor translation

So again, a lick and a promise for this blog as I madly try to finish some translation work. This translation job is an interesting one, though, as I mentioned, and as it turns out, amenable to editing in a specialized tool I just wrote today. Of course, having written the tool today means I have to use the tool this evening in a mad dash to finish, which in turn means I have no time to document the code until tomorrow at the very earliest.

Suffice it to say that the exercise was surprisingly easy. The task was simple: I need a tool to edit text files in which (for reasons we'll go into later) I have a number of phrases, one per line. The phrases mostly have all the right words in them, but not in the right order. I thus need a way to quickly select one or more words and drag it into the right place in the phrase. Sure, you say, Word does that. Yeah, except that Word doesn't put the spaces in the right place. God and Bill Gates alone know why, but Word doesn't put the fricking spaces in the right place when I drag words around on a line, and so I took matters into my own hands and rolled my own solution. And by God it works! Still a few little oddities in it, but it works more quickly than Word for this particular application.

Another nice thing it can do is this: when I drag the first word of a phrase out into the middle, it can decapitalize that word, and capitalize the new first word. That saves me a fraction of a second, and multiplied by 2000 phrases that adds up to a lot of time.

And another little thing I just now added: I can hit a key and toggle the case of the word the cursor is on. Again: this may or may not be of general use, but for this particular application it's very convenient. And that's really the idea of special-purpose text editors. An example from the programming world is emacs -- you can write LISP code to make emacs do literally anything at all (including psychoanalysis) from your text editor. The only problem being that it's too damn hard to start. Python's easier, at least for me. So a text editor in which you can embed your own Python snippets might be a generally useful tool indeed!

So. Tomorrow or Sunday, documentation and maybe some more movement on the drop tagger. And in the meantime, go get some sleep! (I know I won't any time soon.)

Special-purpose text editor #1 complete

2006-12-12 appaweek text-editor wxpython programming litprog

So my first actual weekly application is finished now. Aren't you proud? Suffice it to say that even a minor app takes a few hours to put together when you're reworking all your programming tools at the same time. A character flaw, I suppose. I never use an already-invented wheel if I have a perfectly good knife and wheel material. And I never use an already-invented knife if I have a perfectly good grinder and stock metal. And I never use an already-invented grinder if I have a lathe, motors, and a grindstone. And I never use an already-invented lathe... (sigh).

At any rate, it took me a few hours more than I wanted, but I'm reasonably pleased with the result. You can see the whole thing here (it's far too long to publish on the blog directly, of course). Go on. Look!

Thoughts on wxPython UI design

2006-12-22 appaweek wftk wxpython tagger

For some time, in the context of my workflow toolkit, I've been thinking intensively about UI design in wxPython.

See, once I was embroiled in a rather extensive project developing a GUI application under wxPython, and frankly, the UI was unmanageable. It had been developed with some IDE tool or another, but the output was Python code. It was horrible, trying to find what was what and on which panel it was developed and what its ID was -- ugh! This was back in about 2001.

At that point, I hadn't really started integrating wftk into Python yet, but I dabbled in it over the next couple of years, always with the notion that the UI is most sensibly defined in XML, and that a sensible UI manager would then take that definition and build all the objects needed to implement it in wxPython (or, for instance, online in a portal or something). And since that time, other people have naturally had many of the same ideas, and you see this implemented. But I've always wanted to finish my own implementation.

The current app for Anappaweek.com that I'm working on is, of course, a GUI app (at least, some of the time.) And so naturally I have relived my need for my UI design notion -- and in the context of working on the file tagger, I intend to start implementing the UI module. On that note, here is a tentative UI definition sketch for the file tagger. Ideally, we could use this XML not only to generate the app itself, but also to generate documentation for the UI design (by transforming it with XSLT into SVG, for instance; wouldn't that be indescribably cool?)

All of this is, of course, subject to radical change. Here goes:

<frame>
  <tabset>
    <tab label="Cloud">
       <html>
    </tab>
    <tab label="Files">
       <splitter (some kind of parameters)>
         <panel>
           <radio-group>
              <radio value="something" label="All"/>
              <radio value="something" label="Some"/>
           </radio-group>
           <listbox/>
           <button label="Show"/>
         </panel>
       <listcontrol>
         <col label="Name"/>
         <col label="Tags"/>
         <col label="Description"/>
       </listcontrol>
    </tab>
  </tabset>
</frame>

I already have a framework for that definition to go into -- I wrote that in, like, 2002 or so. But I never got further than definition of menus. So here, I'm going to implement frames, and at least one dialog.

Note that what's utterly missing from this is any reference to code to handle events. That will come later, when I see what has to be defined where to get all this to work.

And on that note, I close.

File tagger app finished!

2007-01-11 filetagger wxpython wxpywf appaweek

At long last, I managed to finish development on a first cut of the filetagger application. It took far longer than I really wanted it to, because I spent an inordinate amount of time whipping the wxpywf framework into shape (about a month) and so the whole "app a week" thing is more like "an app per five weeks" or so. Ha.

But you know what? I did it! I actually brought a major new module of the wftk, one I'd been thinking about for three years, to the point where it can be used. Wow.

So I'm glad I took the time to do it the way I wanted to do it.

Here are some of the features of wxpywf I created and used for this app:

XML definition of the entire UI of an application, using frames and dialogs. In comparison with the traditional call-by-call technique for setting up a wxPython UI, this is incredibly convenient.
Application-specific code grouped into simple commands.
Each frame and each dialog automatically binds to an XML record which can be addressed on a field-by-field basis.
HTML can be used for more textual interfaces; links generate commands which can have arbitrary effects on the UI (in this case, clicking on a link in the tag cloud switches the tabbed frame to the file list and displays the files with the tag selected.)
So far, the UI can include tabsets, list controls, HTML windows, rich text controls, checkboxes, radio button groups and listboxes, command buttons, and static text.

There's a lot of ground still to cover. But in my experience, that kind of ground can be covered in small, manageable steps after initial usability is there. And initial usability is definitely there. I feel really happy about this.