|This page or section may require cleanup, updating, spellchecking, reformatting and/or updated images. Please improve this page if you can. The discussion page may contain suggestions.|
XBMC development (Overview)
2 Source code
3 Development Tools
- Doxygen - Source code documentation generator tool.
4 Other tools and resources
Though any other tools or resources are not required they can possibly help in development.
- Eclipse CDT Setup For XBMC Development
- Doxygen - Source code documentation generator tool.
- Valgrind (for Linux) - a free Linux programming tool for memory debugging, memory leak detection, and profiling.
- Sysprof (for Linux) - a free System-wide Linux Profiler for tracking CPU usage. Sysprof is a sampling CPU profiler for Linux that uses a kernel module to profile the entire system, not just a single application. Sysprof handles shared libraries, and applications do not need to be recompiled. In fact they don't even have to be restarted. Just insert the kernel module and start sysprof.
4.1 XBMC Artwork
The official logo package and source files can be downloaded at sourceforge directly from the link below.
5 General guidelines
- Code documentation (DocBook, rst, or doxygen for the code documentation steps, preferably the latter, doxygen)
- Self-containment - XBMC should be as little dependent as possible on operating-system and third-party services/deamons/libraries
- XBMC should for example contain all file-system and network-client (like samba) support built-into the XBMC package
- Modular design - independent modules made up by localized/isolated code libraries without dependencies
- XBMC should still compile and run if a non-essential module/library is disabled or removed
- Aim for the GUI/interface to run smoothly on a low spec computer (single core with less than 1Ghz)
- 3D graphic controller (GPU) will always be required hardware for XBMC so try to utilize the GPU as much as possible
- Avoid hard-disk trashing (excess read/write/erase cycles), so no hard-drive paging, (utilize RAM memory instead).
- End-users will be running XBMC and the operating-system on solid-State memory as a Live CD (LiveDistro) of a USB-key
- Fast load and boot times for end-user perception (other things can still run/start in the background without the user knowledge)
- 15-seconds or less from when the end user press the power-button on the computer till he/she can browse the GUI
6 User-friendliness is next to godliness
One major ongoing goal of Team-XBMC has always been to make XBMC and its user interface feel even more intuitive and user-friendly for its end-users, based on the KISS (Keep It Simple Stupid) principle of simplicity. It is our belief that usability is the most important aspect of a media center like XBMC. Many other media center projects make user interface decisions by developers, who often have little experience in user interface design. In contrast, Team-XBMC does its best to listen to XBMC's end-users to learn how XBMC is actually being used and how we can improve the user experience. We also aim to do regular overhauls, improving existing features/functions, and scrapping outdated code and features/functions (as "too much stuff" adds unnecessary complexity and can thus also be a bad thing). Everything should be made as simple as possible, but no simpler.
6.1 XBMC as a whole must...
- First and foremost be aimed at a large-screen (28" or more) 10-foot user interface for the living-room experience.
- Large menus, text/fonts and buttons that is designed to be navigated by a hand-held remote-control.
- Be focused around the main features of playing music, watching movies, recorded television broadcasts, and viewing pictures.
- XBMC may be capable of converging other things but those things should never take over the main focus in the interface.
- Be easy to install, set up and maintain (so that our valuable end-users do not get fed up with it and quit).
- Have an user interface that is simple and intuitive enough so that less tech-savvy people are not intimidated by it.
- Make common usage easy, simple 'Human–Computer Interaction (HCI)', from the viewpoint of an ordinary user.
- Be able to play audio and video files that have been encoded using DivX, XviD, etc. directly out-of-the-box.
- Be able to organize audio and video files in an easy and user-friendly way.
- Use standards and be consistent, (the Music section can for example not use completely different controls from the Video section).
- Perform actions in the GUI with as few 'clicks' as possible.
- Be aimed at an international audience, internationalization and localization by supporting different languages, timezones and other regional differences
- Require little to no non-GUI configuration (and all such non-GUI configuration should be done in just one file: advancedsettings.xml).
- Be beautiful to look at, after all we hope you will be using it a lot!
6.2 Team-XBMC members should always strive to
- Promote open source - XBMC is based on the ideas of FOSS (free open source software), licensed under the GPL and builds partly on other open source projects which we do our best to support. The GPL should be respected at all times. All code should be committed to the XBMC project’s git repo before any public binaries are released.
- Promote the sharing of knowledge and collaboration - Through the use of information sharing tools and practices XBMC is a collaborative environment.
- Understand that development is a team effort - Treating our users as co-developers has proven to be the most effective option for rapid development. Always strive to work as a team at all times. Actively promote discussion on new features and bug fixes, and respect others comments and criticisms with replies in a timely fashion.
- Apply the Law of Diminishing Return - The majority of the effort should be invested in implementing features which have the most benefit and widest general usage by the community.
- Try to make all code, feature, and functions to be platform agnostic - XBMC is a multi-platform software, thus any single platform specific features should be discussed with other team members before implemented. Major features should be developed in a separate branch or committed in small increments so that other members have the opportunity to review the code and comment on it during development.