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
Time does fly. It has already been two weeks since my previous blog post, so I guess an update is in order. The support for shine-through directories and the package links has been implemented as planned and works nicely as far as I have tested them. Other than that I've worked on a few odds and ends.
I’ve just uploaded some files onto http://dev.osdrawer.net/projects/perl-haiku-kits/files They are minimal implementations (window with a button) for Perl and Python. The Perl one works fine, but I’m still having issues with the Python.
Here are some of the issues with Python:
Apparently by convention packages start with a lower-case letter. The bindings are currently in the ‘Haiku’ package. This would be a trivial change; it depends on how important it is to Haiku’s Python user community.
A lot of commits have happened since I last blogged on my GSOC Project. The big hitters are:
- the framework of a rankings website for users’ point totals
- A non-regex parser I wrote because I’m impatient (I’m going to test its speed.)
- The begining of the http server that will inform user’s builddrones of availible jobs (builds) [Basically it tells you if packages have been updated so you can build them]
- Verified that Camlistore (on python) can work on Haiku.
- A Jenkins API wrapper for magic to happen (I think it may be the perfect thing to handle build logs and results)
- Redis
- Redis
- Redis
Progress is coming along, I recently [On the 15th] returned from a tour of France. There is a second period later in the summer I’ll have unknown-connectivity, but I’ll still be coding then.
After a week of working on the package management support as per my contract with Haiku, Inc., I have reached my first milestone: The base system is packaged... and it boots again. Here's a short account of what I have been doing exactly and what I'm up to next.
