An App A Week

I'm not ignoring you...

2007-06-24T19:28:00.000-05:00

I've been incredibly busy with the paying work (technical translation) this year, and after getting the blog back up, it has literally been wall-to-wall translation ever since. I have some nice ideas for little apps, but absolutely no time at all to implement them; very frustrating.

I really do expect this to change relatively soon, but how long have I been saying that?

Anyway, I was noodling around with some Markov chain code I wrote a year or so ago on a lark, and decided it would be funny to autopost a blog, because I've always thought the output (which is based on statistical analysis of my Toonbots cartoon blurbs, the discussion forum there, and the CNN and Yahoo headlines for the day) is at times hilarious, and if you've ever looked at Markov-chain output, it's really surreal at times. It's like Dutch, it almost makes sense...

Anyway, if you're in the mood for random textual weirdness (and hey, who isn't?) cast your eyes over at Toonbotting. You ... well, I won't say you won't be sorry you did, because you might not be cool enough, and who could blame you?

We're back

2007-06-05T21:08:00.000-05:00

OK, anappaweek.com is on a new server now, one I control with an iron fist. And it won't be going down again. (Unless it does.)

The AppA{TimePeriod} community

2007-04-29T14:40:00.000-05:00

Besides this modest blog, the PHP Jedi reminds me that there is an IRC channel on Freenode at #TheSoftwareJedi -- if, like me, you're IRC-challenged, you can also use a convenient Java client at the software Jedi's site: click here to get there.

Google counting

2007-04-27T14:09:00.000-05:00

So as you may or may not know, I've been dabbling lately in the despamming of online forum posts, with more or less success. And I've been helping people pro bono in despamming their own fora, if they're interested.

This is in response to the wave of forum spam which has arisen since the availability of XRumer in November, 2006. XRumer has a number of tricks in its toolbag to get around spam blocking measures in place, because after all, if you don't actually track people down and shoot them when they spam, you must actively want "advertising" on your forum for cheap handbag knockoffs, Viagra, and lesbian porn, right? Right.

So forum despamming is getting interesting. One of XRumer's little tricks is to post through HTTP proxies to make it difficult or impossible to do IP-based banning of posters. And that was really pretty effective -- until the very popularity of XRumer and similar spambots using HTTP proxies made traffic through HTTP proxies really, really prominent.

The epiphany I had this week was that if a proxy is well-known by forum spammers, it's going to get indexed by Google a whole lot. So the natural next step is to check Google for the IP of an untrusted poster, right?

Thus the Google counter was born (code presented here). Very simple. And it seems to block about 30% to 60% of forum spam so far.

