Hello all,
GSOC 2011 is over, and the SDL 1.3 for Haiku is over- for now. I intend to continue working on the project, although I probably won’t start again for a while, as the recent errors have been frustrating and I need to relax a bit.
The almost-most-recent-version is available at https://bitbucket.org/antifinidictor/haiku-sdl-1.3/; I had some problems with my computer and haven’t been able to upload the most recent version yet, which just has some changes to which functions are static and which aren’t.
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.
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
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.
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.
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.
