Difference between revisions of "Google Summer of Code 2010"

From LXDE.org
Jump to: navigation, search
 
Line 1: Line 1:
 
{{old}}
 
{{old}}
 
LXDE is participating in the Google Summer of Code 2010 as a mentoring organization. Many other projects usually also offer student slots for the LXDE community in the program. We are gathering project ideas, as a way to start for applicants here. If you are interested to join LXDE at the summer of code and would like to discuss project ideas, please join us on IRC at irc.oftc.net #lxde. Please also have a look at the set up guides for LXDE and PCManFM:
 
LXDE is participating in the Google Summer of Code 2010 as a mentoring organization. Many other projects usually also offer student slots for the LXDE community in the program. We are gathering project ideas, as a way to start for applicants here. If you are interested to join LXDE at the summer of code and would like to discuss project ideas, please join us on IRC at irc.oftc.net #lxde. Please also have a look at the set up guides for LXDE and PCManFM:
[[PCMan's Complete LXDE Setup Guide]] and [[PCManFM build and setup guide]].
+
[[PCMan's Complete LXDE Setup Guide]] and [[LXDE:PCManFM build and setup guide|PCManFM build and setup guide]].
  
 
Following are currently proposed projects open to student applications. Please choose the one you're interested in and send the application via Google SoC or propose new projects if you have better ideas.
 
Following are currently proposed projects open to student applications. Please choose the one you're interested in and send the application via Google SoC or propose new projects if you have better ideas.

Latest revision as of 13:11, 30 January 2012

Outdated icon.svg This page is outdated and is only kept for historical reference.

LXDE is participating in the Google Summer of Code 2010 as a mentoring organization. Many other projects usually also offer student slots for the LXDE community in the program. We are gathering project ideas, as a way to start for applicants here. If you are interested to join LXDE at the summer of code and would like to discuss project ideas, please join us on IRC at irc.oftc.net #lxde. Please also have a look at the set up guides for LXDE and PCManFM: PCMan's Complete LXDE Setup Guide and PCManFM build and setup guide.

Following are currently proposed projects open to student applications. Please choose the one you're interested in and send the application via Google SoC or propose new projects if you have better ideas.

Project List for Google Summer of Code

Accessibility Improvements

LXDE is designed to run well on low spec systems. We want to help those who cannot afford new hardware. In addition, we also want to help those who are disabled, especially for those who are blind or visually impaired. So accessibility is a very important issue.

Here are the requirements:

  • Make sure all custom widgets in LXDE components work with accessibility technologies (AT).
    • GTK+ widgets have built-in ATK support by default, but for custom widgets, this is not the case. For example custom widgets are used in pcmanfm, lxlauncher, and lxpanel. We need to get them work properly with accessibility technologies.
  • Desktop management of PCManFM uses custom widget for the desktop window. It doesn't have built-in ATK support. Make the desktop items work nicely with AT so blind people can use it.
  • LXLauncher for performance reason doesn't use GtkWidgets for its window content. Launcher buttons are painted with cairo and there was no real button. So again, ATK support should be added manually. Blind users should be able to navigate the whole launcher and access all buttons with keyboard or other measures supported by AT.
  • LXPanel cannot be operated with keyboard and you have to work with mouse. There should be a special mode for blind people to navigate through all panel items with keyboard only and again ATK support need to be added to all custom widgets used in it.
  • Make sure all other LXDE components listed on http://lxde.org/ work properly with AT.

Mouse Gesture and Small Screen Support

For most desktop users, menus and shortcut keys might be enough. However, for those who use hand-held devices or tablets, mouse gesture might be more handy. So to improve user experience on those devices, we can try to add mouse gesture support to LXDE components.

Here are the requirements:

  • Build a small generic mouse gesture library written in C.
  • The logics used to recognize patterns should use libc only. (libmouse-gesture)
  • Add a wrapper to this core library for easy use in gtk+. (libmouse-gesture-gtk)
  • Design a GUI way for the user to define new mouse gestures and to associate it with an action.
  • Add vala vapi file for this library (optional)
  • The library should be very small, robust, and fast.
  • The API should be very easy to use in gtk+ programs, like the following example:
MouseGesture* mg = mouse_gesture_new();
mouse_gesture_add_pattern(mg, pattern_string1, id_action1);
mouse_gesture_add_pattern(mg, pattern_string2, id_action2);
mouse_gesture_add_patterns_from_file(mg, filename);
mouse_gesture_bind_widget(widget, mg, mouse_button);
g_signal_connect(mg, "action", G_CALLBACK(on_mouse_gesture_action), widget);
g_object_unref(mg);
  • The APIs should be well-commented
  • Generate API doc with gtk-doc
  • Add mouse gesture support to PCManFM and other LXDE components such as GPicView.
  • Ensure that LXDE components can adapt to small screens. May use alternative GtkBuilder ui files when small screen is detected or by reducing unnecessary margins and paddings of widgets.

LXLauncher theming support

LXDE is very suitable for netbooks and it provides an application launcher similar to the one provided in EeePC. However the original one is a little bit limited and the colors and background are hard-coded. This project requires that you implement theming support for LXLauncher.

Here are the requirements:

  • Creating a theme format which is simple and can be loaded very fast.
  • Each theme should be a sub dir under /usr/share/lxlauncher/themes/
  • Each theme dir should contain a gtkrc file to theme gtk widgets. The theming support should load the gtkrc file of the selected theme with gtk_rc_parse.
  • Each theme dir should contain a index.theme file describing the name and author of the theme. Besides, this file can also contain other data needed by the theme, such as background image for each application category.
  • Each theme dir should contains image files needed by it.
  • The theme should enable setting background images for different application category. For example, the 'Internet' page can have different background image from that of the 'Work' page. If no specific background image is specified for a application category, a default one should be specified.
  • The background support should not only paint the whole image file on the window background. It should support stretching or tiling of the image. The theme author should be able to set this in theme definition files.
  • Users should be able to change the theme on-the-fly.
  • Users should be able to set their favorite background images to override the one provided by the themes.
  • Prevent using xml for file formats. A simple ini file can work most of the time.
  • Encapsulate the background painting and theming routines in a library so it can be reused by other projects requiring background images, such as desktop manager of pcmanfm or lxdm, the display manager.

The theme library can contains some components (in pseudo code):

class ThemeObject {
  property:
    double xpos; (can be % or pixel value)
    double ypos;
    double width;(can be % or pixel value)
    double height;
    bool stretch;
    color bg[]; (colors used to draw gradient)
    gdxpixbuf pixbuf;

  method:
    paint(cairo_t cr);
}

class ThemeBackground {
  property:
    ThemeObject objects[];
  method:
    paint(cairo_t cr) {
      for each object in objects {
        object.paint(cr);
      }
    }
}

A background image can be freely composed by several theme objects. This can be very useful since you can join several smaller image files to form a composite background image.

Then, a GtkContainer drawing its background with ThemeBackground can be created. So everytime when we need background theming for some windows, we can add this container to the windows, and those windows will have background images.

Rewrite GPicView, the image viewer

The image viewer is designed to be lightweight, but is has some old unresolved bugs. Now it's time for a rewrite. Since this one is technically easier compared with other projects, it contains more items. The list seems to be very long, but 80% of the items are quite easy.

Here are the requirements:

  • Port image viewing part to use GtkImageView library. This is a nice library designed specifically for building image viewers. It's fast and memory efficient and did a much better work than ours.
  • Use GtkUIManager to create toolbars and menus.
  • Load image files with gio so remote files can be loaded as well.
  • Load images with multi-threading to prevent blocking of UI.
  • Optional supports for preloading previous and next images in the folder.
  • List image files in folder with GIO rather than GDir to support Remote filesystems. Again, this should use multi-threading.
  • While the directory is still being loaded, the user should be able to navigate through the list of files that are already found without blocking of UI.
  • Add ability to select a region of the image and crop to it.
  • Support printing with Gtk+ printing APIs
  • Ability to set wallpaper in LXDE, Gnome, KDE, and XFCE. (using pcmanfm, gconf-tools, ...)
  • Able to call external programs to open the image file. (Use GAppInfo in glib/gio)
  • Able to show EXIF information properly. (In a user friendly way)
  • Add a properties dialog showing detailed info of current image. (EXIF, size, mtime, ...etc.)
  • Add support for slide show.
  • Optimize for comic reading if a comic book is detected.
  • Single instance support. Use one process for all opened images only.
  • File alteration monitoring: update the display if the file on disk gets changed.
  • Thumbnail support, can optionally have a bar containing a list of thumbnails for easy navigation. (like gqview) (can reuse FmThumbnialRequest code in libfm)
  • Add screenshot taking ability to GPicView. (gpicview --screenshot)
    • A prompt dialog to let the users select some capture options:
      • Full screen
      • Single window
      • Selected region (can be implemented with grabbing full screen + gpicview fullscreen mode + crop to selection functionality)
      • Including mouse cursor
      • Time delay (in seconds)
    • The image viewing window of GPicView can be reused to view and save the result of screen capture, but the toolbar and popup menu should be changed to adapt to the needs of screenshots.
    • Reuse code already in GPicView whenever possible. It's estimated that only few additional code is required to add screenshot functionality to GPicView.
  • While adding new features, prevent making the UI too crowded or full of buttons.
  • If somethings cannot be achieved by using GtkImageView, this might require you patch the library and include the patched code in GPicView and at the same time send the patches to upstream authors. When the patches get accepted later, we can remove duplicated code included in GPicView.


File searching utility based on libfm for PCManFM

After the rewrite of PCManFM is done, now it's time to redesign the file searching tool in it.

Here are the requirements for this project:

  • Keep the original UI in pcmanfm 0.5.x if possible.
  • Able to search in several dirs at the same time.
  • Supports searching in remote filesystems.
  • Able to search for files of some mimetypes only. For example, only search for folders or for text files.
  • Able to search the content of files, like what grep does, but we need to support this for remote filesystems also. (Use mmap for local files and GInputStream for remote files to read file contents).
  • Able to search the filenames in compressed archives (zip, tar, gz, bzip, and 7z). (optional)
  • Implement the search by create a new class FmFileSearch subclassing FmFolder class. So the search result can be added to FmFolderModel and directly shown in FmFolderView.
  • The searching should use multi-threading correctly.
  • FmFileSearch and other non-GUI parts should be implement in the core library libfm and should only use glib/gio.
  • The UI parts should be done in PCManFM.
  • A search bar can be added to PCManFM main window. (optional)
  • The search bar may reuse the existing entry widget of location bar.


Add Custom File Actions, "Send to", and "Create New Files" to popup menus of PCManFM/Libfm

This is one of the mostly wanted feature in pcmanfm and libfm. Previously this is planned but it's not implemented because we're searching for a better and cleaner way to get it done. Now since a spec for this is already initiated on freedesktop.org mailing list, it's possible for us to implement this.

The requirements for this project:

  • To fully implement the proposed action extension to desktop entry spec in an efficient way: http://www.nautilus-actions.org/?q=node/377.
  • To implement a "Send To" sub menu in file popup menus of libfm. (just like the one provided in thunar)
  • To implement creation of new files from popup menu based on template files in ~/Templates.
  • Do some proper caching to prevent scanning the dir to load all the actions every time.
  • Add these to popup menus of libfm and pcmanfm.


Fork GVFS to provide a more lightweight, stripped down version without Gnome dependency

Since pcmanfm now uses glib/gio, it's quite natural to use gvfs in conjunction with it since without gvfs gio becomes very limited. However gvfs suffers from tons of dependencies and dependencies on some gnome libraries. This is very bad for LXDE. So there are needs to fork gvfs and provide a cleaner stripped down version.

Things should be done:

  • Remove gdu and hal monitor daemons from gvfs.
  • Write another simple gio module directly based on udisks to handle volume management.
  • Support setting per-mount options, such as encoding for a remote sftp filesystem or mount options for a local disk partition. This is always lacking in gvfs. (config storage should be based on simple ini files rather than something like gconf)
  • Remove gconf dependency. (this is already replaced by libfm-pref-apps)
  • Make dependencies on gnome-keyring optional. If library of gnome-keyring is found, load it on demand at runtime rather than linking to it explicitly.
  • Try to decrease the numbers of required daemons. Try to implement several kinds of backends in a single daemon, like joining the computer, trash, and network daemons into a single basic daemon.
  • Try to do file alteration notifications in gvfs for remote file operations. For example, if g_file_move is called on a GDaemonFile, we can generate a "file deleted" event for the source file and a "file-created" one for the destination file. Currently GFileMonitor is not supported for all remote filesystems. However this should have been done in gvfs, not in file managers. (optional requirement)


System config tools

Most of the basic building blocks of a desktop environment are already provided by LXDE. The only things lacking are system configuration tools. Currently we borrow those tools from Gnome. However, we still want some simple solution for things like setting date/time, manage users, ... etc.

Here are the requests for this summer:

  • The created configuration tools should be policykit-based.
  • Currently gnome system tools suffer from a usability bug. The whole dialog is disabled and only a unlock button is enabled. While this is good to let the user know that he/she needs to press the unlock button, it makes the user interface much less accessible if the user just want to view rather than to change the configurations. We should prevent this bad design.
  • All tools should be written in C or vala if possible. Distro-specific parts should in shell scripts so distro makers can patch them easily.
  • Create a simple time/date configuration tool supporting ntp.
  • Integrate the time/date configuration tool with lxpanel.
  • Create a simple tool to manage users and groups.
  • Create a GUI configuration tool for cron jobs. (optional)


A Menu Editor for the application menu

A good gtk+-only menu editor is always lacking. Even the one provided by gnome is poor. So, this one is wanted by many users. Although the requirements look shorter compared with other project, this one is quite challenging actually. Otherwise there should have been a good menu editor long time ago.

Here are the requirements for this project:

  • Should be written in C or vala.
  • Should fully support freedesktop.org menu spec. (http://www.freedesktop.org/)
  • Do not use gnome-menus
  • Prevent using libxml and use the simple xml parser in glib instead.
  • Let the users show or hide specific menu item.
  • Let the users delete items from the menu.
  • Let the users add their own programs to the menu. (with lxshortcut integration)
  • Let the users move menu items around using <Move> xml tag supported by the menu spec.
  • To load the menu, you can use menu-cache to speed up the loading, but saving the edited menu should be implemented yourself.
  • Should support XDG_MENU_PREFIX correctly.
  • Optional command line argument to specify a menu file to edit.


Volume control of lxpanel plugin (FIXME: this one is too easy, need to add more items)

The current volumealsa plugin of lxpanel is a little bit problematic and its behavior is not well defined. We need a new one.

Here are the requirements for this project:

  • The new plugin need to provide a UI to configure all channels and let the user select whether to control master volume or PCM only.
  • The user needs to be able to mute any channel in the UI.
  • When the volumes are changed by other applications, the changes should be monitored and the UI of the volume plugin must get updated, too.
  • Separate the UI from backends, so it's possible to support ALSA, PulseAudio, and OSS at the same time in the same UI.
  • Create backends for ALSA, PulseAudio, and OSS.
  • PulseAudio is not linked explicitly to the plugin. The plugin should detect if pulse audio is in use. If that is the case, dynamically load pulse audio support with dlopen or GModule and switch to pulse audio backend. PulseAudio shouldn't be a mandatory runtime dependencies since it's not available on some lightweight systems.
  • When PulseAudio backend is used, should be able to handle per-app volume control.

Power Manager for LXDE

Power manager is always lacking for LXDE. Currently we borrowed gnome-power-manager, but we still need our own. As LXDE is widely used on portable devices, power is an important issue.

Requirements:

  • Implement a power manager compatible with gnome power manager but get rid of gnome dependencies.
  • Based on upower.
  • Need to be small, efficient, and totally free from gnome dependencies
  • FIXME: this list is not yet finished. Need to define the specification more clearly.

Gnome Keyring replacement which is free from Gnome dependencies

It's possible to live in a world without secret. Security is a real issue. Removing unnecessary bloatness and dependencies from the desktop doesn't mean to make compromise on security. For GUI it's very inconvenient to type the password again and again. So some gnome-keyring like program is actually a good idea. Though we all believe that it can be lighter and can has fewer dependencies.

Requirements:

  • Implement a gnome-keyring replacement which has very low dependencies and is light on resource usage and also keep compatibility with gnome-keyring at the same time. (Is this possible?)

Proposals from students for this is needed.

Full multi-monitor support

The Openbox Window Manager is already aware of multiple monitor setups but the LXDE panel, session manager (logout) and desktop manager (login) don't.

Requirements:

  • Put centered dialogs on main monitor (login/logout).
  • Support multiple panels per 'edge' per monitor (12 panel positions per monitor: left/center/right * 4 sides)
  • Option to display only tasks on that monitor in the "Task Bar" panel item.
  • Margins per monitor.


Burner

The LXDE not have theyr hown burer, is important for burn folders for backsup, burn nows linux lived-dvd the actual xfburn is from xfce, and have a minimal dependences from thunar | posibilities:

  • Pôrt xfburn for using dependencis from lxde instead xfce4 dependencis
  • makin' from 0 (Cero) a new an sample (from folder, copy CD fom cdrom0 to cdrom1, and burn iso into cd)
  • port another burner gtk+
  • make a gui for a linux-command-line existent burner

See Also


Links