In other news, since the Big Move back down to the Caribbean, the translation work has been incredibly voluminous. I keep thinking, "Today I'm going to do some GUI work" but I still end up falling asleep translating. (And that's really weird: yesterday I tried to type "replacement and wearing parts" and typed "replacement and wearing turbans" instead. Typing while asleep is very Zen.)

A file monitor

2007-04-01T15:39:00.000-05:00

Well, lo and behold, it turns out I've implemented a very simple version of App #3, the file monitor. It's not very flexible -- if invoked from the command line with a source directory and a target directory, it will monitor the source directory and move anything and everything added to that directory into the target directory. It does no error checking. And it's too stupid to find the Desktop to monitor.

But it's a file monitor, and in the next couple of days I'll post a more complete version. The monitor thus far is just this:

<ui>
<frame id="main" title="File monitor 1">
 <args id="main">
   <arg field="source" default="."/>
   <arg field="target" default=""/>
 </args>
 <html field="html"/>
 <timer field="timer" state="off" interval="1000" cmd="look"/>
</frame>

<action id="initialize" lang="python">
  if not [context]['target']:
     : notify "You need to specify a target directory."
     : exit

  [context].list = set(os.listdir( [context]['source']))
  [context]['timer'] = 'on'
</action>

<action id="look" lang="python">
  oldlist = [context].list
  [context].list = set(os.listdir ( [context]['source']))

  for f in [context].list:
     if not f in oldlist:
        shutil.move (f, [context]['target'])
</action>
</ui>

To run this bad boy, you'll need the latest Pypop from SourceForge (v0.2) -- if you're still running 0.1, you'll run into some bugs I just fixed, and as I haven't done very good error handling, things will just fail silently and you won't know why. Eventually I need to put some error handling into that beast.

Anyway, this is just a taste. I've also written up a nice tutorial on Pypop which goes over some of the design considerations in the apps so far, but it's not uploaded yet (I still have to write some formatting scripts to turn it into proper HTML.) When I do that, I'll post here again, and hopefully sunny Ponce will keep me happy and productive.

Sorry for the hiatus -- I've moved again

2007-03-28T17:07:00.000-05:00

Every few months, my family and I move household, just to stay in fighting trim. Our current coordinates are now here. Ponce, Puerto Rico is a very strange place. It's ... it's like New Castle, Indiana, in that there are townies and non-townies, but the townies have been here for five hundred years. It's part of the United States. Kind of. It's a foreign country. Kind of. It's tropical, but dry. It's hot, but breezy.

We're here because my son is healthier here. We're not sure why, but when you're talking about allergies and kidney disease, you don't argue, you just go with what works. For some reason, his physical health is better here. Socially things are different; we don't speak Spanish very well, and so things can get somewhat sparse. But we do have a lot of friends in town (we've been here off and on for three years now) and so we get by. But after about six months to a year, you start thinking of those libraries and restaurants in Bloomington, and then you decide to go back. Or you start thinking about Europe. That's the last two times we left Puerto Rico. But proteinuria lab results bring us back every time. We just wish we knew why...

Anyway, all is not lost with respect to AppAWeek; as soon as I have a reliable Internet connection, now that the Indiana house has been made ready for the market and the Puerto Rico household has again been retrieved from the storage unit, I should be ready to reengage. In the meantime, um, I dunno, go play Tetris or whatever the kids are doing this year.

Stupid PyPop tricks

2007-02-08T00:01:00.000-05:00

I've been playing with timers in PyPop (the current version has them enabled) because I had originally thought I'd do the directory monitor with a timer. Here's a neat little application for PyPop:

<ui>
<frame id="main" title="File monitor" h="100" w="200">
 <html field="html">Nothing to see here, move along</html>
 <timer field="timer" interval="1000" cmd="tick">
</frame>

<action id="initialize" lang="command" parms="">
  set state tick
</action>

<action id="tick" lang="python" parms="">
  state = [context]['state']
  if state == 'tick':
     : set state tock
     : hide
  else:
     : set state tick
     : show
</action>
</ui>

All it does is to show the frame and set up a timer that calls a "tick" command. The "tick" hides the frame if the state is "tick", and shows it if the state is "tock". End of story. The frame appears and disappears every second. When you've had enough, click on the close button quickly before it disappears. Ha.

Try it! Remember: PyPop installer here at SourceForge.

Forum despamming

2007-02-06T21:43:00.000-05:00

Well, it's not an official app, but I spent a little time correlating forum posts with my access logs over at my own site, and came up with a nifty little script which is doing pretty well despamming my own very low-traffic forum at Toonbots.

Now if I could just get admin access to the Software Jedi's forum... Dana Hanna, Dana Hanna. Would Mr. Hanna please come to the courtesy phone?

Stick a fork in it, PyPop is done

2007-02-02T00:37:00.000-05:00

Well, v0.1 isn't done, really, but then is software ever done?

PyPop is a Python-based GUI interpreter capable of flexibly implementing an application represented as an XML file containing a description of:

Frames and dialogs used in the application
The command-line arguments, if any
The data file read/written by the app, if any
The commands behind all button (and other) actions in the application

