1. Home
  2. Community
  3. Google Summer of Code
  4. GSoC 2016
  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 14th and March 25th, 2016. 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 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 coding period starts) 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.

Project Areas

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:

  • Missing session management. Opened tabs should be remembered and restored when the program is exited and restarted.
  • Missing Cookie Jar management. There should be a way to list, delete and edit network cookies.
  • Missing 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

Extending and improving the Services Kit network backend

The WebKit browser and some other Haiku applications such as HaikuDepot use the Services Kit as a network backend. This is a library similar to curl or soup, but nicely integrated into the Haiku API for easy use in native applications. The Services Kit is still a work in progress, however, and can be improved in several ways. The work on this task could include:

  • 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

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.
  • Even when it looks correct, the rendering in WebKit is usually quite slow. Causes for this are present both in the WebKit code and in Haiku's app_server, which takes care of the drawing. Review the code to identify performance problems, and rework it to make the browser feel faster.
  • Skill set: userland development, exploring a large code-base (WebCore)
  • Possible mentors/knowledgeable people: PulkoMandy

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

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

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/)
  • https://github.com/HaikuArchives/A-Book
  • Skill set: userland development, user interface design, possibly network development.

Updating Mail

Haiku provides an innovative Mail management system using the file system database-like features (queries) to efficiently manage the e-mails. While the technology for this is working well, the user interface is rather limited, making it difficult to use the feature up to its full potential.

The first part of this task is reworking the code base to adhere to our coding style guidelines and convert the user interface to the Layout Kit, making it work with all font sizes and languages. The code should be improved to use proper object oriented programming concepts, and reviewed for potential thread-safety issues.

The second part of this task is to improve the user interface 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 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.

  • Caya (IM client)
  • Torrentor!
  • https://github.com/HaikuArchives
  • http://pulkomandy.tk/projects
  • http://pulkomandy.tk/~beosarchive/
  • 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

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. 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).
  • Skill set: kernel and driver development, USB, general C and C++ development

USB stack improvements (USB3, isochronous transfers)

Like any other operating system, Haiku has drivers for all types of USB interfaces: OHCI and EHCI for USB1, UHCI for USB2, and XHCI for USB3. However, most of these still need some improvements to improve compatibility and add full support of the USB specification.

The XHCI support is still not complete. On several machines it will not detect devices, generate a lot of hardware interrupts, or even prevent the whole system from booting. Work on XHCI support must be continued so Haiku gets more reliable and complete support for USB3.

USB allows 3 different ways of exchanging data with a device: bulk, interrupt, and isochronous. In bulk mode, the data is transferred when the bus is idle. Interrupt mode has higher priority. Finally, isochronous mode guarantees a minimal rate. This last mode is used for example by USB audio cards and webcams, as they need a constant flow of data at a fixed rate. The UHCI and EHCI drivers are missing support for isochronous USB transfers. This makes it impossible to use most USB sound cards and webcams in Haiku.

The USB tasks consist in implementing either complete USB3 support, or isochronous transfers for USB1 and USB2 devices. This can be complemented with porting a webcam or audio card driver from FreeBSD or Linux (FreeBSD is preferred because of the software license used, we prefer to avoid GPL code if possible).

  • Requirements: an USB webcam or audio device for testing (most laptops have an embedded webcam using USB).
  • Skill set: kernel and driver development, USB, general C and C++ development

virtio network and balloon drivers

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 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 Extensions (_DOS _DOD and so on)
  • Skill set: kernel development, general C/C++, userland development

SD Host Controller support

Haiku has currently no support for SD Host Controller.

Implementing a stack with support for SDHC PCI devices would be a good start. Specifications for SDHC Specifications for MMC

To develop and test, QEmu (from 2.3) provides an emulation for SDHC on PCI: -device sdhci-pci -sd my-test-drive

QEmu references

This would involve designing and developing a SDHC PCI bus driver, a MMC bus module and a MMC SD disk driver.

  • Skill set: kernel and driver development, general C and C++ development

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 display 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 a Haiku graphic driver, allowing at least setting the native video mode. Hardware 3D acceleration may also be investigated, but requires more work on Haiku (see the next project idea).

  • Skill set: kernel, and driver development

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 3D rendering and not just software. This involves extending the API used by our video drivers (which is currently 2D oriented only), and making Gallium uses that API. Parts of the DRI/DRM model used on Linux may be reusable, but cooperation with the app_server must be possible.

  • Skill set: kernel, and driver development
  • Possible mentors/knowledgeable people: PulkoMandy

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 extensions or alternative GSoC's
  • Application/driver to handle boot options and install a 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://web.archive.org/web/20150929095441/http://wiki.phoenix.com/wiki/index.php/Category:UEFI_2.1
  • Skill set: kernel development, x86/x86-64 architecture/assembly, bootloaders, QEMU

Power Management

Haiku already has some power management support in the form of a CPU idling driver. This is however clearly not sufficient, and there is room for improvements in several areas in order to make Haiku use less power and make laptops running Haiku last longer on battery.

