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). For details about how to apply, please check out Students: How to Apply for a Haiku Idea.

The most successful Google Summer of Code projects are often those proposed by the students themselves. The following list represents some of our ideas and wishes for the project. However, suggesting your own idea is always 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 application period ends) is recommended, to maximize your chances of being selected, and allow a larger part of the coding period dedicated to coding tasks.

If you find one of the "big" ideas interesting, but feel that you cannot complete it within the allotted coding time, feel free to suggest splitting it into smaller parts for your proposal.

Students that intend to submit applications on ideas which are also part of other accepted mentoring organizations must coordinate with both Haiku and the other mentoring organization beforehand.

Applications

Updating and Extending WebPositive

Haiku uses a WebKit based browser called WebPositive. The browser is still quite simple and can be improved in multiple ways. Some of the missing features are:

Advanced session management. There is minimal support for restoring tabs from the last closed window, but a more complete solution is desirable. The web browser should be able to store its whole state (multiple windows and tabs) to a session file, and restore the state from that file.
Management of broken HTTPS certificates. There should be a way to remember exceptions to the system-wide certificate list.
Support for browser extensions, such as ad-block. This could be done either reusing extensions from other browsers (if possible), or using the native add-ons system.
Skill set: userland development, user interface design and programming
Possible mentors/knowledgeable people: PulkoMandy
Sourcecode
Opened tickets

Extending and improving the Services Kit network backend

The Haiku API includes a framework for performing requests to websites using HTTP and other protocols. This is similar to curl or soup which are often used for that purpose on other systems.

This library is used by many Haiku applications, including the WebPositive web browser and HaikuDepot package manager.

The goal of this task is to rework the implementation to improve performance and fix design issues. As a result, the code would be cleaner, safer, and faster.

Reworking the Service Kit to avoid spawning one thread for each network request. The requests should be allowed to run in an existing thread, or to be grouped together (by use of select() or poll() to wait for activity on their sockets, then dispatching events to the BNetworkRequest objects). This would remove some of the overhead of creating a request and solve some design issues in the Services Kit API.
Implementing HTTP 1.1 support, allowing the reuse of the connection to an HTTP server to perform multiple requests. BHttpRequest objects should be reworked to be able to use an existing HTTP 1.1 connection, and a way to store existing connections should be added.
A caching layer for HTTP requests. There currently is no cache which means some requests are made again and again to the same server. The cache should keep the result of these requests on disk and/or in memory, making it possible to reuse them and load web pages faster.
Complete support for HTTP proxies. While there is currently limited support, it is not possible to do HTTPS requests through a proxy. This should be added, as well as a system-wide user interface to configure and manage proxies.
Implementing FTP support. The services kit is designed to support multiple protocols, but currently only HTTP and Gopher are supported (as well as the local "file" and "data" protocols). FTP support in the web browser would be helpful.
Skill set: userland development, network programming, threads.
Possible mentors/knowledgeable people: PulkoMandy, Jessica Hamilton
Sourcecode

Improving Haiku's WebKit1 port

Haiku has a native WebKit port which uses the WebKit1 API. This port is not complete and there are several bugs and minor problems which needs to be fixed.

There are rendering problems on many web pages. Most of these happen because of missing features both in the WebCore graphics implementation and in the Haiku app_server. This includes missing or incomplete support for dashed lines, shadows, perspective transforms, and probably some bugs in already implemented features. These should be implemented so websites look closer to how they were designed.
Another missing feature is the ability to load fonts into app_server dynamically. Currently the Haiku API only allows using existing fonts installed in specific system directories. This should be extended so WebKit can make use of fonts it downloads from the web. Some websites use these as pictograms, and not having the correct font results in unuseable websites.
Skill set: userland development, exploring a large code-base (WebCore)
Possible mentors/knowledgeable people: PulkoMandy
Sourcecode
Opened tickets

Migrating Haiku WebKit port to WebKit2

Haiku has a native WebKit port which uses the WebKit1 API. Since this port was made, the WebKit project migrated to WebKit2, which provides several new features and separates the work in several processes to limit the impact of crashes in one or the other.

The goal of this task is to get WebKit2 to run on Haiku. This involves implementing the required inter-process communication primitives in WTF (first reusing the UNIX socket support used on Linux ports, then migrating to BMessages if this is relevant/useful), and writing a WebKit2-style API for WebKit, which can be used in native Haiku applications. Proof of concepts could be a minimal browser, an update to the existing WebPositive, or adding a web view to existing applications such as Mail or fRiSS.

Skill set: userland development, exploring a large code-base (WebCore)
Possible mentors/knowledgeable people: PulkoMandy
Sourcecode