The commands are written in Python with some syntactic sugar to save typing.

You can get PyPop v0.1 from its SourceForge download page. Because I like you so much, I took the trouble of building an NSIS installer for it -- so there's nearly no work for you, just click it and install.

Once it's installed, get the filetagger app definition and try it out. There is a "Help|Registry associations" menu item in the filetagger now which will register .ftg for use as a filetagger database file extension. It's crude but it works. Now if I had some more time, I'd go ahead and write code for a real installer, with a SendTo link and all. That will have to wait for another day.

A day after I finish v1.0 of the filemonitor application Cabin Tom's patiently waiting for. Busy busy busy!

Oh, a side note: Dana is still alive, or was a couple of days ago when last I heard from him. Just really distracted. And lame! Don't forget lame.

Stringing the public along

2007-01-27T23:12:00.000-05:00

Ha! I simply haven't had time to look at publishing the PyPop framework yet, but I did go ahead and post the filetagger translated into that framework.

The expression of the filetagger now takes 310 lines of XML, and includes the specification of the UI, the commands behind it, the structure of the datafile, the handling of all command-line flags and arguments, the About dialog text, and the help file -- the Python code was about 340 lines and didn't include any of the textual resources. More importantly, the expression of the commands is somewhat more readable in the interpreted version, or at least I find it more readable and certainly more writeable.

The only sticky wicket is that I have no documentation framework for this style of coding yet. I've got some ideas on how to manage it, but (as always) little time.

Anyway, I'll get the interpreter for this little beastie up as soon as possible, and then things are going to start getting interesting.

WMI wizardry

2007-01-27T16:12:00.000-05:00

So it turns out that there's an easier way to get to most of the Windows shell functionality, through the Windows scripting interface and -- even better -- WMI, the "Windows Management Interface" which is a huge, sprawling attempt to put all the administrative stuff in Windows into one scriptable place. There's a truly inspired Python wrapper from Tim Golden which provides wonderful introspection and scripting, and Microsoft also has an entertaining column on general scripting and WMI at Hey, Scripting Guy!

I've asked the Scripting Guys about how to move icons. I still think it ain't possible, although the quest has reminded me of a lot of Windows API stuff and also brought home to me how many (half-assed implementations of) nice mechanisms have arisen in the fifteen years since last I tried all this.

I almost have the PyPop GUI interpreter up and running for you. It's up and running but I want to add one more feature (the ability to register file extensions) before I release v1.0. Might happen today.

App #3 slight redefinition

2007-01-26T01:15:00.000-05:00

Oh, hey -- it occurred to me after posting the last post that if I modify the requirements just a tad for app #3 I can still do what Cabin Tom really wants to do. Granted, it looks like it's just too durn much trouble to move icons on the Desktop, but I can easily monitor the Desktop and move all newly created files there into an incoming-download folder of arbitrary definition.

So mote it be. App #3 is now slighly adulterated, but at least possible.

(But if you know how to script icon-moving-around on the Windows Desktop, I still want to hear from you.)

Guter Gott...

2007-01-25T21:19:00.000-05:00

Oh yeah. Now I remember why I always hated working with Microsoft Windows. When I started delving into the guts of shell programming, for the first time in a very long time indeed, it was with a fairly relaxed notion that since the Desktop is a folder, the information about the location of the icons on the Desktop must be in a relatively easy-to-find location or have relatively easy-to-use interfaces.

I was wrong. Oh, granted, I'm pretty sure I've found something (IShellView2 exposes a SelectAndPositionItem method) but it took a day's reading, and that just isn't time I had. It escalated into a sort of obsession, and at the end of the day, all I have to show for it is maybe I can move the fricking icons around on my Desktop, for some versions of Windows.

