The following classes have been implemented; some methods and functions have not been implemented due to dependencies on unimplemented classes, but the classes below are otherwise complete:
| From the Application Kit: | From the Interface Kit: | From the Storage Kit: | From the Support Kit: |
| Application
Clipboard
Cursor
Handler
Invoker
Looper
Message
Messenger | Alert
Box
Button
CheckBox
ColorControl
Control
Font
Menu
ListItem
ListView
MenuBar
MenuField
MenuItem
OutlineListView
Picture
PictureButton
Point
Polygon
PopUpMenu
RadioButton
Rect
Screen
ScrollBar
ScrollView
SeparatorItem
Shape
Slider
StatusBar
StringItem
StringView
TabView
TextControl
TextView
View
Window | Entry
EntryList
FindDirectory*
Mime
MimeType
Node
NodeInfo
NodeMonitor*
Path
Query
Statable
Volume
VolumeRoster | Archivable
Beep*
Errors*
TypeConstants* |
*These don’t actually contains any classes, Errors and TypeConstants expose constants; Beep exposes functions; FindDirectory and NodeMonitor expose constants and functions.
The following classes are now mostly implemented; there are some methods that cannot be implemented yet because they require objects that are not yet implemented, but otherwise these classes are complete.
| From the Application Kit: | From the Interface Kit: | From the Support Kit: |
Application
Clipboard
Cursor
Handler
Invoker
Looper
Message | Alert
Box
Button
CheckBox
Control
Font
Menu
ListItem
ListView
MenuBar
MenuField
MenuItem
OutlineListView
Point
PopUpMenu
RadioButton
Rect
Screen
ScrollBar
ScrollView
SeparatorItem
StringItem
StringView
TabView
TextControl
TextView
View
Window | Archivable
Errors* |
*Errors doesn’t actually have any classes, it merely exposes a lot of constants to the target language.
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.
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.
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.
During the first quarter, I defined an interface language to use for creating the bindings. I had to create my own for several reasons. Probably the biggest factor was the need to know whether the target language has the right to destroy an object. Most of the target languages has some kind of automatic garbage collection; the programmer never needs to worry about whether to delete an object to free up memory. I didn’t want to force programmers to worry about it when they don’t normally need to. Therefore, I had to be able to mark whether an object was delete-able, so the generated bindings could delete it automatically if necessary.
In my last blog post, I mentioned the following goals:
- Define an interface definition language
- Define preliminary bindings for a minimal test programy
- Write a preliminary generator to create the bindings
- Write the minimal test program
These have now been achieved, and the minimal test program (in Perl) runs. It shows a window with a button, and the button label changes when the button is clicked.
It still has problems, of course. For example, after 32 messages pass through MessagesReceived, it dies. But it’s nice to see something actually running.
During the bonding period I looked into Python’s extension tools; they seem to be straightforward and at first glance look relatively easy, so Python is definitely an option. I asked on the mailing list what other languages people were using on Haiku, and Neil kindly made a poll based on the results. Depending on the popularity of the language (based on the poll results) and the ease of writing extensions, I will make a final decision on which langauges to target during GSoC.
During most of GSoC, I will be in Faro, Portugal, where I am finishing my Masters. However, I will travel to Santa Rosa, California to visit family for five weeks in June and July.
Time Zones:
Mon 25 Apr - Thu 16 Jun: Western European Summer Time (UTC+1)
Fri 17 Jun - Thu 21 Jul: Pacific Daylight Time (UTC-7)
Fri 22 Jul - Fri 26 Aug: Western European Summer Time (UTC+1)
My project will expose the Haiku API to scripting languages. During GSoC, I will focus on enabling the creation of GUI apps; this will include large parts of the Interface Kit and some essential classes from the Application Kit. I will target Perl and Python as the scripting languages.
(After GSoC, I would like to support other languages as well, and increase the number of classes available from scripting languages.)
