The intention of this page is to classify features and their place with respect to R1. Once every feature is classified, the releases up to and including R1 can then be scheduled. This schedule will help to serve as inspiration to contribute to features that are required for a particular release.

Procedure

1. Define the R1 feature set. Features should be organized in three groups:
   • must-have features
   • nice-to-have features (which shouldn't hold off the release)
   • definitely-post-R1 features

2. Define a rough estimation/schedule for the implementation of the missing

features.

3. Create the R1 roadmap. This includes all releases we want to do until R1, tagged with preliminary release dates.

Features

Locale

Reasons For

1. more polished impression
2. despite a non-public API, it has stirred many contributions and is important even in its current state

Reasons Against

1. need to update bundled third party applications
2. locale API not ready to be public
3. layout API not ready to be public
4. including it in Pre-R1 & not in R1 Final, may cause false hopes

SubTasks

1. Make Layout API public
   • Master ticket: #5524
   • make it FragileBaseClass safe #5526
   • integration with the archiving feature in general #5525
   • testing the archiving feature in general
2. Preflet needs work
3. update applications to use Layout API
   • Mail - partially (settings)
   • Media - partially
   • Terminal - partially
   • E-mail - calculating dynamic sizes
   • FileTypes - calculating dynamic sizes
   • TextSearch - calculating dynamic sizes
   • DiskProbe - calculating dynamic sizes
   • DataTranslations
   • Tracker
   • TV
   • ShowImage
   • SoundRecorder
   • People
   • Poorman
   • MediaConverter
   • Magnify
   • DiskUsage
   • Cortex
   • CDPlayer
   • Bootman
   • Tracker
   • Time
   • ScreenSaver
   • Shortcuts
   • Printers
4. update applications to use Locale API
   • #4619
   • Fill in details.
5. update 3rd party applications bundled with Haiku
   • Vision
   • WebPositive
   • BePDF
   • ClockWerk
   • Pe
   • WonderBrush

Wifi

Reasons For

1. even without encryption, it improves Haiku's appeal & usability
2. marketing appeal

Reasons Against

1. including it in Pre-R1 & not in R1 Final, may cause false hopes
2. currently has irq sharing issues that may prevent a successful boot & cause a negative 1st impression.

SubTasks

1. IRQ sharing issues
2. userland utilities (network preflet integration, some form of notification in deskbar)
3. proper cli integration with ifconfig
4. WEP encryption
5. WPA/WPA2 encryption
   • Porting wpa_supplicant, would be the quickest way to get WPA/WPA2 support working, presumably as an extension to the net_server, just like dhcp is.

WebPositive

Reasons For

1. BeZillaBrowser/Bon Echo/FireFox 2.x is outdated and is a constant blemish
2. In ways, it is more advanced than BeZillaBrowser

Reasons Against

1. Missing functionality that users expect in a browser

SubTasks

1. WebKit as optional build feature
2. Integrate WebPositive in repository
   • for next alpha, perhaps just an OptionalPackage?

ACPI

1. wide spread testing
2. ​http://dev.haiku-os.org/ticket/5064

Package manager

SubTasks

1. UnionFS needs to be implemented, such that one can edit a file that has been inserted by a package (like config files).
2. thorough testing required
3. test packages need to be created

IRQ Routing

Fill in details.

Debugger

1. not quite ready for public consumption yet.

Jamfile Engine

Fill in details.

Media Kit Encoding Support

1. Implement BEncoder API
2. Adding support for more codecs
3. Updating the port of Xiph would need to be done as well

Network Preflet Rewrite

Fill in details.

Device Manager

Fill in details.

bootman improvements

1. support multiple drives
   • hrev25044
   • #2477
   • #3545
   • #4503
2. user selectable destination drive (eg, install to usb stick) #3443
3. writembr #5595

TTY Layer

1. Rework our current TTY layer into a module
2. Create an API that fulfills the need of a serial port
   • traditional RS232
   • serial over USB.
3. Integrate the new API into the serial drivers that are already in our repository,
4. Make sure everything works as expected.
5. Until now the serial port was reserved for kernel debugging, but it is now time for proper userland support.

Reasons For

1. Would allow Haiku to be debugged by another installation of Haiku

Reasons Against

1. More frequently, new hardware is missing serial header

OSS Improvements

1. Prevent driver collision

Stack and Tile

Reasons Against

1. Requires much code refactoring before merging into trunk

Session Management

Fill in details.

Content Based Search

Fill in details.

​Unscheduled

1. Hardware 3D acceleration
   • 3D accelerated app_server
2. Tracker rewrite/refactoring
   • separate view mode code
   • add more view modes
3. Multi-user support
4. 64 bit support
5. Keyboard shortcut and gestures management (Spicy Keys has been integrated as "Shortcuts", needs improvements.)
6. Keyboard and Mouse settings associated with hardware
7. Multi-head support in app_server
8. Concurrent user support in input and app_server
9. Remote app_server (has been implemented, but could use more user-friendly integration)
10. New file system - FutureHaikuFileSystem
11. More POSIX compatibility
12. Replacing the C library
    • #1907
    • ​haiku-development:PATCH-libroot-improvements
13. Power management
14. I/O APICs (implemented, but the interrupt mapping for PCI interrupts that has to be read through ACPI is yet missing)
15. Finalize new driver architecture and rewrite all drivers
16. IPv6 network support
17. Floppy drive support
18. Media Acceleration library (common routines to be used by media plugins that can be replaced by OpenCL, SSE or the like)
19. API changes after dropping BeOS backwards compatibility - ​APIChangesOnCompatibilityDrop
20. Calendar / Scheduling application (and server?)
21. Gamepad/joystick support ​ML thread

Random Questions

1. What is needed to make the Locale API public?
2. What needs to be improved for the Locale Preflet?
3. What currently happens when you archive a BView hierarchy that is layout managed, and unarchive it again?