I say "maybe" because there's no fricking documentation for it. That's a situation I run across in open-source programming, of course, but in the open-source world I could look at the code for Explorer and see how Explorer does it. Here, that avenue is closed to me, not because it's important for Microsoft to hide it, but because it's simply not important for Microsoft to divulge it. The default is secrecy. And that default is, at the heart of it, precisely what is wrong with the world in general. I won't go into the obvious political ramifications because I'm pretty sure if I started in on it I'd shock Dana's maiden heart, but suffice it to say that Windows sucks. Sure, it's usable -- has to be, to perfuse the market to this extent -- but it's just marginally programmable. And for no real reason.

Back in the Good Old Days, when I was doing a whole lot of VB programming under Microsoft Word 6.0, is when I first realized this about Microsoft's worldview. Even then, Word was quickly establishing itself as the industry standard for document editing and storage, and so there was no alternative. And I'll be the first to admit that exposing Word's innards in Visual Basic for programming was brilliant -- I loved it. But whereas the motto of Perl (a language I learned much later) is to make easy things easy and hard things possible, the unstated motto of Word Basic was to make easy things possible and hard things unimaginable. There were things I simply could not do, no matter how many weeks I spent hacking on them. (Back then, as a paid minion, I had the weeks to spend -- now it would simply be out of the question and on to the next project idea.)

With open source, the documentation is of comparable quality, but when the documentation gives out, there is at least some working example code in whatever product originally inspired the interface or function or what-have-you in the first place. The thing was written to solve a problem, and the solution is an open book. With closed-source, somebody obviously solved it, but they will not tell you the solution.

Ugh. I hate them all.

On the other hand, I have found lots of nice pieces for app #3 -- for instance, I can still build a directory monitor using SHChangeNotifyRegister. This installs a window to be passed messages from the Windows Shell (i.e. Explorer and the Desktop) whenever files are created, written, moved, deleted, etc. Instead of polling a directory on a timer, therefore, I can just sit hidden in the background until something happens. Much cheaper in terms of system resources.

And really, just getting that much working would be a valuable addition to my framework; I'll probably just call that app #3 like the coward I am, and call the icon mover action app#4, unless somebody can show me an easier way of going about it. The sticky wicket is that the Python COM model doesn't wrap IShellView2, so if I want to go that route I'll have to wrap it. And I don't want to. So you Windows mavens, now's your chance to show me how much Windows doesn't suck. If you can.

Another detour!

2007-01-22T01:02:00.000-05:00

Well, as I was mulling over how much larger wx had gotten since I last downloaded it (and once I realized the smallest of apps, compiled, becomes 5MB), I got to thinking.

That's always a mistake.

In this case, I thought: gee, it's nice that the UI of these programs is defined in the XML. What if I defined the command-line argument handlers, too? And loaded the external data file based on that description?

What if ...

Then the epiphany struck. What if each of the commands in the CLI were to be defined in the XML? As Python, no wait, as templates to generate Python? So I researched it and bent my fevered brow to the task. And lo! it works.... Really.

If I define "filetagger.wftk" as a UI file, with an "action" tag for each command in the CLI, wxpywf can now read those, build the CLI class, and pass it back to pypop for instantiation in the main context. It can't import Python files, but it could without a whole lot of work. And will.

Now I can introduce a real Software Jedi toolkit: pypop. As soon as it's cleaned up, anyway. If pypop stores apps by name, you could download them with a pypop app manager, install them, and let'em go. If the pypop then subsumes both the Jedi console and a directory monitor and stuff like that -- well, you'll have a handy-dandy Swiss army knife of a UI tool. I kinda like this.

Anyway, I'll clean this up and get it posted tomorrow or the next day. And then continue with App #3.

App #3 taxiing for takeoff

2007-01-20T00:27:00.000-05:00

Today I got started on filemonitor, which is app #3. I really haven't done much yet except to research timers under wxPython, add a nifty "later" command to the wxpywf GUI CLI, sketch out a timer pseudowidget for repeated, scheduled commands, add a "hide" and a "show" command to the CLI so that we can hide on the system bar when in monitoring mode, and that's about it.

