I bought an artist friend the processing book as a birthday present with the result that I've just wasted well over 2 hours in an unsuccessful attempt (via chat) to get processing to actually work on her computer, the difficulties apparently stemming from the fact that she had the audacity to pick a non-ascii login name. Much mutual frustration ensued.

I appreciate that this doesn't seem to be a bug in processing proper, that processing is FLOSS and you get what you pay for etc. -- but surely, for a program that's  aimed at an international non-geek audience, the current way to "handle" this jikes/windows suckage is just a joke.

The error message is pretty much completely useless, other than as a first step for googling which turns up a 2005 discussion forum thread, which doesn't turn out to be super-encouraging either.

So off to the FAQ and on to the Troubleshooting page (minor aside: I think making "troubleshooting" a FAQ item that links to the dedicated page or even merging the whole section in might be worth considering).

After finding the right item (which, BTW is also likely to stump some people, given the disconnect between error message and anything that's directly referred to in "troubleshooting" -- why not mention the symptoms rather than just the cause?), the only offered "workaround" a member of the target audience is (possibly) likely to be able to implement, namely asking users to create a new login name, strikes me as pretty last-ditch.

Now various other hints are offered, if one is willing to trawl through the linked bug-report/discussion messages referenced, but none of them are spelt out in any detail.

I tried the build.path and sketchpad.path approach but with no luck (after spending quite some time to direct her to find the damn preferences.txt file), even after manually also creating the folders (the error still indicated that the build was still attempted in the old path). Maybe build.path is now obsolete? Or maybe my friend made a mistake (a non-geek screwing up hand-edtiting some obscure settings file certainly seems a possibility). God knows.

There's also a mention that javac *does* properly handle non-ascii filenames -- but it is unclear what follows from this.

For example will using the non-java-included version do the trick? Not mentioned. If that indeed fixes the problem, how about adding a download for "non-English windows" users (not quite accurate, but probably good enough) that comes with sun's javac rather than jikes. Or at least include a download link to the right jdk.

Or maybe one could make it easier for the user to diagnose the problem and specify an ascii-only dir (no text file hacking, a better error message with a link to a step-by-step workaround description etc.).

I'm not sure what the best answer is, and I appreciate that there might be no fully satisfying solution.

But one way or other, as things currently are I would certainly think twice before recommending processing again to anyone who isn't either a geek or has an ascii-only name -- which seems a pitty.

unabletoprocess,

Geez, that does sound like a frustrating time!

That being said, I feel it's important to also remember that the continued development/refinement of Processing is really dependent on all of us now-not just B&C. I did really understand and appreciate your points, but I also felt the tone in your post was a bit directed at an "other" ("them" perhaps rather than "us"). I certainly don't want to speak for Ben and Casey, but I imagine I might feel a bit frustrated by such posts, after devoting years of their lives to this project with essentially no remuneration, so many of us (literally tens of thousands) could reap the benefits from their vision and labor. Alright, enough guilt. Now, let US fix those problems.

Very Respectfully,
IG