wiki:GoogleSummerOfCodeIdeas

Version 23 (modified by pulkomandy, 14 years ago) ( diff )

--

Google Summer of Code Ideas for Haiku

Work In Progress: 2010

Limitations:

  • Should be peripheral projects that will not affect any time lines for the project.
  • Published ideas need at least one person willing to be mentor.
  • Maybe we can mention which ideas require a mentor to be found ?

Notes:

  • Make sure every idea has a detailed explanation
  • Create a list of small tasks -- or at least guidelines as the type of tasks that can be piggy-backed on another project
  • Provide links to or at least mention:
    • relevant parts of the source tree
    • relevant chapters in BeBook
  • existing bug tickets
  • persons who can discuss the topic -- this is primarily for the admins, to help redirect inquiries.
    • eg. NickName is currently on IRC or AnotherNickName reads the mailing lists.

Actual Ideas

This is a list of ideas that are planned for inclusion in Haiku R2.

  • 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. Rewrite the API that was available in BeOS R5, and make sure it can be used with a real serial port. USB to serial converter may or may not be included.

  • Remote app_server -- user-friendly integration

The remote app_server allows you to connect to another computer in a graphical shell and run distant applications. It is working fine, but needs a nice graphical window to launch it. For now it needs a command line. Note : this is probably too easy for a GSoC project, unless I'm missing something ?

  • Updating & Utilizing RamFS
    • detect available memory at boot.
    • create drives based on some rules
    • /tmp should be mounted as ramfs -- for both RW & RO medium
    • maybe a Preflet to control settings
    • create a true live cd experience.
      • keep settings on ramfs.
      • write to a secondary disk at shutdown or at 'sync'
      • read imagefile from disk to ramfs at boot

The RamFS allows to use part of your memory as if it was a disk volume. This can be used to store temporary file, but is also really interesting when runnning in livecd mode. As the CD cannot be written, you have to use a RamFS volume to store all of your data while running the system. When you power your computer off, you can dump this RamFS either to an usb disk or a plain file on some partition on your hard drive, so you can load it back next time you boot your haiku livecd.

  • Filesystems: general improvements
    • EXT, ReiserFS: write support
    • UFS2: Read (& Write) support
    • ZFS: Read (& Write) support
    • Note: Utilizing FUSE is possible, but a single FUSE project tends to be small.

Haiku has great support for its own filesystem, 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.

  • Non-x86 Ports:
    • ARM
    • PowerPC
    • x86_64

As of now, Haiku runs only on x86-pc machines. The PowerPC and ARM ports are there, but they are far from finished. The x86_64 port is not even started. All of them will likely help haiku get mainstream : ARM and 64bit systems are likely to become more and more common. Most of the work is kernel-related, and is about getting Haiku to boot. Once the kernel is OK, most apps should go fine. PowerPC may have some endianness problems, and 64bit may mess up pointer arithmetics.

  • Improving POSIX support

Haiku is not UNIX, but it has a compatibility layer allowing POSIX applications to compile and run without changes. This layer is already far more complete than the one in BeOS R5 was, but it's still lacking some stuff here and there. Tasks include testing the support by running some known/standard test suite, reporting the status and fill in the missing blocks.

  • Updating applications to use layout manager.
    • #4619 has some examples in the Skipped section

The Layout Manager is an API introduced in Haiku. It allows windows to be layouted automatically and adapt to the font size settings. It also greatly helps localizing applications. Unfortunately, some apps are still not using it and behave quite badly. Update them.

  • Locale related: (PulkoMandy as likely mentor)
    • Formatting stuff (number, dates, ...)
    • Handling polish plurals (as pointed out by aljen)
    • font overlay and right-to-left languages support

The Locale Kit is a new API in Haiku, allowing to translate an application automatically at runtime. It is still quite young and incomplete. ICU is used as a backend, but the API should provide support for binary compatibility, and have a tight integration in the rest of the original Be API used in Haiku. Task is plugging ICU backends to the already existing stubs, studying localized applications to see where they have problems the locale kit should solve and designing the appropriate API.

  • Fix and improve Haiku's mail system (which ​tickets exactly has yet to be decided).
  • full NFSv4 client with xattr support and caching
  • Utilizing aspects of 3rd party software
    • Creating Text Translators from OpenOffice
  • Native GUI for:
    • Transmission
    • VLC
  • Hardware profiling tool
    • an application for creating a hardware database.
  • Language bindings in SWIG
    • python
    • perl
    • ...
  • Maybe something involving HaikuPorts?
    • improving HaikuPorter to work more like FreeBSD's ports -- python programming
  • Jam build system enhancements.
    • like what...? generic wrapper for autotools, makefiles. This would help integrate existing projects into Haiku's source tree or 3rdparty folder
  • Enhancements for Virtualization Software
  • Universal Spell Checker, built upon the WordServices SDK. note: see ​Spill Chucker
  • IPv6 Mentor Needed!
  • CUPS
  • Gallium3d

2009

See official page here: ​http://www.haiku-os.org/community/gsoc2009/ideas

Note: See TracWiki for help on using the wiki.