VirtualBox port to Haiku

VirtualBox is a virtual machine allowing to run an operating system inside of another. Porting it to Haiku would allow Haiku user to run another system, such as Windows or Linux, when they need to run an application that is not yet available for Haiku. This would make using Haiku as their primary operating system a viable approach for more people.

Starting from this preliminary work, continue and complete the port. This includes writing a native GUI for VirtualBox, getting it to run, and more importantly, work on the virtualization driver which will allow virtualbox to run the emulated machine using the native CPU. This makes the emulated system run at close-to-native speed, whereas a software emulation would be unbearably slow.

Skill set: userland development, kernel development, possibly x86 assembly
Possible mentors/knowledgeable people: mmu_man

KVM acceleration for Haiku's QEmu port

QEmu is a virtual machine allowing to run an operating system inside of another. While there already is an Haiku port, it currently does not support any acceleration system through native virtualization (KVM/KQemu). This makes it too slow for many uses. Fixing this would allow Haiku user to run another system, such as Windows or Linux, when they need to run an application that is not yet available for Haiku. This would make using Haiku as their primary operating system a viable approach for more people.

Work on the virtualization driver which will allow QEmu to run the emulated machine using the native CPU.
Skill set: kernel development, userland development, possibly x86 assembly
Possible mentors/knowledgeable people: mmu_man
Sourcecode (QEmu for Haku)

Devices preferences/Hardware manager

Haiku is meant to be an easy to use graphical operating system. It should provide a GUI to manage devices and drivers. This is currently implemented in the "Devices" preferences, however it does little more than listing devices found on the machine.

The goal of this project is to extend the functionality of Devices preferences to make it a more complete and useful tool. This includes working on the following features:

Telling wether a driver is loaded for a given device and where the matching /dev entry is
Giving user readable information on the device type and subtype
Allowing to blacklist/disable the driver for a given device
Support for USB and bluetooth devices (currently not listed at all)
Generation of a "compatibility report" to help populate an hardware compatibility database for Haiku

Note that a lot of the work may be in making the required information available from the drivers and existing device management infrastructure, and not just in building the GUI itself.

Skill set: user interface, kernel and drivers interfacing (ioctl, devfs...)
Possible mentors: PulkoMandy
Existing code: "Devices"

Other applications

There are many open source 3rd party applications for Haiku that could use improvements. Whether it is resolving bugs, adding features, updating the coding style, updating them to use the Locale and Layout Kits, or anything else imaginable! Writing applications from scratch is also possible.

Skill set: userland development, user interface design, exploring an existing code base, others depending on the application retained.
Possible mentors/knowledgeable people (depends on chosen application): PulkoMandy, Sean Healy, waddlesplash

Drivers

SDHCI MMC Driver

Haiku doesn't yet support PCI devices with class 8 and subclass 5 according to SD Host Controller Specification

While not very common on x86 machines (SD drives are often wired using an USB controller instead), SDHCI is a lot more common on ARM devices, where currently it is not possible to boot Haiku for lack of a suitable mass storage driver.

See SD Specifications, Part A2, SD Host Controller, Simplified Specification for more information.

This project requires to design a MMC bus manager, plus a bus driver for SDHCI controller and a disk device driver for the MMC bus.

This should be tested either with real hardware or an emulated device in a virtual machine.

Requirements: a SDHCI controller for testing, alternative is sdhci-pci in QEMU.
Skill set: kernel and driver development, general C and C++ development
Specifications for SDHC
Specifications for MMC
QEmu references
Possible mentors: korli

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. This allows reusing network drivers with very little changes, considerably decreasing the effort needed to get good hardware support in Haiku.

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.

This project consists in importing one or more USB network drivers from FreeBSD into Haiku sources. The compatibility layer should then be extended to expose the FreeBSD USB APIs to the drivers, and forwarding the calls to Haiku's USB stack. Other parts of the compatibility layers may need to be extended as well.

This should be tested either with real hardware or an emulated device in a virtual machine.

Requirements: an Ethernet USB device for testing (most smartphones can do this), alternative is usb-net in QEMU.
Skill set: kernel and driver development, USB, general C and C++ development
Possible mentors: korli

NVMe driver

NVMe is a standard protocol for SSD attached to the PCI-express port. Unlike SATA and AHCI, it is designed from the ground up to work with solid state drives (where SATA was first designed for spinning hard disks). This allows NVMe to be an order of magnitude faster and more flexible.

The goal of this project is to implement NVMe support and make Haiku able to boot from such devices, without the need to go into AHCI mode. FreeBSD (or other *BSD) drivers may be used for reference.