Some investigation is required to identify the main issues in Haiku leading to suboptimal performance. There are however a few already known problems:

  • Some subsystems such as the network and wireless stack wake up the system at regular intervals (10 or 100 times per second) to perform some tasks. Whenever possible they should be modified to trigger these tasks in anevent-driven way (triggering them from hardware interrupts for example).
  • Some applications (such as the always-running DeskBar) are polling for events in a similar way. The APIs should be adjusted where possible to make those applications wait on notifications instead.
  • None of the device drivers in Haiku include powersaving modes. When a device is idle, it should be put to sleep and powered off until it is needed again.
  • Skill set: kernel development, general C/C++, userland development, debugging, power management / measurement

Add write support for more filesystems (BIG)

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 existing support for one of the following filesystems in Haiku, working from the existing code base:

  1. ReiserFS existing sources, official specifications, extra documentation on the FS layout
  2. BTRFS: existing code, homepage

A good warm-up task would be to get one of these filesystem to build and run in "userlandfs" mode, as this allows much easier development and testing during the project.

  • Skill set: kernel, and driver development
  • Possible mentors/knowledgeable people: PulkoMandy

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:

  1. ext4: extend the existing ext2 driver to support new ext3 and ext4 features
  2. UFS2 (as used in *BSD): FreeBSD implementation, u2fstools for windows (BSD licensed, source can be reused)
  3. HAMMER FS: homepage, sourcecode (3-clause BSD, a port of the existing code is ok)
  4. 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.
  5. XFS: Development community, homepage (existing code in Linux is under the GPL, a rewrite under the MIT license is preferred)
  6. ZFS: main page, existing code (Existing code is under the CDDL, a rewrite is preferred)
  7. 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

IMAP FS: File system access to an IMAP account

In Haiku emails are stored as individual file with extended attributes. The IMAP protocol exposes mails in a folder hierarchy and makes it possible to "browse" a remote mail box. 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. The design of netfs and nfs4 implementations for Haiku, as well as the simpler googlefs can serve as a reference on how to implement a network file system.

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

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

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

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 caches data at the "file" level, while the block cache is used at the "block" level and is used for on-disk structures as well as file data.

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.

The first problem with the current implementation is caching imbalance in favor of the block cache: it tends grow more than needed and prevent the file cache to get enough memory.

Another problem is the use of large amounts of kernel address space by the block cache, which can be problematic on 32 bit architectures. This makes the block cache constrained to the 2GB of memory available for the kernel in Haiku, and sometimes makes the kernel run out of address space for other uses.

The goal of this project is to create a common underlying mechanism (using `VMCache`) to unify both caches and move the block cache out of the kernel address space. The following problems need to be investigated and solved:

  • How to deal with heterogenous block sizes (not necessarily matching the page size): each mounted filesystem volume may have a different block size, and the block cache must be able to efficiently cache blocks of these different sizes,
  • How to map support for transactions to `VMCache` hierarchies,
  • Balancing of the memory allocation between the block and the file cache and between multiple mounted filesystem volumes.

  • Skill set: kernel development

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 drivers for a Bluetooth device of your choice (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.

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

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. Some examples are:

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, Keyboard, Mouse and Touchpad in a single "Input devices" preferences panel,
  2. adding support for joysticks and touch screens support to it,
  3. #6983Reworking the Printer preferences to look better and be more intuitive.
  4. #6206integrate scrollbar options into a new Appearance preflet, and provide a live preview for all of the settings available in this window
  5. Improving the user interface of the shortcuts preference to make it easier to setup custom shortcuts
  6. Improving and extending the notifications preferences to allow easy control of allowed notifications, browsing of the notification history.
  7. 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

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. Scintilla is a good candidate and was already ported to Haiku.

  • Skill set: C++, UI development

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

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

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.

Currently, the codec part of the Media Kit and applications using it relies on media sources being seekable. While this is easy to do when the source is a file, it is much more difficult to use the Media Kit with a streaming source such as a network stream. Use of DVD media can also be a problem, as seeking is a slow operation and can easily lead to dropped frames or otherwise broken replay.

The media kit decoding framework should be improved to handle non-seekable sources properly. This work includes rewriting some code to not rely on seeking, or at least handle failures to do so properly. In places where seeking is really needed, a way to provide a seekable buffer over a non-seekable source should be designed and used.

  • Skill set: general C/C++, userland development
  • Possible mentors/knowledgeable people: PulkoMandy

Possible extension to this project: better support for DVD playback in the Media Kit, including menus, decss decoding, etc.

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

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

RTL languages support in interface kit

The interface kit is the part of the API taking care of everything drawing related: windows, buttons, and other widgets. It is not currently able to display right-to-left languages (such as arabic) properly, making Haiku unusable for a lot of people.

Font rendering should be reworked to use the HarfBuzz library, instead of just Freetype, providing support for ligatures and bidirectional text output. The Layout Kit (which handles positionning widgets in a window) should be made to work as expected with these languages (possibly inverting left and right in the window layout).

This task can be extended with better support for font overlays (picking the correct font for each language automatically, probably using fontconfig), and work on input methods for some languages.

  • Skill set: C++, graphics development, text rendering
  • Possible mentors/knowledgeable people: PulkoMandy

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

Menu