GSoC 2013 Ideas list
Introduction This page lists several ideas on how to improve the project.
We are currently in version 3.2, so these ideas target the version 3.3.
The project is clearly separated in 3 parts: core, plug-ins, and third-party applets, so each idea targets one of these parts.
The first 2 are written in C (C + + is possible for the KDE integration idea), the 3rd can accept any language (although Python mostly used).
See the documentation for complete details on the API, and Launchpad to access the code.
For more information on the GSoC, please see their wiki. You can of course contact us for any question.
If you wish to submit another idea or some suggestions, please post a message on the forum so that we can talk about it.
For each idea, the context is exposed, followed by the issue, followed by a possible solution. The language and the difficulty are also mentioned.
Translator The Translator applet currently uses Google Translate in an inefficient way: parsing the html result page.
This prevents it from being able to display the additional results, since they are not present in the html.
The idea is to use the Google Ajax API (which requires a key).
Alternatively, it would be nice to have a backend architecture, with another translation provider (for instance wordreference, which also has an API, or any other online translator).
The code is in Python, and using JSon is possible.
Difficulty level: 1
Calendar The Clock applet has a calendar feature, however it's quite limited. It supports the ical protocol, but only through a local file.
The idea is to integrate Google Calendar to the applet, or any other online calendar that has an API.
The applet is written in C and already has a backend architecture, which can be improved for the occasion.
An alternative is to write a complete new applet with any language.
Difficulty level: 2
KDE integration Currently the dock relies on GVFS to access the virtual file system.
However, gvfs is not used on KDE, which make sit necessary to install and run this additional daemon.
The idea is to write a KDE-integration plug-in on the same model as the Gnome and Xfce ones.
It should be able to list all partitions, mount/unmount volumes (included distant volumes like FTP and Samba, and encrypted volumes, which require the user to enter a password), get information on them, and react to any change (like a new volume connected).
It should use Qt, and the Qt main loop should be integrated with the GLib main loop.
Difficulty level: 2
Mint integration Currently the dock is well integrated in Gnome, XFCE, Unity, and partially KDE.
However, Mint is a popular distribution and uses its own shell.
The idea is to review the complete integration of the dock into Mint, from the installation to the daily usage, including a correct default theme, and all the usual interactions (showing the desktop, windows Exposé, desktops Exposé, session management, screensaver management, power management, getting the wallpaper, etc).
In case some interfaces are not standard (for instance with the Mate version), additional backends should be added.
Difficulty level: 1
Reduce the dependency to X The dock relies on X for several tasks.
However X will be superseded by Wayland in a near future.
The idea is to reduce from now the dependency to X.
There are several entry points:
- get a dynamic view of the existing windows
- react to the change of position, size and desktop of the windows, as well as the active window.
- get the desktop and screens properties (size, position, number of desktops) and react to any changes, currently done through Xrand
- get the resolution and be able to change it, currently done through Xrand
- get a thumbnail of a window (displayed in the dock when the window is hidden), currently done through GLX
- trigger a shorkey, , currently done through Xtst
- get the OpenGL visual, currently done through GLX and Xrender.
There are a lot of points, so of course one should pick one or two. They are listed in the order of difficulty, as much as we can assume.
In the perspective of integrating with Mir too, it could be nice to think of it in a general way, so a backend architecture will be needed.
Developing a generic backend and using it with X would already be a good achievement.
An interface to BAMF (Ubuntu) is one possible backend.
The language is of course C, and located in the core.
Difficulty level: 3
Logind integration Currently the Logout applet allows to log out of the session, and change the current user, by using ConsoleKit or GDM.
However, more and more distribution uses Systemd nowadays, and Logind to manage the user session.
The idea is to make the applet able to use Logind as well.
A backend architecture should be proposed for the occasion, and used for the 3 session managers.
The applet is developed in C and uses Dbus.
Difficulty level: 1
Writing a Javascript interface Currently the applet interface supports several languages: Python, Ruby, Mono, Vala, and even Bash.
The idea is to support Javascript as well, which would allows more developers to write third-party applets.
It should support the exact same things as the other interfaces, and be based on Dbus.
Difficulty level: 1 if you already know Javascript
Writing a third-party applet The Applet interface allows to quickly and easily write an applet for the dock.
Any idea on a third-party applet (using any language) is welcome.
It can be a smart launcher (like we have for Pidgin, Transmission, etc), or be a quick interface to a web or a service (like Translator, GTG, etc).
Difficulty level: 1 or 2 |
English
Online users :