Google Summer of Code

Port mozilla engine to ggi. The goal is to run firefox as a native GGI application. For this the widget and layout engine may be port to GGI. http://lxr.mozilla.org/mozilla/source/gfx/▸ should probably be extended to contain ggi specific rendering classes. http://lxr.mozilla.org/mozilla/source/widget/▸ should probably be extended to contain ggi implentations of mozilla widgets. Reference material:

• Mozilla layout engine page : http://www.mozilla.org/newlayout/▸
• A good introduction to porting the layout engine : http://www.mozilla.org/newlayout/ngport.html▸
• GGI documentation : http://www.ggi-project.org/documentation/index.html▸

Project requirements: Skills in C, no special requirements on HW or SW.

LibGGIwidget is a simple library for making graphical user interfaces with GGI. Normally, you use C function calls to generate a tree of widgets and set the appropriate attributes that determine the look of the final application.

While this is relatively simple for small applications, specifying complex GUIs dircetly in the code is not too much fun.

An interactive application should be made that allows to create dialogs by placing widgets graphically and manipulating their properties from a GUI.

The application should finally generate readable code that can be linked to the target application.

Project requirements: Skills in C, no special requirements on HW or SW.

Start out with patch from Sean D'Epagnier at http://marc.theaimsgroup.com/?l=ggi-develop&m=115293199612665&w=2▸

Project requirements: Skills in C, caca software, no special requirements on HW.

You start on an existing framework called libggigl. Its goal is to extend libggigl with the OpenGL API, allowing GGI applications to easily use OpenGL for drawing. This would enable XGGI to provide GLX support, for example.

libggigl uses targets for APIs which provide native OpenGL support (e.g. on X, this is GLX). For other targets with no native OpenGL support (e.g. aa, fbdev), it uses Mesa to do OpenGL on them. The project goal is to make it usable on at least one target of the students choice. If time permits, also implement GLX support in XGGI.

Project requirements: Skills in C, no special requirements on HW or SW.

implement hw acceleration in display-quartz using MacOS's OpenGL

Project requirements: Skills in C, Apple Mac with MacOSX 10.4

Rework display-directx and use DirectX acceleration for drawing operations.

Project requirements: Skills in C, Windows 2000 with DirectX 7 or newer

Bittorrent is a common file distribution system that is used to offload download servers for popular downloads (like Linux LiveCDs) by sharing bandwidth between clients to exchange already downloaded parts.

The original client is largely written in Python and there are some implementations that provide a GUI (either as frontend or with a native implementation of the protocol).

A GGI client could allow for a more detailed status while not requiring a full GUI server like X system to be up.

implement multiframe output in display-file(7): MNG and/or YUV4MPEG

Project requirements: Skills in C, no special requirements on HW or SW.

XGGI is a variant of the Xorg server, which uses libggi instead of the traditional DDX, thus giving it access to all of the GGI targets which support ggi_directbuffer(3).

Possible improvments include:

• Implement some X extensions like Xinput. KDE likes it.
• Available X extensions such as RENDER should use libggi functions for hw acceleration.
• Update randr support to the new 1.2 revision
• Implement DPMS handling
• Implement Composite extension

Time probably doesn't permit implementing all of these; the student has to pick some he wants to work on.

Project requirements: Skills in C, no special requirements on HW or SW.

To allow running existing applications on the GGI infrastructure, wrappers can translate from popular interfaces that many applications use to the GGI API, so they can use libggi. One interesting wrapper would be for libdirectfb. This task involves figuring out what's the best way to implement this: Simply create a DirectFB renderer using libggi as backend; plug deeper into libdirectfb; or even completely reimplement the DirectFB API on top of GGI. After finding the best approach, implement it.

Project requirements: Skills in C, no special requirements on HW or SW.

Allow applications requiring a "big" visible area to display on systems with only a "small" visible area. Allow the visually impaired to magnify any application. Integer zoom ratios and simple interpolation schemes as a first step. If time permits, this is extendable.

A zoom pseudo-target can also be used by display-vnc(7) to implement server side scaling of the framebuffer served to the client.

Project requirements: Skills in C, no special requirements on HW or SW.

libggi provides some 2D drawing functions, but these are very limited and low-level. Today, cairo is available as a versatile and extremely powerful 2D drawing libarary. Integrating libggi with cairo would allow easily porting many existing applications and toolkits to libggi, including new versions of Mozilla and GTK.

This task involves figuring out what's the best way to implement this: Simply create a cairo backend using libggi for output; or plug deeper into the libcairo. After finding the best approach, implement it.

Project requirements: Skills in C, cairo software, no special requirements on HW.

The libggi backend abstraction allows using GGI on top of many different driver frameworks. (KGI, DirectFB, Quartz etc.) However, while some of these frameworks offer distinct advantages (like proper kernel support), they generally aren't as featureful as Xorg's DDX backends -- most notably the xf86 DDX with all the normal accelerated drivers.

Implementing a framework that would allow using the Xorg DDXes as libggi backends, would enable XGGI (and everthing else using GGI directly or through wrappers) to reuse the existing DDXes; thus providing a smooth transition path from the traditional Xorg server to XGGI, without being forced to switch to some entirely different driver backend.

If implementing a generic DDX backend framework turns out problematic, an alternative approach would be to implement only an xf86 backend, so the -- most interesting -- xf86 drivers could be used by libggi at least.

Project requirements: Skills in C, no special requirements on HW or SW.