= 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 === * Non R1 tasks: http://dev.haiku-os.org/wiki/FutureHaikuFeatures 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 [http://dev.haiku-os.org/query?status=assigned&status=new&status=reopened&component=%5EApplications%2FMail&component=%5EServers%2Fmail_server&order=id&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component tickets] exactly has yet to be decided). Haiku features an integrated mail management system allowing to manage your mail using Tracker, the file explorer. This system needs some improvements and updates. * 3rd Party Applications * [http://dev.osdrawer.net/projects/imkit IM Kit] * [http://dev.osdrawer.net/projects/caya Caya] -- Planned to eventually replace IM Kit 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). * [http://dev.osdrawer.net/projects/serviceskit Services Kit] * [http://haiku.pastebin.com/f28de1029 Summary] * [http://www.freelists.org/post/haiku/GSoC-Web-Services-Kit-OS-integration Mailing List thread] * [http://www.freelists.org/archive/haiku/03-2009 May contain additional threads] 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. * WebKit based browser 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) * OpenJDK Haiku is not able to run Java. Port OpenJDK so this language can be used in Haiku, to run applets and other apps. [http://openjdk.java.net/projects/haiku-port/ OpenJDK: Port: Haiku] * full NFSv4 client with xattr support and caching 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. * Utilizing aspects of 3rd party software * Creating Text Translators from OpenOffice Translators allows apps to automatically open documents in any format. The OpenOffice.org documents format are quite common and well documented, so Haiku apps should be able to read them. Write a translator so this becomes possible. * Integrating software into Haiku 1. updating to use a jam build system 1. complying with Haiku's Coding Guidelines 1. layout manager 1. HVIF icons 1. Locale API 1. possibly becoming an actual part of Haiku's source tree and not a 3rd party addition * [http://dev.osdrawer.net/projects/infopopper InfoPopper] -- as an actual notification_sever * [http://www.freelists.org/post/haiku-development/Notification-Server Big discussion in May 2007] * [http://www.freelists.org/post/haiku-development/infoPopper-info-server And some more in April 2008] * [http://www.freelists.org/post/haiku-development/Comments-on-these-possible-OptionalPackages,18 Year++ with plan for integration] * [http://dev.osdrawer.net/projects/pecorename PecoRename] or [http://dev.osdrawer.net/projects/rename ReName!] * [http://dev.osdrawer.net/projects/colors Colors!] * [http://dev.osdrawer.net/projects/clipup ClipUp] * [http://dev.haiku-os.org/ticket/1098 CD/DVD burning application] Maybe update Burnit Now 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. * Native GUI for: * Transmission * VLC 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. * Hardware profiling tool * an application for creating a hardware database. 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. * Language bindings in SWIG * python * perl * ... 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. * Maybe something involving HaikuPorts? * improving HaikuPorter to work more like FreeBSD's ports -- python programming 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. * 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 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. * Enhancements for Virtualization Software 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 * Universal Spell Checker, built upon the WordServices SDK. note: see [http://www.haikuware.com/remository/view-details/productivity/utilities/spill-chucker Spill Chucker] 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. * Improving [http://dev.osdrawer.net/projects/qt-beos QT4 port] http://qt-haiku.ru/ Haiku now has a qt4 port, but it is far from perfect. Fix bugs, make it look more native. * IPv6 '''Mentor Needed! ''' 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. * CUPS 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. * Gallium3d 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. == 2009 == See official page here: [http://www.haiku-os.org/community/gsoc2009/ideas]