Best Approach for a Quick & Dirty Desktop Application

I have decided to let the geeks out there solve a problem for me. The problem is writing a quick and dirty solution to a temporary problem. I have an idea but I am interested to see what others have to say.

The application is for some not very fancy record keeping. You could call it a payroll system but it has few of the characteristics of a real payroll system. Also, it is temporary—in a few months it will be no longer needed. It is for the Geek Ranch project and is to keep track of "casual labor".

We have anywhere up to 50 people working on various construction projects. They are paid (in cash) every two weeks. Their pay is based on days worked during the period at a daily rate. The "twists and turns" are minimal (getting paid for seven days if they work six, for example) but that can pretty much be dealt with by hand.

There are reasons this becomes a database project rather than just a spreadsheet.

  1. We want some sort of error checking on data entry and it seems easier with a database
  2. There are a couple of balances that accrue (vacation and a "13th month" pay that accumulates and gets paid out once a year). We want to keep track of this and also print info to put in the General Ledger that reflects the wages we pay out plus the liabilities we are accumulating.

For data, I see three record types:

  • Employee—name, ID number, start date, current pay rate, ...
  • Pay—The data we enter each two weeks.
  • Comment—General-purpose info that just includes a timestamp and a comment field.

Transactions are limited to:

  • Enter/update employee record
  • Add/update a pay record
  • Add a comment record

Reports consist of:

  • Generate a pay report (selecting by a particular person and date or all on a particular date)
  • Payday ledger showing who got paid what plus the liability updates
  • Employee summary showing the employee info and all related records

By "report" there is absolutely fancy here. This can be just fixed width characters on a piece of paper. Again, think temporary.

The person using this will be at a KDE desktop. They are not a computer geek (and, if it matters, they only understand Spanish). The whole program can be running on their workstation (only one person really needs to access this) or it can use a web interface from a local server. Postgres is running on a server (to support another system) or sqlite could be used.

If there is code to be written, I would prefer Python but other possibilities (from Awk to PHP) exist.

That's the story. Tell me the "best way" to do it and, if possible, why your way is best.


Phil Hughes


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Camelot : desktop apps the django admin way

tw55413's picture

You could use a project I started a while ago,, it allows you to build pyqt desktop apps the same way you build a django admin interface. By simply adding some information to your model definition, the table and form views are build.


Phil Hughes's picture

Well, I actually solved that problem by "the human problem" deciding to go find another job. But she left us with an accounting disaster. Similar in size, I needed something to enter a Chart of Accounts, Vendor names and then accounting transactions in an attempt to clean up a serious mess.

I loaded Django on the server (I loaded 1.0.1 from as the latest Kubuntu package was 0.96), created the model and enabled the admin interface. Started up the test server and had what I needed. I entered a few records and realized there is one thing missing—I need to have the transaction number which is an auto field displayed. That should be a 5-minute fix.

The total implementation time including the download and fighting to figure out why I couldn't access it from another machine on the network (the answer is "because that is the default—it's just a test server after all) was about three hours.

Phil Hughes

The most cost effective solution

David Anstey's picture

Go buy a cheap payroll package. Seriously, this is what the answer really should be. Why would anyone want to design a piece of software which will be only used for a few months when there are perfectly inexpensive solutions out there which have been tested and deliver. This is not a slam on Open Source - there have been some tremendously innovative open source projects, but we must keep an open mind as well. IMHO, time trumps everything else, it is too valuable to waste needlessly on throw-away software projects.

Ok, any suggestions?

Phil Hughes's picture

I actually looked a bit but didn't find anything. It has to be in Spanish, and it has to run on Linux. Beyond that, I think we can work around any things it doesn't do the way we need it done. What do you suggest?

Phil Hughes

About 1996 I developed a

bob Carpenter's picture

About 1996 I developed a record keeping/payrole system for a 24/7 trucking operation. The company was a Microsoft shop so Access was my only option, and it worked very well.

The system itself was quite simple. Data was entered every morning for the previous day (Monday for Fri., Sat., and Sun.). The data entered went into a holding database. When payrole reports were run on Mon. P.M. they were verified before faxing to the payrole dept.

Verification for data entry was simple, don't allow more than one entry per day per person.
Holidays, sick days, and vacation were entered as such even tho vacation pay was put in in advance.

After verification the holding db was appended to the main db and the holding db was flushed.
Flushing the holding db eliminated the chance of paying someone twice for the same days work.

The main db held all records for the current year and what ever reports were necessary came from the main db.

Use whatever db you like, write it in whatever language you like, and have fun.


A Seda's picture

I think web framework is overkill for this. I think OpenOffice Base is good enough and it can connect to the Postgresql DB if you want to use what you have at hand. Also, you will require minimum programming and can re-arange the same concept or idea for future projects. Another benefit is to, possibly, keep the complexity to a minimum (less programming, less code to maintain) and is cross-platform (base runs on windows, linux, etc) and promote the use of OpenOffice. No web server complexity and you can teach someone else how you did it, so others can create their own solutions, in the future. This is my opinion. Thanks !!... Exito !!

C++, Qt-Create and PostgreSQL

GreyGeek's picture

Even as an alpha release I've found Qt-Create to be an excellent tool!

Open your repository and install PostgreSQL 8.x plus the PostgreSQL 8.x devel files and Pg3Admin. Also install Qt4 and its devel files. Download Qt-Create's binary and install it.

