1. Home
  2. Community
  3. Google Summer of Code
  4. GSoC 2014
  5. Ideas

Ideas

For information about Haiku's participation in GSoC this year, please see this page.

Qualifying students can apply for a Haiku project (see the list of suggested projects below) between March 10th and March 21st, 2014. For details about how to apply, please check out Students: How to Apply for a Haiku Idea.

According to other mentor organizations, the most successful Google Summer of Code projects are the ones proposed by the students themselves. The following list represents our ideas and wishes of our project. However, suggesting your own idea is encouraged!

Be aware: API and user interface design requires a higher level of skill. A significantly more convincing proposal is required for tasks involving those. Getting started with the design early (before the coding period starts) is recommended, to maximize your chances of being selected, and allow a bigger part of the coding period to actually be dedicated to coding tasks.

If you find an idea marked as "big" interesting but feel you cannot completed in time, feel free to suggest splitting it into smaller parts in your proposal.

Many of these ideas are not sufficient as stand-alone projects and would need to be combined with others on this list or of your own suggestion. We expect students to build on the ideas to make a complete project proposal.

Students, who intend to submit applications on ideas that are part of other accepted mentoring organizations, need to contact both Haiku and the other mentoring organization.

Project Areas

Applications

Updating and Extending WebPositive

Haiku uses a WebKit based browser called WebPositive. This task could involve:
  • Improve the network backend. WebPositive has been switched to use Haiku's native network backend instead of cURL. The backend can be improved, one beneficial task would be to implement an efficient caching layer.
  • WebPositive has lots of room to improve as an application. For example it is lacking session management, where it can restore all open tabs from the last session.
  • The graphics platform port in WebCore is not complete due to missing features in the drawing related BView API. Fixing this involves implementing missing functionality in BView and app_server (line dashes, shadow effects, ...), then making use of it in WebKit.
  • There are various WebPositive related tickets.
  • Skill set: userland development, exploring a large code-base (WebCore)

VirtualBox port to Haiku

A port of VirtualBox to Haiku, would allow developers and users to run another operating system within Haiku. Preliminary VirtualBox port to Haiku
  • Skill set: userland development, kernel development, possibly x86 assembly

Calendar application

Create a native calendar application or port an existing calendar application to Haiku. The app should support creating events and saving them to event files augmented with attributes similar to how People file work for contacts. Additional features of the calendar app might also include support for recurring events, integration with other calendaring software such as Google Calendar or Microsoft Outlook™, and vCalendar support ; CalDAV synchronization, import of iCal files, and more.

You should review existing calendar applications on Haiku/BeOS and other operating system to find out the key features for such an application. Then, decide if one of the applications linked above may be used as a starting point, or if it is better to start from scratch. Aside writting the application itself, it may be useful to improve the BDate, BTime and BDateTime in Haiku to make it possible to do date math easily, work with different timezones, and format dates represented using these classes, as well as relative durations ("Today", "2 days ago", ...), in a localized way.

Some applications to look at for inspiration/examples:

  • http://www.pulkomandy.tk/~beosarchive/?file=archive/source/utils/Organizer.zip
  • https://github.com/HaikuArchives/Eventual (for screenshots, see: http://sourceforge.net/projects/eventual/)
  • http://haikuware.com/directory/view-details/info-management/personal-information-managers/a-book
  • Skill set: userland development, user interface design, possibly network development.

Updating Mail

Haiku's built in Mail application is in need of various improvements. Some of the issues include from re-writing code to adhere to style guidelines, utilizing the Layout API, utilizing proper object oriented programming concepts, addressing race conditions, and GUI improvements.

In addition to that, you may have your own ideas how Mail could be improved to meet today's expectations of a great way to view and edit your mail.

  • Skill set: userland development, user interface design, possibly network development.

Other applications

There are many open source 3rd party applications for Haiku that coud use improvements. Whether it is resolving bugs, adding features, updating the coding style, updating them to use the Locale Kit and Layout API, or anything else imaginable! Writing applications from scratch is also possible.
  • Caya (IM client)
  • Torrentor! (source)
  • https://github.com/HaikuArchives
  • http://pulkomandy.tk/projects
  • http://pulkomandy.tk/~beosarchive/
  • http://wwww.haikuware.com
  • Skill set: userland development, user interface design, exploring an existing code base, others depending on the application retained.