I don't yet have things set up to upload works in progress easily, so I haven't done that yet, but I'll probably do something along those lines over the next few days.

Wheel reinvention for fun and profit

2007-01-19T18:21:00.000-05:00

It's come to my attention that some among you think it's a waste of time to reinvent the XML-described UI. Some such rot about "reinventing the wheel".

Strunk and White's Elements of Style has a nice little turn of phrase I've always liked: "Infinitives, like round stovewood, sometimes benefit from being split." To which I add that wheels occasionally benefit from judicious reinvention.

There are three responses to this complaint, actually. First is why I believe that it's not a waste of time to reinvent the XML-described UI wheel, and it's the same as anything else in this venture: yeah, lots of people describe UI in XML, for the simple reason that XML is specifically designed to describe things. There are, in fact, a couple of XML UI description frameworks already out there for wxPython. As I said at an earlier point -- I don't like them because I didn't write them: the flippant version of saying, "I don't like them because they don't do everything I want and they don't express things as elegantly as I like." There's a great deal of machinery behind the wxpywf that simply doesn't exist in any comparable framework I know of. The fact that it's XML-described is only the surface -- the thing is, by reinventing XML UI description in the context of my existing workflow toolkit, I saw that there was a great deal more that could be done to encapsulate the UI in the first place.

Essentially, the UI frame is itself now an XML-describable object at runtime. It is an array -- I can effect changes to the UI simply by assigning a variable, and the framework takes care of figuring out how to implement the actual visual changes. If you take a look at the actual code for the filetagger, instead of carping about wheel reinvention, this elegance becomes more apparent. And so yes, I think that this particular wheel did not suffer from gratuitous reinvention.

So that's one response, a nuts-and-bolts thing. The second is more of a philosophical nature, a simple refutation of the weird notion that There Can Be Only One. Is there only one database? Did anybody carp at the MySQL writers that PostgreSQL already existed, so they were just reinventing the goddamn wheel? Did sendmail's mere existence make it superfluous to consider any other mail handler? For that matter, what about Linux itself? Didn't Unix already exist? Didn't Windows already exist -- what's the point of writing a GUI environment for Linux, then? Python is a reinvention of Perl, Perl of C, Java of C++. wxPython is a waste of time given TK, and Tcl isn't a reinvention of anything recognizable but still manages to be a waste of time. Or so it would seem to this humble wheel reinventor.

A healthy ecosystem benefits from a great number of competing -- and symbiotic -- species. That's a point equally true of carbon and software. If you don't like my GUI framework, don't use it. But whatever you do, don't complain that I wasted "time" -- whatever the hell that is -- by writing it. Because reinvention is progress. It was reinvention of the basic fabric of society that gave us the American Constitution, and a reinvention of our attitudes towards the universe itself that gave us the Enlightenment. I maintain that I was not wasting time.

And then the third and lowest-level response: who the hell are you to complain about wasting time, anyway? Why the hell do geeks think anything of a time-wasting nature is an affront? Do I complain about people playing RPGs or watching football? Is that stuff inherently more useful than my coding? What did you do today that wasn't a waste of time? Still got a TV? Bet you watched 24. Talk about a waste of time! At least I have something to show for my time that's different from what ten million other oxygen sinks did.

Waste of time. I'll give you waste of time.

Welcome to the XXIst century!

2007-01-18T20:08:00.000-05:00

Yeah, so I finally upgraded my Python and wxPython versions. OK, so I hadn't upgraded since 1999, OK? OK? You got a problem with Python 2.1 and wxPython 2.3? Hey, they were good enough for us back then.

