GSoC 2009

General Information

WinLibre is an open source project aimed at popularizing Open Source software.

WinLibre is a META-project that was originally targeted for the windows platform (hence its name) but it has evolved during the last 3 years to embrace also the Mac OS and Linux platforms. We are focusing on delivering to our users quality open source software with a strong emphasis on ease of use. We are mainly maintaining WinLibre (open source software distribution for windows) and MacLibre (open source software distribution for Mac OS X).

The Winlibre distribution provides a collection of first-class open-source software bundled in a easy single installer & updater. Through time and thanks to the former editions of the Google Summer Of Code, the Winlibre project has evolved and created other sub-projects to fill gaps in the open-source desktop software offering. The Maclibre distribution is an equivalent to the Winlibre distribution for Mac OS.

Guidelines for students

Time Line

The student application period begins Monday, March 23, 2009, and ends Monday, April 4th. Accepted students will be known on April, 20th.

You can find more information on the time line on the GSoC page

We will proceed to a phone or video interview between April, 4th and 11th in order to help us select student’s applications. Please be available during this interval.

Student Signup http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

About Ideas

The ideas listed on this page are just that - ideas. They are deliberately somewhat vague, because you are meant to fill in the details.
Last year there were too many proposals that were simply cut-n-pasted from our ideas page.
Don’t do that! If you do, you will be tossed out very early in the application sorting process.

In other words - sell yourselves in this Wiki - and link your proposals with the project idea.

Do I have to use one of the ideas?

Definitely not! These are here to get you started, and because some folks think it’d be great to see them done.
If you have your own idea, run with it. We’ll judge applications on their strengths, not on who wants the project done or who thought of it.

Writing your application

If you (as a student) find an idea you like, we ask that you create :

  • a list of deliverables
  • quantifiable results for the WinLibre project
  • a detailed description / design document
  • an approach
  • an approximate schedule and some kind of background text.

Here are a few documents (written by the Drupal and PostgreSQL teams, but applicable to Winlibre) that could help you in writing your application :

Drupal's Write a SoC applicationDrupal's Student requirementsPostgreSQL: Advice to Students on Submitting SoC ApplicationsGood example we got years ago (Thanks Pawel)

Contact

If you any question contact us:

Proposals

WinLibre Package Manager Proposals: #1 #2 & #3

This is our main project. It will be splited into three proposals.

Primary Contact Licence OSLanguage
Bertrand Cachet GPL Multi OS Python

Scope

Main Goal

We want to develop a package management system for Windows in order to facilitate the deployment of Open Source applications on Windows systems.

In deed there is no application of that sort onto Windows platform. Nowadays, users need to find the application on the web, download/install/keep it updated by themselves. Moreover, there are a lot of different way to manage applications on the Windows platform. End users need to know all of them.

Package manager will be in charge of displaying informations about available packages to the user. User will be able to install/upgrade/remove the application he has selected. End user will manage his/her applications from this single tool.

Our package manager will be able to handle dependencies between packages. That will ease the deployment of applications on Windows platforms because developers will not need to keep a watch on the libraries they use anymore.

Description

The package manager ecosystem is divided into several parts. We have decided to create one proposal for each of these component. One student will be working on each sub-system. They will cooperate intensively during the whole summer in order to build a fully functional package management system.

Each sub-system (Repository, Package Manager, Package creator) consist in a peculiar proposal.

Repository (Proposal 1)

This is the place where all the informations about software will be stored and display. All these informations will be available to package manager in two ways:

* Global: A list of the names, versions and descriptions of the available applications for the platform.

* Specific: The specific information for a given application: URL of the binaries, URL of the developer web site, dependencies, ... which will be used to install/remove/update the application itself.

Anyone can access to this website to get information about packages, rank applications, leave comments ...

Only developers are able to update informations about the software they develop. They can do it using the web interface or by POSTing a package to the URL associated to their application. The second mode will be used by package creator to push new release on the repository.

We will need a way to make it impossible to post a new package that contain viruses and/or content that is not wanted. We need to have a look to repositories like http://pypi.python.org/pypi to understand how do they proceed.

We will need to provide different ways to access to the list of available packages. We may want to get the complete list of available packages, or the list of the packages that have been updated since a given date or just the list of a given category ... All the work will be done easily with the help of database request and it will help us to limitate the amount of data exchanged with the server.

To resume, we want a repository (place where we get info from available packages and packages themselves) and also features like the ones on http://www.kde-apps.org/

Package Manager (Proposal 2)

Application used to search/install/remove/update applications on the user’s Windows system. It will handle software dependencies will install all the libraries/applications needed by the software to run properly. User will interact with application using CLI or GUI.

Package Manager is divided in two parts:

* One will install/remove/update application using the package file. We will call it the Package Installer.

wpkg *action* <package> Install/remove/update software described into package file. wpkg will use scripts located into the package and will use/download binary representation of the application
wpkg *status* <package> Get stattus of the package. Possible output:Installed/Not Installed/Update Available.
wpkg *show* <package> Show information about package. It will output: name, description, license and so on.

* Another one will search/download packages from repository. It will also handle dependencies. We will call it the Package Manager.

