It’s been a while since I last wrote something here on Blog-O-Sphere. Probably most of you don’t remember me anymore - but I’m still around, still experimenting with things Haiku in my free time.
During the weekends, I’m working on enhancing a very old BeOS application long lost in time. While browsing the Haiku kit and application source tree, sometimes I stumble upon some new (at least for me) but also interesting small elements that Haiku added to the Haiku API during its development. I like to try these elements out. Most of these API additions might change or even disappear in the nearest future, since I understand their development process is not yet finished, but they’re interesting to know nevertheless.
I know some of these additions might be obvious to those up-to-date with the Haiku source code. But maybe some readers will find this at least a bit informative.
From my latest post, i had to do more work on the base classes, i realized that my implementation of BContactField was too inflexible for the use so my progresses were not fast as i hoped. The main problem was to provide something that can fit the simplicity of the Person format (people files) and the complexity of VCard. The result was BContactField. Starting from a number of fields (defined in ContactDefs.
My midterm goal was porting libzpool -- which contains most of the ZFS code -- to Haiku. Another midterm goal was to get ztest -- the ZFS testing tool --- to run on Haiku. Being able to run ztest in a loop for an entire day means that about 80% of the ported code is working fine (though the remaining 20% is the most difficult part of the entire porting process).
I’m in the middle of my planned vacation in New Mexico. I recently wrote a new feature for haikuporter emulating the style of homebrew’s create command. (It makes as much of the bep file for you as can be automated.) I’ve written a haikuporter (or later pkgman) wrapper to handle the achievements. It works like git-achievements you alias over the command and check the switches/commands. I’ve moved over some code to redis, and have gotten their development branch to build on alpha3 (Stable used to work back a few revs.
Alas the time of my contract with Haiku, Inc. is up. So besides giving some details about the query support and libsolv port which I've been working on since my last post, I'll also summarize where Haiku's package management stands now and what still needs to be done.
A status update for those interested:
Bindings now return multiple values when appropriate (this was not working before).
Bindings now return undef (in Perl) or None (in Python) for a NULL object pointer; previously a target language object with an underlying NULL was returned, which obviously caused problems.
For errors, Perl returns undef and sets an error variable. Python raises an exception. However, when the status code is also the return value, Perl returns true if there is no error.
Shares fully working! Slightly slow, but usable. Clipboardy stuff too.
I’ve now fixed most of the bugs in the guest additions, to the point that what’s done so far is mostly usable - the only major bugs remaining are some random crashes in VBoxService that I’ve not been able to reproduce, and an inability to drag icons when mouse pointer integration is enabled. (Thanks to kallisti5 for finding both of these.
So far: SDL 1.3 officially compiles. Whether it works is another story.
I’ve created 7 patches so far, four of which were created in logical pairs, one of which was completely useless. The 7th patch (SDL-1-3_patch06.diff) was sent out to the haiku-gsoc mailing list today, and should allow the code to compile. Note that not all functionality is implemented in the video code.
I’ve also started working on creating a Google code project to host my repository; this will make it easier to follow my progress if I succeed.
Since my last blog entry a lot of progress has been made. Currently I’m right on the cusp of actually producing images on the screen that have been captured by my camera. Successful communication is occurring between the driver and the camera in at least two different forms.
The first form of communication to be successfully implemented involves the setting of values within the camera which affect image capture. These are the familiar brightness, contrast, sharpness etc. settings which most cameras support. Nearly all of the options available to my camera are now presented for manipulation by end-users and successfully communicated to the camera. These values are maintained within the camera between power cycles and this fact is successfully communicated to the user via the available controls. The controls can be viewed and modified in the media preferences application or the cortex demo application. ParameterWeb control documentation indicates a range of different style controls within the continuous or discrete parameter varieties. However it appears to me that the only discrete value input method currently supported with an appropriate gui interface is the binary on/off option. This is suitable for features like the auto value for white balance which can only be either on or off. However the powerline frequency setting which has three possible values was unable to be represented with the appropriate discrete control of the B_RECSTATE type which has three possible states. To simulate this capability a continuous control was modified to only allow three values which are indicated by placing the sliding control within a +/-10 range of the desired value. The slider snaps to the available values to indicate this behaviour. One future feature which would perhaps be desirable is controls with auto settings which indicate in real time by their movement what values the camera is using in its auto mode. Right now sliders are simply frozen in their last position when the auto mode is in effect. I had some brief discussion with my mentors about this feature, but it was deemed to be unnecessary at this stage as a lot of work is left to be done in actual image capture.
The following objects have at least partial bindings:
From the Application Kit: From the Interface Kit: From the Support Kit: Application Clipboard Cursor Handler Invoker Looper Message Alert Box Button Control Font Menu MenuBar MenuField MenuItem Point PopUpMenu Rect Screen StringView TextControl TextView View Window Archivable At the moment, some of the classes are not very usable; they’re necessary because other objects inherit from them.