So now I'm on Python 2.4 and wxPython 2.8 and it only cost me a day of flailing around, realizing I hadn't compiled anything in C in an inordinately long time (two laptops ago, actually), trying Microsoft's new free MSVC environment, rejecting it due its stupid requirement of manifests for the runtime (who forces licensing for a C runtime? Microsoft, that's who) and switching back to MSVC 5.0, which was good enough for grandpa so it's good enough for me. That kind of thing. But now it all works again, and while the switch from Py2.1 to Py2.4 isn't going to get me much, there are a lot of fancy new widgets in wx2.8.

(As soon as I have another day to spare for it, I'm seriously going to migrate over to MingW32 and be done with MSVC for good. I've used MingW32, way way back when you had to handroll and compile your own Perl to run it on Windows, and it's a dandy compiler. But the wftk has a rather complex build environment on Windows, and getting that all to work right with a new compiler felt rather daunting yesterday. So I'll do it later.)

Primary among the fancy novelties in wxPython 2.8 is a nice class to put an icon on the system tray in Windows, and that was really what made me break down and do it in the end. Oh, no, I forgot -- the other reason is that to get to the Windows COM classes I need the Win32 classes but they don't support Python 2.1 any more. Not even available for download! So here I am, being dragged kicking and screaming into the new Python millennium.

App #3 on the runway

2007-01-16T22:33:00.000-05:00

OK, we have a winner in the app implementation lottery: Cabin Tom's suggestion for a "file placement" utility. The idea here is simple: when downloading things to the Desktop, Tom is bothered by the fact that the icons for these downloaded files get scattered all through his carefully set up working icons. He'd prefer that the files get tossed into a separate part of the Desktop.

Since the Desktop is of course just a directory which gets special treatment, my solution is a two-parter:

Reimplement miechu's directory monitor in a more generalized way, so that a generically specified action is taken whenever the contents of a directory change
Implement an action for that utility to take which consists of modifying the icon properties of the file in the directory, so that they get moved into a specified area of the screen.

This is going to be a bit of a challenge for me, because I'm not at all familiar with the Windows classes to get this kind of task done. But in principle it ought to be easy. Right? Yeah!

Whoops, documentation helps

2007-01-14T00:00:00.000-05:00