wpckgmgr *update* Updates package lists. Get last package list from repository.
wpckmgr *action* <name> Install/update/remove package. Handles dependencies.
wpckgmgr *search* <keyword> Search through name/description of packages. Outputs names of packages whose name or description fits the keyword
wpckgmgr *show* <name> Outputs information about package. It outputs even if package wasn’t installed or downloaded. Manager gets information from package list.

As we decided to use the  SMART library, we already have the Package Manager. We only need to develop a Package Installer which will handle MSI, InstallShield, Inno Setup, Nullsoft packages and the associated backend for the smart library.

In a first time we will reuse the existing SMART interfaces: GTK, QT, CLI.

User will select the application to install using the graphical interface he wants (GUI or CLI), SMART will search for this package in the list of available packages (that it gets from the repository). If it find a package that match the search then it will download this package and all the needed dependencies. When SMART gets all the needed packages it will call the Package Installer to install it.

We only need to develop this Package Installer.

Our Package Installer should be able to:

  • Install software silently
  • Remove software silently
  • Check if software is already installed

To do that, we will need to know how to:

  • Ask installer to perform its task silently
  • Find a way to automize setup that are noisy and are waiting for information about the user (using pywinauto ?)
  • Find information into the registry and/or from windows installer to know if a software is already installed or to remove it (reading registry ?)

We cannot fully automize this kind of tasks, so we will develop modules that ease the writing of a script that will specific to one software installation. Into each package we will have several scripts to: enumerate (does software already installed), install, remove, update applications.

For example a enumerate script will look like:

from registry import exist, read
def is_installed():
  return exist('ARegistryKey')

def get_version():
  return read('ARegistryKey')

We will only install packages that have been created with our Package Creator: they will contain: a file describing the software itself (XML file), scripts like explained previously. Binaries of the application can be integrated to the package or not. Everything will be noticed into the package description file. For example and URL with :http: indicate we will need to download it but a package: URL indicate that binaries are included into the package itself.

Package Creator (Proposal 3)

This tool will be used by the software developers to upate informations about their packages onto the WinLibre repository.

Developers will give informations about their application (name, version, description, dependencies, binaries) to the Package Creator which will create the package and also upload informations to the repository.

The aim of this tool is to ease the deployment of applications onto Windows platform. Most of the open source projects use the same libraries. On POSIX system they only provide a binary of their applications and give a list of the libraries they depend on. Package Manager like *ports*, *apt*, *rpm* handle the dependencies for them. On Windows, most of the time, they add to their installation a binary representation of the libraries they use because they need to apply some patch on them in order to make them Windows compliant. That means that each Open Source organization has it’s own patch for the same libraries. All these patches are a redundant work which can be skipped if we are able to create packages of these patched libraries and handle dependencies.

That’s this problem that we want to solve with our Package Creator. We would like to have a common repository where a package of all the common libraries can be found so that Open Source organization can link them dynamically just by providing the list of libraries the depend on.

Main goal is to handle dependencies for developers. We will write tutorials to help developers link DLL dynamically which is not so easy on Windows. But providing some guidelines will help developers to enjoy the fact that they will not need to support libraries they use. Of course, these tutorials will no be written by the students but by ourself with the help of other developers.

Technical Specifications

These are technologies we may use during our development

Package Manager

