The Road Ahead for Paladin

For some strange reason, February is one of two months of the year -- December being the other -- where Real Life gets a stranglehold on my free time. Music teachers in the U.S. typically put on at least one Christmas-related program each school year, so December isn't at all a surprise, but February... that one is still a mystery to me. Between the icky weather, my daughter's birthday, and replacing a vehicle, I haven't had much spare time. Most of the spare time I have had has been spent tinkering with Linux because I've been too tired to do much of anything else until yesterday and today.

Even now I'm pretty surprised by the number of bugs that have been squished since Paladin's first beta release. There will be at least one more release candidate before the final 1.0. There probably wouldn't have been quite so many were it not for so few people actually reporting bugs. The vast majority of bugs fixed have been ones I've noticed.

None of this is to say that Paladin is more or less standing still, feature-wise. The bugs from the release candidates were almost all ones which I discovered while working on the development branch. Some of the new features include support for shell scripts and rez files, lots of internal cleanups, shorter build times, and the ability to recursively add a folder's contents just by dragging and dropping.

Adding entire folders makes migrating from other build systems incredibly simple and fast, especially when groups are also created for the user. Projects which have lots of files and subfolders, like Open Sum-It, for example, all that is needed is to drop the main sources folder onto the project window, add a few include paths, and change the system libraries in the Project Settings window. It won't be much longer and Paladin will be used to build PalEdit instead of jam -- rez support is still under heavy development as of this writing.

I don't know how far I'll be taking Paladin development, really. The future is wide open in that respect, but I'll describe some of the features that I'd like to make happen most. If nothing else, it'll make for some good Sunday evening light reading. ;-)

One feature that will be added, barring unforseen issues, is a one-click backup of a project into an archive. Coupled with a command-line switch, it could make for some simple nightly snapshot files and also provide a good alternative to using revision control for those people who don't have access to CVS, SVN, or whatever.

A personal code library could also be really handy, and it's a feature that I really want to see happen. The idea is that sitting around my hard drive are some reusable classes that I've used in different applications. For me, this includes a C++ wrapper class around SQLite3, a TextFile class that allows reading of a file one line at a time, and a bunch of things that eventually made their way into LibWalter. There aren't really so many classes to warrant my own personal library -- libdw or whatever -- but there are enough of them to be difficult to manage manually, particularly if I find a bug in a frequently-used class. The solution? A personal code library without the overhead inherent with a full-blown revision control system. Not all of the details have been sorted out, but if I think it would help me personally, others probably would, too.

Code generation facilities could also speed things up in a useful way, too. BeOS C++ developers do a lot of subclassing, and it would be nice to have a way to quickly give a class a name, check a few boxes, and have the generator churn out skeleton code. Instead of using cut 'n' paste or manually typing out a MessageReceived function for a BWindow subclass, checking a box could make the genenerator spit out something like this:

 void
 MyWindow::MessageReceived(BMessage *msg)
 {
     switch (msg->what) {
        default: {
             BWindow::MessageReceived(msg);
            break;
        }
     }
 }

One checkbox to get this? Sounds like a nice tool to do all the boilerplate code, if you asked me.

Basic makefile and/or jamfile generation is still on my to-do list and would make migrating to a more complex build system easier. Code completion would be a wonderful help -- I'm forever having to look up the parameters to a BListView constructor because I use them enough to want to have them memorized, but not often enough that I actually have memorized them. A preferences window and profiling support are coming, too.

All in all, there are lots of exciting things coming. I'm not crazy enough to think that it'll become the de facto IDE for Haiku developers, but if it helps a few people start developing for BeOS / Zeta / Haiku and helps grow the community a little, that'll be far more than I ever thought would happen.