Drivers

USB Support for FreeBSD network compatibility layer

Haiku uses a FreeBSD network compatibility layer to support many network devices (ethernet and wireless) using drivers written for the FreeBSD project. However, this layer only supports PCI devices, and doesn't work with USB ones. Adding support for USB to the compatibility layer would bring us support for a range of devices like so-called USB tethering, as well as USB to Ethernet and WiFi dongles.

Suggested work: Import USB drivers, implement the missing parts of the layer, test and validate with emulated or/and physical USB devices.

  • Requirements: an Ethernet USB device for testing (most smartphones can do this).
  • Skill set: kernel and driver development, USB, general C and C++ development

virtio network and balloon drivers

Haiku already has a virtio bus driver, and a virtio disk driver. The addition of a virtio network card driver and a virtio memory balloon driver would enable Haiku to take advantage of emulation speedups using the lightweight virtio bus. Haiku could also be deployed in environments such as Amazon s3 or OpenStack. To complete this task, a fully stable virtio network card driver would need to be completed and tested as functional as well as a working virtio balloon memory driver.

ACPI Video Extensions

ACPI Video Extensions, as specified in ACPI Spec 4.0a Appendix B, adds special support to handle multiple output devices such as panels and TV-out capabilities, brightness control as well as special power management features.

Suggested work: Detect attached devices for display adapters, implement a basic driver for a display, allow display switching and brightness control.

  • Requirements: computer with ACPI that has Acpi Video Extentions (_DOS _DOD and so on)
  • Skill set: kernel development, general C/C++, userland development

AV/1394 support

Our Firewire stack supports DV receiving, but not controlling the A/V device (ie play/stop). This requires to modify the Firewire stack for FCP frame support. See AV/C Digital Interface Command Set General Specification for reference.

  • Requirements: a DV camera, a machine with a Firewire port.
  • Skill set: kernel development, API design, general C/C++, userland development

TTY Layer

The TTY layer is needed for proper serial port support in Haiku. Until now the serial port was reserved for kernel debugging, but it is now time for proper userland support.

Currently, the TTY layer is written mostly with the usb_serial in mind, so it uses stuff that might not be easy or possible at all to use in more low-level drivers (like pc_serial). The API could use improvements. Locking issues exist. Also the generic module is not yet in the image due to these, and the pc_serial driver itself is still untested.

  • Skill set: kernel, and driver development
  • Tickets: #35, #3232
  • The TTY demystified, a good article about what a TTY is (not Haiku specific).

LibUSB port

LibUSB is a portable library to access USB devices from userland. The existing port isn't complete, and fails to work with almost all LibUSB based applications. Make it work on Haiku and port applications such as sane, avrdude, and more to test the port. Haiku already provides similar functionality in the form of the USB Kit, but a LibUSB port would enable use of existing applications without modifications.

You should study the existing libUSB code and get it to work with one of the applications that use libUSB. Examples applications are avrdude, dfu-uploader, openOCD, Sane. This task requires a compatible USB device for at least one application using libUSB for testing.

  • Skill set: USB
  • Existing porting effort: https://github.com/pulkomandy/libusbx

Nouveau / PSCNV port

Haiku currently doesn't have a driver for NVidia video cards, and falls back to VESA for those. While our VESA driver is reasonably fast, it can't set the native resolution on all systems, leading to a suboptimal Haiku experience. Nouveau is a graphics driver for NVidia video cards. There is a fork called PSCNV which might have less dependencies on Linux. cf. https://github.com/pathscale/pscnv/wiki

Port (parts of) Nouveau to an Haiku graphic driver, allowing at least setting the native video mode. Hardware 3D acceleration may also be investigated, but requires more work on Haiku

  • Skill set: kernel, and driver development

Kernel

UEFI Bootloader x86-64

Haiku currently lacks a UEFI boot loader. The code for making Haiku build an UEFI application with the boot platform already exists. You will need to write the actual boot code that sets up the CPU to boot Haiku. To your help you have the boot code for BIOS x86/x86-64 and serial debugging with printf. Development can be done in QEMU with UEFI firmware and serial output. UEFI API is very simple and learned quickly, major skill needed is booting x86-64 platform. This does not have to include Secure Boot.