We will use SMART (http://labix.org/smart) motor to perform all the tasks of finding/downloading packages, handling dependencies, displaying informations about packages. Currently backends for Debian, Suse, Fedora, Mac OSX .. already exist.

We need to develop a SMART backend for Windows platform that mean a tool that will be able to install/remove softwares contained into MSI, NSIS, NullSoft packages.

In a first time we will use the existing GTK/QT interfaces from SMART library. If we have the time, we will adapt the existing one or develop a new one.

The Repository Server

It’s a RESTful web application where each URL represent a package:

* GET access is public and can return JSON, YAML or HTML formats. GET access will be used by WinPacMan client to get information about the package.

* POST, UPDATE and DELETE access are protected (authentification via OpenID or Google Account). These access are used by the Package Generator Tool to update information about the package.

We plan to develop it on appengine to be scalable.

Packages

They will contain: a file describing the software itself (XML file), scripts that can be used to install/remove/enumerate the application. These scripts will be developed by the developers and us using all the tools we will develop to simplify this process like explained into the chapter about package manager. All the default installers (MSI, NullSoft, InstallShield) will be handled automatically,in these cases, scripts can be more or less empty.

Binaries of the application can be integrated to the package or not. Everything will be noticed into the package description file. For example and URL with :http: indicate we will need to download it but a package: URL indicate that binaries are included into the package itself.

We propose three proposals that belong to the same global project. Each part of this project will interact with others:

  • Package Manager - Repository:
    • Package manager will fetch list of available packages from the repository. It will fetch a compressed XML file.
    • Package manager will fetch packages from the repository to read them and be able to install softwares.
  • Package Manager - Package Creator:
    • Package Creator will POST new package to the repository. Repository will parse this package to update information about the application

Each part of the project can be developed individualy, we just need to define:

  • Content of the package, especially the content of the XML file included into the package that will contain information about the package.
  • File Format of the file containing the list of all the available packages.

We think we can use the following file format for our project: http://xtreeme.org/xpkg/. We will define precisely all the needed file format and the content of a package before the beginning of the GSoC so that students can be independent.

We want to share as much code as possible between project. We will try to develop every part of this global project from the same repository folder. Maybe we will add branches if needed but Repository, Package Manager and Pacakge Creator will be contained into the same project.

We will setup all the needed directories and tools before the beginning of the GSoC. We want such an organization to force students to interact with each others and communicate about what they implement. It’s really important even it is not easy to work on a same project at the same time.

Pwytter Improvements : Twitter Client for Windows, Mac, Linux

Primary Contact Licence OSLanguage
Pierre-Jean CoudertGPL Multi OS / Qt Python

http://www.pwytter.com/ : Twitter client, Multi-OS, Python, GPL

MacLibre 3 : Open Source Software Distribution for Mac OS X

Primary Contact Licence OSLanguage
Pawel SolygaGPLMac OSX Python

Description

MacLibre has been an outstanding success of former Summer Of Code editions. We would like you to help this project going even further with its third version...

Here are some of the enhancements we would be glad to see in MacLibre v3. Of course any other great ideas are welcome and encouraged!

  1. ask for installation directory path if you have no rights to install in /Applications directory
  2. show estimated time to finish downloading
  3. download pause and resume
  4. local copy of downloaded file if something gonna go wrong we don’t have to download everything from the beginning
  5. move configuration files from ~/.MacLibre to the Mac OS X apps data specific location
  6. create apps updates notification daemon with Growl support (http://growl.info ), you can use Growl python binding
  7. add buttons for reporting new version of apps and new useful apps
  8. integration with Spotlight (plugin)
  9. support for Mac OS X proxy settings
  10. implement a Sparkle software updates (http://www.andymatuschak.org/pages/sparkle )
  11. automatic apps update tool (versiontracker or macupdate sync), there is a problem with MacLibre and this kind of applications that apps updates takes a lot of time. This tool would make automatic versions updates, this might be integrated with admin tool
  12. admin and maintenance tool for MacLibre. It would be important tool not only for developer, but also for users who could create their own MacLibre distributions. We will get a tool for editing/modifing installation xml files. Mostly everything will be based on xml file modifications. With such tool we will cut down updates/new versions development time.

Most important features of admin tool:

  • automaticly make online (internet) / offline (stand alone) versions of MacLibre using scripts written for MacLibre 2,
  • easily add new applications to distribution (Virtue, QuickSilver, Vienna and many others).A good place to start might be those urls: http://nothickmanuals.info/doku.php?id=opensourcemac, http://www.opensourcemac.org/
  • test applications installation process (some kind of unit testing for each application including http url, downloading, md5 etc),
  • modify existing MacLibre configurations/distributions (modification of xml file),
  • ability to make new kind of distributions: MyOwnMacLibre, MacGamesLibre, MacOfficeLibre, etc. (creating new xml files),

Ressources

Deliverable

  • Source Code
  • Setup.py to generate a .App file

GPS Data display and management software

Primary Contact Licence OSLanguage
Julien Marbach (jumar) GPL Multi OS mono/c#

This is an open proposal, applicants are encouraged to add their own ideas as far as the main goals are respected.

Overview

On the windows platform there is currently no high quality open-source GPS management software. To review, display, backup their GPS data most users must use the proprietary software shipped with their device (Like MapSource for Garmin GPSs). Those software are very poor in terms of usability, responsiveness and overall quality. What we would like to see developed during this summer of code is a fast and easy to use GPS data management software with the ability to visualize GPS tracks and waypoints and display maps from online and/or local databases.

Key features

  1. Dynamic & fast display of maps from online (Open street map, google maps...) sources
  2. Ability to display and edit GPS tracks and waypioints
  3. Ability to store in a database all track and waypoint data

Secondary features

  1. Ability to transfer data from a GPS Device
  2. Ability to display maps from hard drive
  3. Ability to store partial online maps on hard drive in order to be able to use them when offline
  4. Live position tracking and track recording

Implementation constraints

  1. Must be implemented using a cross platform framework: mono and C# should be considered as a serious candidate
  2. Must provide the same features on windows, linux and Mac OS X
  3. Pan and zoom must be fast and smooth
  4. Large datasets must not impact overall performance
  5. A data abstraction layer must be used to allow for various data storage back ends

Botomline

We would like to focus on the quality of the basic features before adding bells and whistles to the software. Implementing “Trendy” features like photo geotagging or social networking abilities are not the main goal of this project but may be considered when a solid code base will be done.

Open proposal : New Innovative Desktop Application

Write a new, innovative, multiplatform, windows compatible, easy to use desktop application.

If you want to create a brand new, innovative application, write and submit a proposal.

Note : Before submitting your idea(s) please be sure that no other Windows open-source alternative already exist (in terms of functionality, quality, ease of use...). Intensive Google searching will help you at this point.

Links

 
winlibre_soc_2009/proposals_for_the_google_summer_of_code_program_2009.txt · Last modified: 2009/04/10 10:07 by 88.175.148.213
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki