The miscellaneous ramblings and thoughts of Dan G. Switzer, II

qForms v2.0 News / Call For Developers...

I sent this letter to the qForms Mailing List earlier and figured I'd better post it here. Leave me a comment if you're interested in helping with development.

I know many of you have been waiting a long time for news on v2. Believe it or not, it does actually exist. The reason why it's been in sort of permanent hiatus was because I really wasn't doing any work that corresponded w/furthering the development.

qForms v2 is like 95% complete, and has been, for a long time. There have been a few key features I just have never had the time to sit down and really figure out. The key features I wanted to introduce for rev 2 that aren't done to my satisfaction yet are:

  • Applying validation rules to a qGroups (a qGroup is a group of fields that work as a single field. Picture splitting a phone number into separate fields for area code, prefix, suffix, etc and being able to use getValue()/setValue() to retrieve the values of all the fields as one string.)
  • Event queuing. One of the things I want to do is get it to the point where you can safely write add-on hooks w/out fear of them interfering w/other add-ons you must load. This still needs improvement.
  • Masking—still needs some improvements. I've re-written the code from scratch several times.

There are other things that can probably be done to improve things and I think the project really needs some new energy as I think that will help re-spark my energy for the project.

So, where am I going w/all this? Well, last night I submitted a new project request at Tigris.org. I'm hoping that those guys will approve the project soon (or I'll be looking for a new SVN home.)

What's this mean? Well, I'm planning on opening up the SVN repository for open development. Instead of opening the floodgates and letting everyone have access to the SVN repository, I'd prefer to have some volunteers from some of you who are willing to help out on the project.

So, I'm looking for experience JS programmers who have some experience w/Subversion (that's the source control I'm using) and who would like to help out on the qForms project.

As soon as the guys at Tigris approve the project, the URL for qForms SVN will be:


For those of you not interested in following the actual day-to-day things, keep going to www.pengoworks.com/qforms for updates. However, if you're always interested in playing around w/the latest and possibly unstable builds, that's the place to go.

I'm also going to be posting the language files there (as qForms v2 supports internationalization.)

For those of who never saw it or what to see it again, you can view a preview of qForms v2 at:


Here's a brief list of what I have added:

  • Internationalization
  • Auto tabbing (via the setMaxLenght() method)
  • Remove validation rules on-the-fly
  • Keystroke dynamic masking
  • Disable/Enable validation rules per form
  • Much more customizable. (See the preview for how you can replace the default alert() handlers and drive everything via DHTML.)


Thunderbird - Temporarily Switch Composing Between Plain Text/HTML

Ok, so it's been a while since I've blogged anything useful—so I figure it's about time I do!

I've been using Thunderbird as my primary e-mail client for my new job. I figured I'd try making the switch away from Outlook to see how it goes. Overall there are a lot of things I really like about Thunderbird. It's definitely faster than Outlook and creating/sending e-mails definitely seems quicker. There are things I miss from Outlook—mainly the complete integration between tasks & e-mail. I've been using the Mozilla Calender project, but I'd like to see all the pieces integrated.

However, the biggest problem I've always had in every e-mail client I've used is that I hate, and I mean hate, HTML e-mail. I find it cumbersome and it's usually harder to read. It seems like everytime I get an e-mail in HTML there are several different fonts. I rarely get an HTML e-mail from someone that actually looks elegant. I also find creating inline responses (which is my preference) is much cleaner and easier to follow when done in Plain Text. That's why I always use Plain Text as my default send method.