Wednesday, March 17, 2010

Why We Develop With Panther

People are pretty passionate about their development tools, we found something that works for us based on our needs. Maybe if you are in the Government or Business segments, this information will be useful.

The development tools on Linux most commonly in use are great for writing 'desktop applications'. Want an email client? Use C. Want a note taking package? Use Mono. But those tools are not a good fit for our needs. We want to quickly connect to a database, drop and drag fields out, give the users a simple grid and entry system; and then give them quick reports. We always say that the type of software that we write boils down to "enter, list, sort and print". When we get a request, they usually want it finished quickly, and we don't want our staff debugging garbage collection, threads, compilation and fighting every widget interaction. Our custom software isn't as complicated as Firefox or Evolution, and does not need low level languages. We also want it to run on Linux, and carry no runtime licenses.

The other big issue for us is portability and server upgrades. When an operating system or hardware becomes obsolete, you don't want to spend a time messing with stable software trying to get it to work correctly on a new box. It's much easier to just tar it all up and move it over and it just *works*. Sometimes too you move to new operating systems. All of our software started on SCO Unix and then moved to Linux, and we didn't want to have to recompile and debug working applications during that transition. Lastly, when database upgrades and changes come we didn't want to have to touch the software yet again and fight library interactions.

So how did we obtain these goals? We are using a software package called Panther from Prolifics. The way that it works in a nutshell is that when you develop, you are writing GUI layout instructions and logic code into the 'client.lib'. This file itself does not execute and is highly portable. You then get a 'prorun' binary from Prolifics for whatever platform you wish to deploy on, and it converts your UI instructions into native widgets of the current operating system. It's super fast, with a small memory footprint and serves us well.

This image shows how software is deployed with Panther. You develop your screens on any platform, and a runtime engine on other operating systems instantly convert your screens to that platform.

I built a very simple (blingless!) screen to demonstrate. Here is a shot of the development environment running on Linux/X.

Once your screen is finished all of your instructions are stored in client.lib. You can then pass it to the prorun binary for various platforms unmodified. I do want to be clear that you do of course have to make considerations for the real estate of the various platforms. But Panther does a good job of adding scroll bars to screens when they don't fit. Making this work becomes kind of a art form, and is elegant.

Here is the screen running in Linux/X

If you unset DISPLAY, it instantly runs in character mode. It replicates the widgets as closely as possible, and on a workstation with a mouse, you are able to click into fields and activate the pulldown menus.

They have a prorun (jserver) process that can go into the cgi-bin directory of your web server and once called converts the client.lib into HTML. Your screens are instantly on the web, unmodified. In theory you could NFS mount the client.lib file and run the same code on MS WIndows, Linux/X, Linux/Character and on the web. Any changes you made instantly were deployed to all users.

Here is the screen running in the webserver.

Here is the same screen running on Microsoft Windows.

So for the last few months I have been working with our Integration staff in making Panther fit better into the GNOME desktop. Artwork is being upgraded and all hard coded colors are being removed. GNOME themes automatically set old school X resources as closely as possible to the right colors, which Panther picks up nicely. These steps along with anti-aliased fonts in newer versions of Motif have allowed us to deliver better looking software. The shots below demonstrate a deployed screen, with colors picked up from GNOME theme.

Linux is a wonderful runtime environment for running custom in-house software, and maybe this post has given you some ideas for your own organization.

Update: Receiving and uploaded Microsoft Windows screenshot.


Murray said...

That still sounds overly complicated and awkward. My Glom project would hopefully be much simpler, if it had a working Web UI already.

Anders W said...

Hey, this is not 1999 any more. Today we use more than X in a modern GUI environment. Even if you don't have any use of the latest Gnome widgets, you want your application to fit in with Evolution and other real Gnome-applications. Have a look at for a very interesting Python/XML/Webservice/SQL environment with native Gnome and Web-clients for business applications.

Sebz said...

I agree, It sounds a little bit complicated and looks old...
Did you heard about Eclipse RCP/RAP platform ? It allows you to create rich application for both desktop (cross platform, since this is Java, with native widgets since it uses SWT) and web.

Dave Richards said...

@all: I knew that discussing development environments would be a passionate topic. :) Gtk widgets would be nice, but it's not a show stopper for us. We aren't writing iTunes or desktop apps. These are simple screens for users to enter data and run reports. I believe that Motif is still used to allow portability with Solaris and AIX. The theme work we did was an added touch at integration. At a certain point functionality trumps bling. The scripting language in Panther is very similar to BASIC and is easily half the code of anything in Python. All things Java have proven horrible over remote display and on multi-user systems. The point of the blog was to alert people of what is working for us. If you found other things that work better for you, that's awesome.

Dave Richards said...

PS: Regarding the character mode shot, we do not currently have anything deployed in that manner. But it's nice to have as an option. Ask any clerical people that enter data all day what they think of GUI screens vs their old telnet sessions. In theory you could write screens for data entry people who need to fly with their keystrokes and not wait for UI updates.

GCU Prosthetic Conscience said...

To me, it seems like there's no real reason anymore to develop this kind of application as a desktop app. I'd write it in Python using Django. Everyone gets to use the client of their choice, including lynx or elinks for the tty displays. And if the apps are as simple as you say, most of them can be done with Django's generic CRUD views, and no additional code other than wiring them up to your models.

Murray said...

My point, when mentioning Glom, is that this isn't an issue of what programming language is most suitable. You should not need any programming for these incredibly generic database UIs. Glom lets you use Python if you must but you hardly ever need to.

Less code means less maintenance and more consistency.

Tom said...

Very interesting.

But why still use a proprietary tool when building database web apps is very easy today? has all the parts you seem to need and doesn't need any programming.

Dave Richards said...

Lots of people wondering why we don't develop web apps. Web apps need Firefox, which has a huge memory and CPU footprint when you consider 100s of concurrent users.

239m 81m 24m S 12 0.4 1:21.77 firefox-bin

Panther runtime:
12480 12M 7732 S 0.3 0.3 0:01 3 prorun