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.h) the class provide some methods to access the field-type of a particular fields and give an interface able to manage properties and parameters as well. At the bottom there are some classes that implements BContactField, they will be used directly by the user, let me give some examples :
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). ztest is a userland test, so actual file system modules or disks are not involved in the testing procedure -- ztest creates block files in a temporary directory and treats them as disks.
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.). If you have ideas for achievements please file them in the issues tracker
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. Python simply returns the status code.
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.) I also have replaced VBoxApp (which currently handles clipboard sharing) with VBoxTray, a replicant which serves the same purpose but can be autoloaded by Deskbar.
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. So far I have had trouble pushing my repository to the project site; it’s a lot of information, and takes about five hours. I’ve tried twice and it failed both times, although the failure may have been due to other things running; I’ll have to try again tonight.
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. They will later be expanded to allow creation of custom objects based on them, so users could subclass a Looper or a View the same way they can now subclass Application and Window.
Here is a topic that for the longest time as a BeOS/Haiku developer, I had no idea how to do and didn’t really feel enthused on the concept of learning. Of course, now all the major platforms have desktop gadgets. Ironically, writing a replicant is really easy if you already know how to write basic Haiku GUI applications already. Find out how in this lesson.
Programming with Haiku, Lesson 21