Haiku code to load the kernel is located in src/boot/platform. You can see the different implementations.

The EFI version in that tree builds the bootplatform code, can run as a EFI application, can call EFI functions, but not much else. What needs to be done is setup CPU, MMU, handle kernel args, load kernel, some drivers (at least Vesa) that uses BIOS functions needs disabling. Basically everything needed to setup and boot a x86_64 platform once the EFI app is started is missing.

Userland tools for EFI is also missing, so modifying and viewing boot options could also be part of the project. It would need a driver for Runtime services and an application to set/get variables.

If you are interested in this I suggest trying to set a time schedule and see what parts you can fit in your GSoC. I rather see some parts done well and properly tested than focusing on to much.

Possible extentions or alternative GSoC's
  • Application/driver to handle boot options and install bootloader similar to efibootmgr in Linux
  • Make 32 bit version of bootloader (target and most platforms are 64 bit)
  • Secure Boot
Additional information:
  1. Our simplified GNU EFI (good for learning UEFI/QEMU): https://github.com/tqh/efi-example
  2. Current EFI development tree (take a look at the commit history and build instructions)
  3. UEFI API information: http://wiki.phoenix.com/wiki/index.php/Category:UEFI_2.1
  • Skill set: kernel development, x86/x86-64 architecture/assembly, bootloaders, QEMU

Power management

Improve power management in Haiku. Haiku has recently had improvements in CPU idling, but there is more to be done. Investigate what is using power and what can be done to improve the situation. This can be work on making Haiku tickless (used in networking/wifi atm), reducing interrupts (perhaps for polling), fixing bad code and adding power management for devices.

  • Skill set: kernel development, general C/C++, userland development, debugging, power management / measurement

File Systems: general improvements (write support: BIG)

Haiku has great support for its own file system, but most others are only available read-only, or not at all. It is way better for interoperability with other systems to be able to read and write to these disks. To give you some examples what you could work on:
  1. ReiserFS, BTRFS, exFAT: write support
  2. XFS, UFS2, ZFS: Read (& Write) support
  3. SMB, Windows shares: Read (& Write) support
  4. HAMMER FS: Read (& Write) support
  5. SquashFS: To support booting Haiku off SquashFS on a CD/DVD
It's okay to port over the code from other systems, although we prefer code that can be distributed under the MIT license.
  • Skill set: kernel, and driver development

IMAP FS: File system access to an IMAP account

In Haiku emails are stored as individual file with extended attributes. Mounting an IMAP account as a local file system is therefore a natural fit. The file system should have full read and write support (deleting mails (files), creating folders, and moving mails between folders, etc.) with local caching for better performance.

  • Skill set: kernel and file system (driver) development, network development

x86-64: Support for 32 bit userland

Since Google Summer of Code 2012 there's a x86-64 port of Haiku. The kernel only supports a 64 bit userland, though. A compatibility mode should be added, so that 32 bit programs can be run as well.

  • Skill set: kernel development, x86 architecture/assembly

ARM port