Required hardware: computer or virtual machine with NVMe support
Skill set: kernel and driver development, general C and C++ development
Possible mentors: kallisti5, jessicah, PulkoMandy

USB Webcam or soundcard support - isochronous USB transfers

Currently Haiku has very limited support for webcams and USB sound cards. The goal of this task is to improve the WebCam or USB audio drivers, in order to make them production ready. For both of these, the USB specification has a well-documented standardized way to communicate with the devices. Haiku has a working driver for sound cards, and an incomplete one for webcams.

The main area of work for this project would be getting isochronous USB transfers to work in Haiku. The USB specification defines various types of transfers on the USB bus, which affects the scheduling and how the data is exchanged between the computer and USB devices. The isochronous mode is used for low latency applications where a reliable and predictible timing is required (as is the case for video and audio streams).

Unfortunately, Haiku implements these transfers completely only for some USB1 controllers. There is partial support, but it is not fully working.

The first part of this task is to investigate the state of isochronous transfers and what is missing to get them working. Then, of course, actually making things work. Once this part is sorted out, the audio and webcam drivers may also need some work to get everything running smoothly.

Requirements: USB audio or webcam device (a laptop with built-in webcam should do)
Skill set: kernel and driver development, USB, C and C++ development
Possible mentors: PulkoMandy

virtio balloon memory driver

virtio ("virtual input and output") is a technology used in virtual machines to reduce overhead of emulation. Instead of simulating an existing device, virtual machines expose a simplified "virtio" device, which is designed to make interfacing between the guest and host system easier. The technology is currently applied to disks, memory, and network.

The virtio memory driver allows to implement "ballooning", that is, the virtual machine can increase or decrease its memory use (just like a balloon is inflated or deflated) when the guest system allocates or releases memory. This makes it easier to share the memory between several virtual machines more efficiently.

Haiku already has a virtio bus driver, and virtio disk and network drivers. The addition of 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 balloon memory driver would need to be completed and tested.

Requirements: qemu or virtualbox, or other VM implementing balloon memory.
Skill set: kernel and driver development, general C development.
Tickets: #9800 virtio network driver, #9803 virtio balloon memory driver
Existing code: virtio network driver, virtio bus driver (should be mostly complete), virtio block (functional, example usage of virtio bus)
Possible mentors/knowledgeable people: Jerome Duval

3D acceleration support

Haiku does not currently support hardware acceleration of 3D rendering. Using the Gallium infrastructure from Mesa, the goal of this project is to make the existing Mesa renderer allow hardware-accelerated 3D rendering, and not just software.

Haiku video drivers are split in two parts: the driver itself, which is quite minimal and only provides low level access to the video card, and the "accelerant", which runs inside app_server and communicates with the driver in order to configure the card and use its features.

The interface between the driver and accelerant is inherited from BeOS and designed mostly for 2D acceleration (blits, scrolls, hardware cursor, etc). As part of this task, the communication channel should be extended to allow for 3D acceleration as well. It is likely that the best solution is something similar to the DRI/DRM model used on Linux and adopted by most *BSD. This would allow reusing Gallium3D, which is part of the Mesa OpenGL stack, and only work on the low level side of things (as Gallium already knows how to handle DRI/DRM like drivers).

Skill set: kernel and driver development, Mesa graphics stack
Possible mentors/knowledgeable people: PulkoMandy

Kernel

Improving the btrfs filesystem

Haiku has great support for its own file system, but most others are only available read-only. It is way better for interoperability with other systems to be able to write to these disks from Haiku.

The goal of this project is to complete the btrfs filesystem, to allow it to write btrfs volumes (reading works already). During GSoC 2016, a student already got as far as creating directories, but it is not possible yet to write files. The first part of the work is to review the existing code, and report on the current status and the work needed to get everything in place.

After completion of this project, it should be possible to read and write files to btrfs volumes, making sure they are interoperable with Linux (mount without errors, file data is accessible, fsck detects no problems). Stress-testing should also be performed using bonnie++, and other test suites may also be used.

Skill set: kernel, and driver development
Possible mentors/knowledgeable people: PulkoMandy, Sean Healy
Sourcecode
GSoC 2017 log

File Systems: general improvements and new filesystems.

Haiku has great support for its own file system, but is completely missing support for some other fielsystems. It is way better for interoperability with other systems to be able to read and write to these disks.

The goal of this project is to port one of the following filesystems to Haiku:

