Changes between Version 26 and Version 27 of GoogleSummerOfCodeIdeas

Mar 8, 2010, 9:50:29 PM (10 years ago)

finished migrating to drupal. nag me to add more ideas there.


  • GoogleSummerOfCodeIdeas

    v26 v27  
    1 '''This page is now being migrated to Drupal.'''
    3 ----
     2The contents of this page have been migrated to our [ Google Summer of Code] section on our [ Drupal Website].  Feel free to look at this [ page's history] for additional ideas.
    5 ----
    7 = Google Summer of Code Ideas for Haiku =
    9 == Work In Progress: 2010 ==
    11 Limitations:
    12  * Should be peripheral projects that will not affect any time lines for the project.
    13  * Published ideas need at least one person willing to be mentor.
    14  * Maybe we can mention which ideas require a mentor to be found ?
    16 Notes:
    17  * Make sure every idea has a detailed explanation
    18  * Create a list of small tasks -- or at least guidelines as the type of tasks that can be piggy-backed on another project
    19  * Provide links to or at least mention:
    20         * relevant parts of the source tree
    21         * relevant chapters in BeBook
    22         * existing bug tickets
    23         * persons who can discuss the topic -- this is primarily for the admins, to help redirect inquiries. 
    24                 * eg. NickName is currently on IRC or AnotherNickName reads the mailing lists.
    26 === Actual Ideas ===
    27         * Non R1 tasks:
    29 This is a list of ideas that are planned for inclusion in Haiku R2.
    31         * TTY Layer
    33 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.
    35         * Remote app_server -- user-friendly integration
    37 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 ?
    39         * Updating & Utilizing RamFS
    40                 * detect available memory at boot.
    41                 * create drives based on some rules
    42                 * /tmp should be mounted as ramfs -- for both RW & RO medium
    43                 * maybe a Preflet to control settings
    44                 * create a true live cd experience.
    45                         * keep settings on ramfs.
    46                         * write to a secondary disk at shutdown or at 'sync'
    47                         * read imagefile from disk to ramfs at boot
    49 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.
    51         * Filesystems: general improvements
    52                 * EXT, ReiserFS: write support
    53                 * UFS2: Read (& Write) support
    54                 * ZFS: Read (& Write) support
    55                 * Note: Utilizing FUSE is possible, but a single FUSE project tends to be small.
    57 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.
    59         * Non-x86 Ports:
    60                 * ARM
    61                 * PowerPC
    62                 * x86_64
    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.
    66         * Improving POSIX support
    68 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.
    70         * Updating applications to use layout manager.
    71                 * #4619 has some examples in the '''Skipped''' section
    73 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.
    75         * Locale related: (PulkoMandy as likely mentor)
    76                 * Formatting stuff (number, dates, ...)
    77                 * Handling polish plurals (as pointed out by aljen)
    78                 * font overlay and right-to-left languages support
    80 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.
    82         * Fix and improve Haiku's mail system (which [ tickets] exactly has yet to be decided).
    84 Haiku features an integrated mail management system allowing to manage your mail using Tracker, the file explorer. This system needs some improvements and updates.
    86         * 3rd Party Applications
    87                 * [ IM Kit]
    88                 * [ Caya] -- Planned to eventually replace IM Kit
    90 Caya and IMKit are to IM what the Mail Daemon is to mail : they integrate your IM contacts into the system. IM Kit is an application from the BeOS era, but was still alive until not so long ago. Caya is a rewrite from scratch, to build a cleaner codebase. Both of them may need your help to get better protocol supports (Caya only does jabber as of now), or to get better features (voice & video may be an example).
    92                 * [ Services Kit]
    93                         * [ Summary]
    94                         * [ Mailing List thread]
    95                         * [ May contain additional threads]
    97 The Service Kit is a planned feature in Haiku, nothing is written yet besides some design ideas. It would make most web-2.0 sites and social networks available right on your desktop, with seamless desktop integration. Using RSS feeds and other public APIs, it would download things from the web and expose them in an easy to use interface with a native feeling, integrated in the system and not locked into a webpage.
    99                 * WebKit based browser
    101 Haiku has a webkit port since GSoC 2009. There is a browser being written, but it still lacks some features. Improve it. (not easy to describe more in detail since the browser is evolving quite fast)
    103                 * OpenJDK
    105 Haiku is not able to run Java. Port OpenJDK so this language can be used in Haiku, to run applets and other apps. [ OpenJDK: Port: Haiku]
    107         * full NFSv4 client with xattr support and caching
    109 Haiku has an NSF client, but using the out of date NFSv2 specification and the old filesystem API. This makes it unuseable for any practical purpose. Also, the current implementation doesn't support caching, which makes it slow, and lacks xattr handling, which is very important in Haiku.
    111         * Utilizing aspects of 3rd party software
    112                 * Creating Text Translators from OpenOffice
    114 Translators allows apps to automatically open documents in any format. The documents format are quite common and well documented, so Haiku apps should be able to read them. Write a translator so this becomes possible.
    116         * Integrating software into Haiku
    117                 1. updating to use a jam build system
    118                 1. complying with Haiku's Coding Guidelines
    119                 1. layout manager
    120                 1. HVIF icons
    121                 1. Locale API
    122                 1. possibly becoming an actual part of Haiku's source tree and not a 3rd party addition
    123                 * [ InfoPopper] -- as an actual notification_sever
    124                         * [ Big discussion in May 2007]
    125                         * [ And some more in April 2008]
    126                         * [,18 Year++ with plan for integration]
    127                 * [ PecoRename] or [ ReName!]
    128                 * [ Colors!]
    129                 * [ ClipUp]
    130                 * [ CD/DVD burning application] Maybe update Burnit Now
    132 Haiku is a brand new system, but sometimes it is wiser to reuse an existing codebase than growing our own. This is a list of applications that may be integrated in Haiku releases, because they are needed for everyday basic tasks. Some of them were not updated for a long time and expect to run on a BeOS R5 system. Some others may be written in a coding style very different from ours. Update one (or more) of these and get it nicely integrated in Haiku source tree.
    134         * Native GUI for:
    135                 * Transmission
    136                 * VLC
    138 Some software we use are ports from other systems. Currently, Transmission and VLC are working, but only on the command line. Write a nice native GUI using the Be API for them.
    140         * Hardware profiling tool
    141                 * an application for creating a hardware database.
    143 Haiku supports a wide range of hardware, but there may be problems in some cases, be it a missing driver, an outdated one, or a nasty bug. Write an application that gathers all the available information about a computer running haiku, and generate a report file users can send to the devs when they report bugs. This would help building an hardware compatibility matrix that would both help people to select what computer to buy, and help devs select what device to test and fix.
    145         * Language bindings in SWIG
    146                 * python
    147                 * perl
    148                 * ...
    150 Scripting languages should be able to use the system API directly. Python and Perl have an object-oriented approach that would allow using the Be API and using the full power of the Be API right inside your scripts. This includes displaying windows, but also accessing the locale kit, or other native stuff.
    152         * Maybe something involving HaikuPorts?
    153                 * improving HaikuPorter to work more like FreeBSD's ports  -- python programming
    155 HaikuPorter is the tool used to collect infprmation about ports from the unix world (or elsewhere) to Haiku, and building packages from this information. It needs some improvements.
    157         * Jam build system enhancements.
    158                 * like what...?  generic wrapper for autotools, makefiles. This would help integrate existing projects into Haiku's source tree or 3rdparty folder
    160 Haiku use the jam build system for managing the source tree. This creates problems when importing an existing library (ICU, freetype), because most of them use autotools instead. Until now, devs rewritten the build systems of these libs using jam. It may be better to allow wrapping autotools directly, so jam would lauch the correct autotools procedure without having to mess with the imported files.
    162         * Enhancements for Virtualization Software
    164 Haiku works nicely both on real hardware and virtualized machines, but lacks most of the so-called "guest additions" that allows smoother integration with the host. This include changing resolution on window resize, mouse automatically switching from host to guest and back, file sharing. Write such a guest addition package for virtualbox or/and vmware
    166         * Universal Spell Checker, built upon the WordServices SDK. note: see [ Spill Chucker]
    168 Integrate a spell checker to the Haiku API, so all apps can request it to find mistakes in a BTextView or some other custom widgets, and highlight them.
    170         * Improving [ QT4 port]
    172 Haiku now has a qt4 port, but it is far from perfect. Fix bugs, make it look more native.
    174         * IPv6 '''Mentor Needed! '''
    176 IPv6 is a new network protocol that allows easier management of the Internet. Without it, at some point Haiku will be unable to join any network. Write an IPv6 protocol handler and integrate it to Haiku's network stack.
    178         * CUPS
    180 CUPS is used on most UNIX system to manage printers. The Haiku project would like to recycle their drivers and not write new ones for every available printer. Either port CUPS itself and integrate it to the printing kit in Haiku, or make the printing kit able to use CUPS driver files.
    182         * Gallium3d
    184 Gallium3d is a software stack allowing faster hardware acceleration in a more cross-platform way. Some work was started to make it run on Haiku, but it lacks a kernel module for handling DRM, so the drivers upper in the stack can plug to it. Write such a module and bring 3d acceleration to Haiku.
     4== 2010 ==
     5See official page here: []
    1867== 2009 ==
    187 See official page here: []
     8See official page here: []