The ARM port of Haiku is currently not booting. Using the hardware of your choice (we can provide a development board if you don't have one), or an emulator such as QEMU, improve the port and make it boot further. This will involve fixing the kernel code, and writing drivers for the chosen hardware (serial port, mass storage to load the userland, then later on video and ethernet).

A preliminary task is getting Haiku bootstrap build to work, allowing you to build the required package files for a minimal Haiku system to work with.

  • Skill set: kernel development, ARM architecture/assembly

Unify File System Caches

The Haiku kernel provides two kinds of caches for use by file system implementations: the file cache and the block cache. The file cache uses physical memory pages directly and it is linked with the VM subsystem, so that pages used for caching are freed automatically (in a least recently used order) when running low on free memory. The block cache, however, uses mapped memory (via the slab allocator) and freeing memory in low memory situations is handled via the low resource manager. Using different mechanisms to deal with low free memory situations leads to a caching imbalance in favor of the block cache. Furthermore the block cache uses large amounts of kernel address space, which can be problematic on 32 bit architectures. The goal is to create a common underlying mechanism (using `VMCache`) to unify both caches. Solutions must be found to interesting problems like how to deal with different block sizes (not necessarily matching the page size) and how to map support for transactions to `VMCache` hierarchies.

  • Skill set: kernel development

Network

Bluetooth Stack Improvements

Haiku Bluetooth Stack implements basic functionality on lower and middle layers, this functionality needs to be completed and Bluetooth 2.X possibilities explored.

  • Requirements: Bluetooth enabled Haiku system
  • Skill set: C++, kernel development, userland development, global bluetooth stack knowledge(optional)
  • Tasks: RemoteDevices Database, UserLand tools(Preferences), Pairing/Auth/Encryption use cases, etc.

Integrate our PPP implementation

Port the PPP implementation to our new network stack. Add phone-line modem support, including HDLC framing and VJC compression (porting both algorithms is sufficient, but make sure the license is compatible to MIT). Implement CHAP authentication. Find and fix bugs.

  • Tickets: #812, #869, #873, #922, #923, #1059, maybe: #1057, #1058
  • Skill set: multi-threading basics, maybe network protocols and some kernel/drivers development, maybe UI development

Stream Control Transmission Protocol (SCTP)

Implement and test SCTP, a message based transport layer protocol similar to TCP and UDP. It should comply with current IP and IPv6 implementations and provide similar programming API as BSD.

  • Skill set: network protocols, kernel and network stack development

IPv6 Polish

The base framework for IPv6 support was implemented as a Google Summer of Code 2010 project. Even so, there remains a lot of smaller cleanup/polish tasks that can be done as a project.

  • Tickets:
    • #8293 -- BNetworkAddress needs to check if there is an available IPv6 connection.
    • #7228 -- RFC: BNetworkInterfaceAddress needs to store auto-configuration flags
    • #6489 -- ifconfig needs to validate availability of ipv6 module prior to utilization
    • #2632 -- Possible redefinition for struct sockaddr_in, related to IPv6
    • #8319 -- Haiku needs IPv6 duplicate address detection during link scope ip configuration.
    • #8317 -- Haiku needs IPv6 global scope Auto Configuration (router advertisement + DHCPv6)
  • Skill set: IPv4 and IPv6 protocols, kernel and network stack development

User Interface

Preflet GUI refactoring

Several preference applications (aka preflets) could be redesigned. Furthermore, there might still be code that does not yet use our layout API. This work may include (but is not limited to):
  1. combining Keymap and Keyboard
  2. combining Mouse and Touchpad
  3. #6983Printer
  4. #6206integrate scrollbar options into a new Appearance preflet
  5. Shortcuts
  6. Notifications
  • Skill set: c++, UI development, usability basics

Modular edit view (BIG)

Many Haiku applications are using their own edit view to provide basic editor functionalities. All these implementations work a little bit different and create an inconsistent user experience. One solution is to provide a modular and powerful editor view that could be used in various Haiku applications.

The edit view design should be modular and extensible to make it easy to implement e.g. following features:

  • syntax highlighting
  • spell checker
  • code completion, word completion
  • line numbers, ruler, 80 character limit line, hyper links
  • working on an input stream rather than on a input file e.g. to be able to open files ~100Mb without loading them into memory in one go.
  • interface to external applications e.g. to jump from a compiler error to the according line in the code

Reuse of existing syntax highlighting libraries may be possible, provided they can be connected to a native Haiku view. MIT license would be preferred for the external library.

  • Skill set: C++, UI development

Media

Add subtitle support to the Media Kit

While our MediaPlayer has support for external subtitle files, the Media Kit itself has not. The most obvious downside of that is that there is no support for subtitle (text or bitmap) embedded in video files within the MediaPlayer or other applications.

Your job would be to design the necessary API extensions to let subtitles fit in with the rest of the Media Kit, and add native support for them, which will then be available to all applications as part of the framework.

Merge CDPlayer into MediaPlayer

The functionality of CDPlayer could be migrated into MediaPlayer, allowing the play back of audio cd's. An alternative to CDPlayer's (outdated) way of controlling the device in a low-level fashion would be to make it use the wave files as presented by the cdda-fs, subscribe to volume mounts via BVolumeRoster, present a menuitem for the CD similar to one for DVDs in the VLC Media Player, having this option populate a playlist and start playing.

  • Skill set: general C/C++, userland development

Implement system wide and application level input/output chooser

When more than one soundcard is attached to Haiku, you can only change the default input/output in the Media preferences, or reconnect media nodes manually via Cortex to another input/output device. The Media Kit could support default nodes per application (either unset (system default), or set to a specific device), and the Media preferences could offer an UI to change this.

Additionally, applications like MediaPlayer, and SoundRecorder should be able to change the input/output device within the application, too (which would just be another way to alter the described Media Kit functionality).

This functionality should only be visible if there actually is more than one audio device attached to the system; if a device is not available, it should automatically use the default output instead.

Part of this work would be to implement non-volatile storage that the Media Kit uses for each application that is connected to it, and the ability to detect the application on next start. This storage could then also be used to remember other per application sound settings in the future (or if time permits) like the balance, and relative volume.

  • Skill set: general C/C++, userland development

Streaming support for Media Kit and applications

The media kit and related applications in Haiku relies a lot on the BMediaFile being seekable. This makes it difficult to use with non-seekable media sources such as internet streams or DVD media. Rework what's needed to get them working properly.

  • Skill set: general C/C++, userland development

Other

Trac Plugin: "Test and Commit Patch" functionality

Several developers have requested the ability to simply press a button that would trigger an automatic system to test and (conditionally commit) a supplied patch.

  • Skill set: Python

Add Haiku support to Allegro 5.0

Allegro is a gaming library, it has support for BeOS/Zeta/Haiku in the 4.4 branch, but they dropped BeOS from the 5.x branch. Now that Haiku is in a usable state it would be nice to get the latest builds of Allegro 5.0 working on Haiku. It's still unclear if Allegro will be applying for GSoC but they do have a developer who'd be willing to co-mentor this with a Haiku mentor.

  • Skill set: C++, userland development

Graphical project manager tool

BeOS had CodeWarrior IDE built-in, which makes it easy to create a new project and get started on development. Haiku currently only provide make and jam in the default installation, which is far less easy to use for starting developpers. The makefile engine is somewhat simpler, but more limited. All of these tools are to be used in text mode, not so good for beginners. Create some graphical tool to easily get started on 3rd party development in a few clicks. No need for a full-blown IDE.
  • Skill set: C++, userland development

Tracker add-on for a version control system

Windows has TortoiseSVN and TortoiseGIT. Choose your preferred VCS, and do something similar for Haiku's Tracker.
  • Write a Tracker add-on that has the functionality to let you carry out most daily needed tasks when using the VCS.
  • Extend support in Tracker itself where needed: icon overlays, custom file menus, ...

Modify the app_server to support compositing

This would be a step towards faster/smoother scrolling, window positioning and drawing. Once compositing is in place, it would also be possible to create Compiz-like effects in Haiku, eg. drop shadows, transparent windows, content previews, and window animations.

There's lots of info on what would need to be done and how to go about it in this article: /articles/2011-06-15_how_transform_app_server_code_use_compositing .

  • Skill set: C++, graphics development

Evaluate Qt as a potential Haiku R2 API

While in comparison with other frameworks the BeOS API was quite nice back in the day, save for a few additions (like layout management, an improved archiving mechanism, tool tips) very little has changed since. Particularly the interface kit leaves a lot to be desired these days, both in general design and completeness. The Qt toolkit on the other hand has evolved quite nicely over time and now presents a very complete and for the most part well designed API. This project shall evaluate Qt as a potential native Haiku R2 API, replacing partially or even completely the previous BeOS/Haiku API.
  • Analyze the current state of the Qt 4.x port, update to 5.x, and add/complete what is missing/incomplete.
  • Add extension in or on top of the Qt API to provide access to Haiku specific functionality (attributes, entry_refs, resources, translators, etc.)
  • As a proof of concept port an existing Haiku application (e.g. StyledEdit) over to the extended Qt API.
  • Skill set: C++, API development

Port the Go programming language to Haiku

The Go Programming Language is a relatively new programming language that is open-source and was created by Google. It has been getting a lot of traction recently and it would be nice to have a Haiku port.
  • Get Go's build system working under Haiku (there is actually code to do that already).
  • Implement Haiku specific code in the runtime and syscall packages.
  • Implement Haiku specific code for garbage collection and the runtime scheduler.
  • Get "Hello World" fully working.

Menu