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.
In these weeks i have improved the contacts kit core in order to have enough support for the formats supported. The vcard and people translators can now translate and exchange many types of field, though photo and groups aren’t yet supported.
Main functionalities of the classes :
BRawContact
Their functionality is to deal with the BTranslatorRoster and keep track of basic informations, like the final format. The final destination is represented as a BPositionIO object. Basically the class find a suitable translator when initialized and provide two methods : Commit() and Read(). The first has as argument a BMessage that contain Flattened BContactFields, the second translate the source file (that can be a B_PEOPLE_FORMAT, B_VCARD_FORMAT, B_CONTACT_FORMAT) into a BMessage and return it.
In these last few (official) weeks of Google Summer of Code I’m focusing on the meat of my project. This means that side features like the achievements, scoreboard etc will be ‘frozen’ as-is until after GSOC. I’m planning on rounding them out, just not yet. The main work will be on the builddrone working properly and testing/signing. A major but was in the camlistore python library, I’ve fixed it and will change how it works a little.
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.
Briefly, my goals for the three quarter term were: port libzfs, port the commandline tools zfs and zpool, and write a kernel module to communicate with userland tools via ioctl() calls on a /dev/zfs. Another goal was to make sure our port of ZFS passes all tests in ztest.
With the exception of a few missing routines, libzfs builds fine on Haiku. So does zpool. zfs requires some love, but nothing major remains to be done. In fact, with the exception of a few routines that I need to implement in libsolcompat (our Solaris compatibility library), the port builds almost perfectly on Haiku. But getting it to build is only half the battle ;)
So far SDL 1.3 for Haiku has made significant progress. Video draws correctly both with and without opengl, audio appears to already work, and various tests provided in the SDL test suite seem to work. However, there are a few significant bugs I have come across.
The first error occurs when resizing the window. The application occasionally receives the illegal operation signal or a SEGFAULT. The illegal signal operations occurred when blitting from the backbuffer I allocated to the screenbuffer provided by BDirectWindow’s DirectConnected() function. Presumably this was caused by the window being resized in the middle of a draw operation, since this error only occurred after I moved blitting to a separate thread. Before this, blitting was done in the application thread, and caused a slowdown of SDL’s event handling by up to 1 second (moving around the mouse required redrawing the window). I received several suggestions to fix this error, including move the blit code back to the application thread, use mutexes, and use BBitmaps. I have since transferred drawing operations to a BBitmap object, which appears to have removed the illegal operation signal. However, resizing the window continuously will result in the occasional SEGFAULT. I only discovered this error today; I intend to investigate it further over the weekend. So far I have noted that the SEGFAULT occurs in different places on different runs, although I have not officially found a connecting pattern.
New status report:
major feature dropped; bugs fixed;
did some screen research.
At the start of the third term, it was pointed out to me that Haiku does not actually support hardware 3D acceleration, and to add it would be a larger project than I have the time (or knowledge) for. Therefore, I’ve had to drop host-accelerated OpenGL from the planned features. I’m somewhat annoyed by this, but looking back it was probably a bit too ambitious anyway, and I’m not convinced I could have finished it in time.
Not so long ago, at the half way mark of the GSoc, I was optimistic that I was near to actually interpretting data from the camera in such a way as to produce images on screen. I was successfully grabbing payload data from the camera, the camera’s in-use light was on, things were looking good. Since that point, progress has been repeatedly stalled by strange and difficult to debug behaviour.
Once again, the idea that tracker should use single-window mode was raised as a trac ticket. This discussion was made multiple times on the mailing list, and each time the answer from the developper was no. However, users still seem to prefer the single window mode, and other OS are switching to it. Maybe we just need to explain how to efficiently use this mode, and why we think it’s better. I’ll try to do that in this blogpost, with my own point of view on it.
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.