Use the Pg3Admin to create your database and its tables. Use Qt-Create to write your app. If you have any experience with C++ at all you should be able to knock out the app in a couple days.

Otherwise, use OpenOffice 2.x or 3 and use its database tool to create foxpro type dbf tables. Then use its data-aware form and report creation wizards to write your data entry forms and reports. You could probably do this one in under a day.

Use a an office DB

Anonymous's picture

This is what the MS Access and the OOo Base are designed for. IT makes a good quick solid database, with easy reporting and query tools and you can even build the pretty front-ends in it that are easily expendable.

Best with OpenOffice Base

Anonymous's picture

Web Frameworks?? Gosh ! That seems like overkill for a simple project. My take is to develop the application on OpenOffice Base (the database program). This makes it easy for even business users to create and extend the solution. And stuff like validation, data entry forms, reporting become a breeze WITHOUT writing code. For a sample screenshot, check


Web Framework

Silver Knight's picture

I'ma have to agree with all these folks who suggest a web framework. Personally, I like CakePHP with MySQL or PostGreSQL, but as at least one poster mentions, you're best off choosing the language you are most comfortable with. PHP, Python, Ruby, CGI, or whatever you can build with to get the job done... (Decent Web frameworks exist for the vast majority of popular languages, so choice of language should be mostly based on your comfort level above all else.)

While you say it's going to be a temporary thing, if you keep the code you build, and something even remotely similar comes up in the future, you should be able to easily refactor what you already have and save a TON of time on your future similar needs. Being based on a web framework would also make it fairly "future-proof" (as you should be able to easily enough refactor the code to fit future needs, regardless of how much time passes).

Making it web server based also has the advantage of not tying it to any particular operating system, desktop interface, widget set, etc, etc. The user (or users) simply use something they are already familiar with (a web browser) to enter data into something they are already familiar with (form fields) to get back something they are already familiar with (reports and processed data).

All around win, pretty much every which way you look at it...

Go minimal

Akshay's picture

I would go with something tiny and fun for an app like this one... in fact apps like these present opportunities to experiment. Go with a ruby based mini-framework like camping... or if you just have to have a pure desktop based client, try 'Shoes'. Better yet go with Lua and try kepler maybe... always wanted to try that... then again, you can just have bash scripts for 'quick' and 'dirty' work. As for the db... sqllite.

Yes, web framework

Jem's picture

I'd go with rails and be done in no time.

For a desktop client, I'd build a Swing app using netbeans. The Matisse GUI builder is insanely easy.

Re: Swing

Scaroth's picture

I agree, Swing and Matisse are both excellent, but the handicap is you have to use the Java language :/ Unless you want to use Groovy, which adds too much scaffolding code for my liking.


Guindilla's picture

I would do this with django.

It is easy to install, has a complete administration interface for the model without coding anything extra and some "views, i.e. some pages that automagically print "repports" for some kind of data. Furthermore, it supports all kind of languages easily (I'm playing with it with japanese, spanish, french and english) and could be used by any number of people due to the web interface, although it also works in localhost without the need of a webserver.


definately agree with django

Anonymous's picture

The poster who suggested Django is definately onto something. Why write a boring desktop app, when a web app is so easy. Django lets you define the model of your data easily in python and then instances of that model are automatically mapped to the database. Building a simple django app with fields and buttons is fairly trivial. Also everything you need is in which is a completely free book. You could probably whip up a basic version of the app in a long weekend.

Whatever is most comfortable

Arthur Griffith's picture

For quickies like this, one should always use the language that is most familiar. For me, this would be Java. It gives me the coding speed and flexibility that I need. Byt Python is fine, if that's where you're most at home.

The key to the job is to devise a form to hold the data. I would suggest a simple journal--every record in the same format. Unsorted. Then, the output can be a produced from an independent group of select-sort-print modules.

The whole thing can be developed in radical top-down fashion, so there is minimal need for design documentation.

This approach has proven itself to be effective. Problems come from this style of program only after it has aged and grown lots of kruft (which it gathers rapidly), but this is a short-lived project so the problem vanishes.

On second thought, COBOL might be a better choice. This is exactly what it was designed to do.

I'm glad this is your project. Not mine. These programs are never fun, and everybody always complains.


Harry's picture

For the UI I'd give


some consideration.
Ok so wxPython is going to use GTK+ as its widget set on linux. Personally I have no issue with either GTK+ on a KDE desktop nor Qt on a Gnome desktop.
wxPython is relatively easy to program, the api is quite straightforward and vastly simpler than GTK+, Qt or Win32, and python does your memory management.
For added win it is highly portable and should look pretty good on any X based desktop, or the various proprietary operating system desktops.
For the database as simple as you want it


might be the thing. pscyopg2 and postgres is probably overkill.
I can't do a comparison to Sean's solutions as I haven't been creating javascript widgets using the various libraries for validation recently as nice as Rails and Django appear to be to program. You probably do want as much validation in the client as well as in the database as possible so your poor user doesn't start hating the software, their computer, all computers, all programmers and the tyranny that is working with data in an office in front of a screen without programming ability at your complete disposal.

Web framework

Sean Walberq's picture

Sounds like a fairly simple job for a web framework. Frameworks allow for easy abstraction of your business rules, and also can apply rules (validations) to data before they go to your database. My experience is with CakePHP and Ruby on Rails, but I'm sure Django would do just as well if you want to use Python.

The frameworks also have features to make the HTML generation easier. It's been a welcome change moving from the old style of web programming to using a framework.