Still Here

Yep, all quiet on the front, but not for any bad reasons or anything. I've been spending quite a lot of time working on the renovations in my house. Last summer, my wife and I started working on fixing up our house for when we finally decide to sell it and move closer to work. My living room was in a nice state of plaster covered with drywall mud when school started. 9 months later, I got back to working on it. You know you're in education if your life is school 9 months of the year. I can safely say that it's about 75% done -- 3/4 of the room is completely done and the other 1/4 isn't much beyond having the walls stripped and ready to start with mud. It'll probably be pretty close to completely done by the end of the week, thankfully.

Codewise, I'm still working on the GUI designer foundations -- list controls, buttons, and checkboxes work right now. There is still a ton of work before it's worth using for anything, but I'm not giving up. I've been working a bit on the development branch of Paladin, too.

The last couple of days I've been working on an alternative using SoftwareValet packages. The reason? Release time for Paladin is a major pain in the neck, mostly because the same set of procedures needs done each time and they have to be done manually. This, on more than one occasion, has led to mistakes in the package, in the build, or something else. This goes back to one of Joel Spolsky's questions in his 12 Steps to Better Code article. If you've not read this article and you are either a developer or work with one, you should definitely read it. To save the rest of you who don't want to bother, you should have it possible to make a build -- from checkout to compiling all the targets -- in one step. The BeOS platform doesn't have something like that... yet.

It's Official: Paladin 1.0!

At seven months old, Paladin certainly isn't going to win any age records, but it's nice to see how far it's come since last November when I first started it. It's been a couple of months since the RC6, but that's actually a good thing -- it's taken some time to find some of the bugs that have bitten the dust in this release. I'm also at the point where pretty much the only time I use BeIDE is to debug Paladin. All of my other work, such as the GUI designer, BeVexed, BeMines, and so on, have been done using Paladin. It feels great to have really scratched an itch that I've had for such a long time. I spent yesterday putting GCC4 fixes into the code for both development branches, and now the community has an IDE for both GCC flavors. I'll still be patching any bugs that might crop up, but it is feature complete and stable at this point.

For those of you that haven't played around with it, here are some of the differences between BeIDE and Paladin:

• Open source - you can pretty much do anything with its code that you want, except change the copyright on the original sources.
  
• Group non-code files -- notes, TODO lists, etc. -- in with your code for better organization
• Support for flex and bison out of the box
• More ways to execute your program, including logging debug output and setting run arguments
• Support debugging with gdb in Haiku
• Project files are in an open format
• Projects can be built from the command line
  

And this is just for the stable branch that came out today. Just so you know that I haven't been *just* fixing bugs, the development branch sports additional features, like makefile generation, better multithreaded build support, better integration of resource files, shell script support, and fast project backups. With the stable branch reaching 1.0, I'll be putting out periodic development builds so that people who like living on the cutting edge can get new features while others can get hold of a rock-solid build they can depend on. I'll be doing all of my development with this branch so that bugs can be found and fixed as features are added.


I've also added GCC4-only packages to BeBits so that anyone running it can conveniently get an alternative to just Pe and jam or make. I'm having problems uploading the new release to Haikuware, but I should have that resolved before long.

And for those of you about to code, we salute you. ;-)

More Component Work Done

Since Sunday I've managed to get some harder code written in the component system for this GUI designer I'm working on. I was surprised at how much work was required to support the AddChild and RemoveChild methods for windows and views. It's not quite there yet, but it works well enough for some of my test code to work on other things.

The component code allows for something like reflection -- you can get a list of interfaces that an object supports and a list of its properties, so if an object implements the PView interface, you can, for example, expect to be able to change its ViewColor property and see its background color change. One of the coolest parts of the API that I've built is that I changed *one* name in the code and rebuilt the test program and a button became a checkbox! The component API itself doesn't lend itself well to manual coding -- more effort is required to set and get properties, for example -- but it isn't really intended for that. Getting a list of an object's properties, making an editor for each, and modifying the object's values from these editors will be very easy and not require very much effort.

All of this hammering on a project has also exposed some small bugs in Paladin's stable and development branches, including a crash that I fixed last night. As soon as I can get PalEdit's sources fixed to build with GCC4, the official 1.0 release will be going out the door. Man, I love summer vacation!

Pythonizing C++

Yep, I'm still working with that possible GUI designer. It's been fascinating. To do a designer properly, you need some way of dealing with all of the different controls in an abstract way of dealing with properties and methods. The main problem for this in BeOS is that C++ doesn't like dynamic interfaces. At all. Luckily, I've managed to take some cues from Java and Python and the result seems to be both pretty flexible and reasonably elegant. Check this out:

PObject *o = NULL;
o = NewObject("PWindow");

StringValue sv("FooWindowTest");
o->SetProperty("Title", &sv);
RectValue rv(BRect(100,100,500,400));
o->SetProperty("Frame",&rv);

BFile file("/boot/home/Desktop/test.plg",B_READ_WRITE | B_CREATE_FILE | B_ERASE_FILE);
BMessage msg;
o->Archive(&msg);
msg.Flatten(&file);

In these reasonably few lines of test code, I not only manage to create a window in the upper left corner of the screen in a thread-safe fashion, but I can even save it to disk and recreate it in the exact same state as I left it, and the code is refreshingly short:

BFile file("/boot/home/Desktop/test.plg",B_READ_ONLY);
BMessage msg;
msg.Unflatten(&file);
PObject *o = (PObject*)UnflattenObject(&msg);

The backend code is only 5 or 6 files of reasonable length, but even so, I'd be hard-pressed to do the same kind of trick using regular BWindow and BMessage code in anywhere near the same amount of code. Then again, maybe I'm just overly excited. *shrug*

What's the significance of this technical rambling? The designer, assuming no other major roadblocks from here, will be very flexible, relatively easy to code, and pretty simple to extend with classes not bundled with the operating system. Code generation may not be all that difficult, either, but only time will tell on that one.

Keeping Busy

As of three weeks ago, I was in the throes of futzing with Python to make a clipart manager for Linux and hit what seemed to be a brick wall. For the most part, it is... that is unless you use Qt. Looks like PyQt4 is going to be the route for the API at this point. I've taken a break from that for now while I'm in the process of learning to use it, but I'll be coming back to it later.

Paladin has seen some renewed development. The last time I was actively developing it, I was in a burst of activity that kind of burned me out a bit. After a little time off, I'm back at it. There have been some bugfixes and it looks like there are enough that a new release isn't far off. There are a bunch of things that have been fixed and there is even work on getting it to build under GCC4.

I've also stumbled into actively looking into something that I thought was going to wait for later: a GUI designer. Yeah, yeah, there's MeTOS, BeBuilder, Bic, BeXL, and probably a few others. Each has their own problems and limitations. The biggest problem I see is a lack of active development, especially in light of the slow-but-steady progress Haiku is making. None of the open source ones seem all that usable -- though each has some nice features -- and there doesn't seem to be anything new brought to the table aside from an easy way to piece together the GUI. Right now, I'm working on a component model that so far seems to do its job pretty well and as far as I can tell is language-agnostic, making the use of something besides C++ (yab, Python, Perl, etc.) not too far-fetched. We'll see what happens.

School lets out for the summer tomorrow, so there should be some significant stuff happening in the next couple of months. Should be fun to see what, um, develops.