ext4: extend the existing ext2 driver to support new ext3 and ext4 features
UFS2 (as used in *BSD): FreeBSD implementation, u2fstools for windows (BSD licensed, source can be reused)
HAMMER FS: homepage, sourcecode (3-clause BSD, a port of the existing code is ok)
JFS: existing code in Linux is under the GPL, a rewrite under the MIT license is preferred. The filesystem design and disk structures are well documented.
XFS: Development community, homepage (existing code in Linux is under the GPL, a rewrite under the MIT license is preferred)
ZFS: main page, existing code (Existing code is under the CDDL, a rewrite is preferred)
SMB, Windows shares: smbfs from FreeBSD (2-clause BSD, code can be ported to Haiku)

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
Possible mentors/knowledgeable people: PulkoMandy

x86-64: Support for 32 bit userland

Haiku is currently available in both 32 and 64 bit versions. However, the 64-bit version is currently unable to run 32-bit applications, forcing application developers to provide a 64-bit version of their applications. This is reducing the adoption of 64bit versions of Haiku for lack of available applications.

The goal of this task is to add a compatibility mode to the 64-bit kernel so it is able to run 32-bit programs. The issues in doing that involve adjusting syscall parameters, and mainly converting pointers from the 32bit userland to the 64-bit addressing used on the kernel side. 32-bit applications compiled for Haiku "x86" architecture should be supported. Handling of gcc2-compiled legacy BeOS applications may also be considered as an extended goal, but not as much important.

Skill set: kernel development, x86 architecture/assembly language
Possible mentors/knowledgeable people: Jerome Duval

x86-64: Implement support for Process Context Identifiers (PCID)

on Intel CPUs. The feature tags TLB entries with the Id of the address space and allows to avoid TLB invalidation on the context switch, it is available only on x86-64.

The goal of this task is to propose possible designs, implement the feature, extend the performance logs to measure impacts when the feature is enabled.

Skill set: kernel development, x86 architecture/assembly language
Possible mentors/knowledgeable people: Jerome Duval

ARM port / device tree support

Unlike x86 systems which have a PCI bus, most ARM devices have peripherals at hardcoded addresses. This means automatic hardware discovery is not possible. The Linux kernel developers designed a solution called "flattened device tree". It is a static description of the hardware, telling the kernel where devices are located and which driver to use.

Haiku plans to use device trees to support several ARM devices with the same kernel. This requires updating our drivers and driver infrastructure to not rely so much on the PCI bus. This work should start with the USB EHCI driver, in order to provide at least one mass storage solution to the ARM port of Haiku.

The ARM port of Haiku is currently in an early state. This project may involve debugging of other issues in the port to get it running further, so the device tree part can be tested. Several parts of the early boot code should be reviewed to make use of the device tree and remove hardcoded addresses (RAM mapping, framebuffer, serial port, etc).

Skill set: kernel development, ARM architecture/assembly
Possible mentors/knowledgeable people: PulkoMandy

Network

Bluetooth Stack Improvements

Haiku Bluetooth Stack implements only basic functionality on lower and middle layers. This functionality needs to be completed and Bluetooth 2.X and later possibilities explored. This task involves investigating the current state of the Bluetooth code, checking that the basic functionality is still working (pairing devices, etc), and improving the stack to make it more useful by implementing driver(s) for Bluetooth device(s) of your choice (file transfers, audio, HID, networking, etc).

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.
Possible mentors/knowledgeable people: waddlesplash (userspace stuff)

IPv6 Finalization

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/finalization 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)
- #11862 -- Net server multi-protocol rework

Skill set: IPv4 and IPv6 protocols, kernel and network stack development
Possible mentors: jua

User Interface

Preferences GUI refactoring

Haiku is an operating system designed for ease of use on desktop computers. A key part of this work is an easy to use set of preference applications. Some of the currently available preference panels could be merged or improved in several ways.

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):

combining Keymap, Keyboard, Mouse and Touchpad in a single "Input devices" preferences panel,
adding support for joysticks and touch screens support to it,
#6983Reworking the Printer preferences to look better and be more intuitive.
#6206integrate scrollbar options into a new Appearance preflet, and provide a live preview for all of the settings available in this window
Improving the user interface of the shortcuts preference to make it easier to setup custom shortcuts
Improving and extending the notifications preferences to allow easy control of allowed notifications, browsing of the notification history.
Research on how to improve the other preference panels further with the goal of making them easier to use.

Skill set: C++, UI development, usability basics
Possible mentors/knowledgeable people: PulkoMandy, waddlesplash

Modular edit view (BIG)

The current solution for text editing in Haiku is the BTextView. It is a rather simple view providing basic text editing features and limited styling. This is, however, not powerful enough for most serious uses. The goal of this project is to design a complete replacement for BTexView, which should be designed to cover more use cases.

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