Seems I neglected to mention that there is a command-line syntax for the filetagger (and didn't test it for absence of said command line). I've fixed both issues -- first, a new version is up that does the Right Thing if you don't give any command line arguments or naively click the executable, and second, there is a doc file attached to the zip which explains the command line, and it says this:

This is run from the command line like this:

filetagger1 -fcst[tag] [database name] [command]

The flags are as follows:
-f: show the Files tab when starting
-c: show the Cloud tab when starting (default)
-s: run silently, i.e. just execute the command given and quit
-t[tag]: in the Files tab, filter for the tag given.

The database name is required, hence the confusion. I hadn't tested for the case of no command line -- there's a new version up on my site which works better, assuming the database name 'default.ftg'. If you give a filename that doesn't exist, it'll be created when you add files.

Finally, the command can be one of the following:

add [filename] [filename]...

(In silent mode, no dialog will appear to elicit extra info; in that case, give it a tag with -t[tag] and that tag will be attached to the files you've just added.) If you don't give any files, a common files dialog will come up to let you pick some.

mod [filename]

Pops up a dialog to edit that file

del [filename] [filename] ...

Deletes the file(s) listed.

Here's what the Files tab (the file management half of the app) looks like:

And the Cloud tab (which comes up first by default) looks like this:

The whole thing is done with XML and mirrors and I'm really quite happy with the results. Now on to app #3. I'm not sure what I want to do next. Any ideas?

At long fricking last! The filetagger is here!

2007-01-11T20:07:00.000-05:00

OK, OK, I know this isn't anappamonth.com, but there was a lot I wanted to do right in this first serious application. And I'm quite happy with it! Tired, but happy. You can see the results of my handiwork here (code and download available there, too).

I did this app with my (now marginally working) wxpywf framework, which combines wxPython GUI with my XML-oriented wftk project. This framework started as a simple way to put together UIs for workflow applications under the wftk, but I lost development steam a few years ago due to many Real Life factors. That seems to be changing (insert vigorous wood-knocking here). The module has a few nice features:

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.

Anyway, it works for this app. The filetagger fulfills most of the requirements I posted last month, and can easily be added to the SendTo menu and assigned to a file extension (although I leave those as an exercise for the reader at this point -- did I mention I'm really tired?) I didn't implement any export capabilities, for instance. But it would be really easy to do so.

It's a good first draft!

Haven't forgotten you all

2007-01-05T21:59:00.000-05:00

But it looks like I should next create an app-to-week ratio meter, sigh.

The holidays did indeed intervene, and as I always suspected, getting my GUI framework into working shape was more work than I expected, but the task is near done. So tomorrow or so, I'll be treating you to app #2, the file tagger. It's kinda cool, and I find it elegant. And since so much of the effort has gone into making the framework elegant and reusable, my next app should really be done in a week (or less!) That's the game plan, anyway. This egregious Yuletide disappearance has just been an excuse to do this right, something I've been planning for years.

Onwards!

Requirements for the file tagger

2006-12-21T23:11:00.001-05:00

So I've finally grabbed enough time to work out what I think the file tagger application should look like in more detail, and thought I'd at least blog that much before going on -- as you can see, this isn't going to be an app a week yet (more like a 0.5 app-to-week ratio), and I have no doubt that Dana will think that's evidence of the superiority of the .NET platform, but you and I know he's full of it.

Here's how I envision it:

The central data structure of the application is a list of managed files. These files can actually reside anywhere in the file system; adding a file to the list or removing it has no effect on the actual file. This is essentially a database about the files. We can store the following information about each file:

Where it is (the filename and full path)
An optional nickname
An optional descriptive text
A list of tags for the file.

The application can run in command-line mode or in GUI mode. In command mode, you can add and delete files from the list of managed files, change their descriptive text, and import/export various things (the info for a file, the info for a tag, or the entire file database).

In GUI mode, the frame consists of a menu bar, a status bar, and a tab set; the tabs are "Cloud", and "Files". (This bit of the specification may well change after I've implemented the first draft of the program.)

The Cloud tab consists of the current display of the tag cloud; each tag is a link. The Files tab consists of a split screen; on the left is a bar specifying the tags displayed in the list on the right side. The right side is a columnar list with a subset of the information for each file (the name or nickname, at least some of the tags it belongs to, and the description. I guess.)

When I add a file to the database, a dialog needs to appear asking me for more information about it: the nickname, tags, and description. The same dialog is used to edit information about the file. I can add a file in one of two modes -- either the dialog appears immediately, or the file added is added with a provisional tag (e.g. "new-files") and I can go back and organize all the new files at once. From the command line, the second, "silent" mode is the default. From the GUI, I can specify my preference. Note that the monitor application that miechu wrote (see the Jedi forum) could invoke the file tagger in either mode, adding new files to the database automatically after, say, you download them.

Anyway, in the Cloud tab, when I click on a tag, the app opens the Files tab with a list of the files in that tag. I can then edit them, etc.

When I drag a file from the Explorer (or desktop, or whatever) into the application, it depends where I drop it. If I drop it when the Clouds tag is open, then the editor dialog opens for the file, allowing me to specify tags, unless I have specified silent adding. If I drop a file or files onto the Files tab, though, they're automatically added with all the tags currently shown on the Files tab (unless there's no filter active.) That way, when I've got a tag open, it acts just like a folder.

I should be able to drag files out of the app, too. That shouldn't be hard.

OK, what am I missing? Oh, yes -- import/export. Especially export. When I export a tag, I want to get a tab-delimited list of the files in it, say. Or the XML descriptions (optionally, either). And I also want to be able to export the entire tag cloud as a set of cross-linked HTML pages, so that each tag links to a page listing the contents of the tag. How that page should be formatted, I'm not sure -- I guess to make sense, each file should be able to link to some activity, but I'm open to suggestions as to what.

So. That's your challenge. As usual, my main block is that I have specific ideas for extensions to my usual wxPython toolset to make this sort of UI development quick and easy, but I've never had the time to finish those tools (and as we know, I never use a tool if I can make it first. If I knew how to whittle a laptop, I wouldn't even be posting this at all -- it's all I can do to resist rewriting Blogger from scratch before starting, after all.) So the process is delayed.

Incidentally, regarding my last post about deadlines -- when Sunday started, I had two very solid days of work ahead of me, but the deadline was actually Monday morning. I could live with a day's tardiness (translation customers really don't like lateness, but sometimes they just learn to live with it). But when I got into the work, I was totally in the Zone. I've been in the Zone when programming before -- when it all just flows, you instantly comprehend each problem, each snag, each bug, and every line you write works the first time. It's like a religious experience, except that afterwards you have something to show for it.

In the four years I've been translating for a living, Sunday was the first time I hit the Zone. My fingers could do no wrong; I made next to no typos and my typing rate was some unheard of number. I didn't need to look up any words (well, it helped that the source text was very well written and all about XML as used in SAP ABAP). It just flowed. I usually figure on 4000 words translation per day as a full day. My personal record for a day was, until Sunday, about 8000 words. I don't really know. But Sunday, I translated no fewer than 16,300 words. Literally four days of work -- by 2 AM I just wanted to know how far I could take it, and at 6:30 AM, against all expectations, I simply ran out of text to translate. I actually made the deadline.

All of which is a long-winded explanation (as you know, I'm incapable of any other kind) to explain why it is now Thursday and you haven't heard a peep out of me. When one does four days' work in one day, it takes time to recover. Also there were Christmas presents to wrap and still a few to obtain, packages to take to the post office to send out in time for Christmas (largely the presents for our friends in Puerto Rico, along with one package for Hungary which won't make it in time), holiday break camps to schedule with Parks & Rec for the kids, guitar strings to buy, that sort of thing. But now I'm back.

Anyway, Dana, you have your challenge -- can you write the app above in one day with .NET? (Ha, like I can write it in one day with wxPython -- I probably could, but I won't, not this week. I'm still ramping up.) Maybe you could smack me around a bit about that, since I seem to have been relatively unslappable this week.

More tomorrow or on the weekend -- I really want to spend more time with my toolset before posting an app. Specifically, I've been working for a while on a simple resource-like overlay for wxPython which will allow me to express the above UI as XML, then instantiate it as an app. Yes, I know there are such things already for .NET, as painting the screen is kind of the point of rapid app development -- and actually, there's one for wxPython, too. But I don't like it. So I'm writing my own, because by God it's open source and I can. So. More later.

Feeds have been fixed

2006-12-19T10:44:00.000-05:00

Sorry for my disappearance, but have no fear - the feeds are fixed. I'll log on later tonight and smack Michael around a little bit.

Whew! Busy, busy!

2006-12-16T20:43:00.000-05:00

I've been trying to hit yesterday's job deadline today (sigh) and working with my Perl translation code to do it. My thinking is that this code is probably too specialized for general interest -- not to mention far too rough for public display -- but would anybody here be at all interested in one tech-geek professional translator's approach to language handling? If so, leave a comment and I'll see what I can do that doesn't make me look like a total linguistic amateur.

Now I'm only two days behind to hit a Monday deadline for another chapter of German-to-English translation (on ABAP programming in SAP, actually) and so I'm unlikely to post much more on the file tagger app until Monday or Tuesday. Just so you're warned -- I wouldn't want anybody to suffer! (Unduly.)

(Except Dana. He's left us totally in the lurch. So Dana should suffer.)

Note to self

2006-12-14T14:53:00.000-05:00

More posts, but shorter ones. Nobody comments on or links out of the windy ones...

Dana still missing, film at 11.