spell checker
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
Including pictures in the text flow
Sourcecode editor: syntax highlighting, code completion
Ability to load and save data in different formats (using the Translation Kit)

Existing work

The HaikuDepot application includes preliminary work on a rich text view, which it uses to provide the description of packages. This could be used as a starting point for this work.

Skill set: C++, API design, UI development
Possible mentors: scottmc, Sean Healy

Media

Add subtitle support to the Media Kit

Haiku "media" applications rely on a framework called the Media Kit. This provides an unified API to handle audio and video streams, including codec plugins to read and write the stream to files or other sources, as well as transporting the data from one application to another, with a latency as low as possible.

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.

implement the required code to extract the subtitles from source files (either standalone .srt files or contained for example in mkv containers), with proper handling of replay time and text encoding
integrate this in the existing API (probably as a new kind of BMediaTrack), and update applications such as MediaPlayer and MediaConverter to make use of the feature.
See the BeBook introduction for the Media Kit to become familiar with its design.
Skill set: general C/C++, userland development, API design
Possible mentors: Barrett, jua, PulkoMandy

Complete and Finalize the MediaPlayer Plugin API

The MediaPlayer app included in Haiku is able to play most of the media formats around. To be able to do that it includes a monolithic framework that uses most of the important features of the media_kit. To improve maintainability and flexibility we are looking forward to include a plugin API and export or implement as plugins certain functionalities.

Some examples :

Playlist
Attributes editor
Cover Art
Web Remote Control

Some efforts have been already put and can be found here.

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
Possible mentors: jua

Other

Coding style check tool

Haiku has its own coding guidelines which describe how the code should be formatted. There is currently no reliable tool available to check if these are applied properly.

The goal of this project is to develop such a tool. It should properly parse C++ (so basing your work on an existing tool such as WebKit's checkstyle or clang-format would be a good idea), and provide either an human readable report, or a review on Gerrit. Automating coding style review would allow for faster feedback on that aspect when an user submits a patch, and allow developer's review to focus on functional aspects.

Skill set: Gerrit, code formatting tools
Possible mentors: PulkoMandy

Add Haiku support to Allegro 5.0

Allegro is a gaming library. Older version (4.4) did support Haiku, but this support was dropped from the newer versions (starting from 5.0). The library should be ported to Haiku, allowing to run the bundled examples and possibly port some other software using it.

Skill set: C++, userland development
Possible mentors: scottmc
Alternative projects: porting SFML or another similar library

Tracker add-on for a version control system

Git is now a very popular version control system. In Haiku, most interactions with it are through the command line. This makes it a bit hard to use for some people.

The goal of this task is to integrate Git support into Tracker, which is the file browsing application in Haiku. The result should be similar in behavior to what TortoiseGit achieves on Windows: right click menu to perform various actions, overlay on file icons to show the file status, etc.

This should be implemented as an add-on to Tracker, which can be installed separately. However, it is quite likely that Tracker itself will also need some changes to support the required extensibility: add-ons provided menus, icon overlays, and other features are currently not available.

Prior art: MoleSvn - Tracker add-on for Subversion
Skill set: userland development, UI design, git
Possible mentors: Sean Healy, waddlesplash
Possible alternative ideas/extensions: do the same for another version control system

Multiple monitors output in app_server

app_server is Haiku's graphics server and the equivalent of X11 or Wayland on other UNIX systems. It currently supports only one video output, but should be able to do more.

While the API already allows this for the most part (with the BScreen class), there is no actual implementation behind it and parts of the code assume only a single screen.

Some drivers implement minimal support for multiple displays, but not all of them. This task may involve updating the video drivers to handle multiple monitors correctly.

Skill set: C++, graphics development
Possible mentors/knowledgeable people: jua, PulkoMandy

Complex font rendering in app_server

app_server is the graphics server in Haiku. It handles the rendering and display of application windows, desktop, and everything that is shown on screen.

Freetype (in combination with agg) is used to render text. While it provides good results on its own for latin and cyrillic alphabets, Freetype is not enough on its own to properly render other scripts with more complex rules, such as Devanagari or Arabic.

The goal of this task is to integrate Harfbuzz into app_server, so that the complex rules for text rendering are properly applied. This would allow rendering of complex languages as mentioned above, as well as mixing different languages (picking appropriate fonts automatically).

This task can be further extended with investigations of API changes required in the interface kit (and in particular BView and BFont) to properly handle left to right text.

Skill set: C++
Possible mentors: stippi, PulkoMandy