|
|
![/!\](/gnome/gnome-responsive/img/dialog-warning-symbolic.png "/!\"){kind=small}
Students: Please read the notes on the Contents
1. General Info
It's important to note that this list is not exclusive: if you are a student and have an idea that is not listed in our pool of project ideas, don't hesitate to apply for your project. It's probably a good idea to ask people in the GNOME community if they think your idea is good, though. Also, if the development team is already working on something similar to your idea, they may be less likely to accept your proposal, so ask on the project's mailing list or IRC channel (lots of people lurk on IRC; don't be surprised if it takes an hour for your question to be answered, and don't just leave if nobody answers within five minutes!).
The ideas do not have to be only about modules that are in a GNOME suite. If it's a project on GNOME-related software that can benefit the GNOME community, it's also good to list it here.
When adding a project idea, please try to follow those guidelines:
- if you're interested in mentoring it, put your name. If not, then just leave it blank.
- do not list multiple idea with only one item. Use multiple items instead.
- briefly explain why this would be great for GNOME.
- do not write lots of text to explain your idea. If this is going to be long, maybe it's worth creating a page for it?
- make sure students who do not know much about all GNOME modules can understand the proposed idea.
please use this format, as it will be easier to get some information about tasks:
. '''task title''' (mentor: mentorname) * ''Benefits'': describe the benefits of your task * ''Requirements'': what should the student know already? * Note: one or multiple notes, links, whatever further information ----
|
2. Desktop
Please do not add your idea here directly; it will be triaged by administrators.
Hiding folders to the user: Content oriented Open/Save dialog (mentor: IvanFrade (tracker), somebody else with strong gtk background)
Benefits: Hide the concept of folder and filesystem to the user, showing an open dialog based on valid content types (depending on the application), last accessed time and tags.
Requirements: Gtk knowledge enough to write new widgets
- Note: This can require some extra bits besides the plain dialog, like a tagging widget or a lazy-loading model for tracker results. Detailed design spec required in proposal.
A fancy clutter based GUI for Cheese (mentor: DanielSiegel)
Benefits: Cheese should finally be able to show the effects in real time, add some new effects and a better usability
Requirements: Python or Vala, Clutter, gobject-introspection
A RDP plugin for Vinagre (mentor: JonhWendell)
Benefits: Vinagre will be able to connect into Windows machines, with no need to install a VNC server on remote machine. Also, they won't need to install additional software in the GNOME desktop to be able to connect to such machines.
Requirements: C, GTK+, GObject, overall understanding of RDP protocol (there are specs available)
Notes: Vinagre is the GNOME remote desktop viewer. Currently it's able to access other machines via VNC (graphical mode) and SSH (text mode). There is a big demand for RDP protocol. Nowadays people are using rdesktop to connect to Windows machines via RDP protocol (actually people use tsclient, which is just a frontend to rdesktop). So, one could grab the rdesktop code and port it into a Vinagre plugin. GNOME Bug. Also, I (JonhWendell) would mentor Vinagre and the overall thing, but I do not guarantee will mentor any RDP specific trick.
Widget layer for GNOME Shell (Mentor: GNOME Shell team, TBD)
- The current GNOME Shell sidebar is just a placeholder. This project would involve working with GNOME designers to come up with a better design, implementing that design, then implementing a number of widgets.
- (Because this project has a large impact on the GNOME Shell experience, successful applicants for this SOC will need to have a demonstrated track record of substantial contributions to the shell or to other open source projects.)
Improve GNOME Shell run dialog (Mentor: GNOME Shell team, TBD)
- The current GNOME Shell run dialog is basically just text entry field. This project would consist of working with the GNOME designers to come up with a more extensive design and implementing this. This would likely involve making the run dialog closer connected to the search entry in the overview "dash", to allow accessing other types of search results than applications, but might also involve power user features more along the lines of GNOME Do or Quicksilver.
GNOME Shell: Online integration (Mentor: GNOME Shell team, TBD)
- There are many ways that a user's online life should appear in the shell. This might include:
- Including documents from Google documents into recent documents
- Widgets that pull information from online service (calendars, TODO list from rememberthemmilk, etc)
- This project would involve figuring out a consistent way for the user to manage online accounts (possibly based on the online desktop accounts service, or on Mojito) implementing that and several specific usages of it.
New Clutter-based Screensavers (mentor: ThomasWood)
Benefits: Provide visually rich and interesting screensavers for GNOME using Clutter.
Requirements: Good knowledge of C. Comfortable using GObject and Clutter.
- Notes: Currently there are only a few basic screensavers shipped with GNOME. Possible Clutter based screensaver ideas include:
- Picture gallery with 3D and physics effects
- Cover art gallery
- Clock
- Feeds from social network sights such as Twitter
Zeitgeist: Libzeitgeist wrapper around DBus API (Mentor: Zeitgeist team, TBD)
- Implement a Library wrapping around the DBus API and Data model using C/Vala. Use GObject-Introspection for support of other Programing languages.
Benefits: Easier unified integration with Desktop Applications
Requirements: C, GObject, DBus and Python
- NOTE: The student will have to first write a ontology parser and the datamodel in C. Later he will have to rewrite the python-zeitgeist wrapper in C and add gobject introspection to it. The hard part is adding monitoring and subscription functionality to the library.
Zeitgeist: Implement Winepi and Minepi Algorithms (Mentor: Zeitgeist team, TBD)
- Zeitgeist logs the activities of a user and tries to figure our associated data over personal experience using algorithms such as "A Priori". However this is not suited for a journal log since it requires transactions, that up till now have been simulated. Winepi and Minepi algorithms are designed for finding association rules in data having no transactions. Enriching Zeitgeist with these algorithms would allow more stable and accurate results.
Benefits: Adding these algorithms to Zeitgeist would allow more accurate results, without the need to generate buckets.
Requirements: Python, DBus
NOTE: A good link to understand the issues and idea behind the need of the algorithms is http://en.wikipedia.org/wiki/Apriori_algorithm. It needs strong understanding for Algorithms.
GNOME Activity Journal: Integration of Firefox/Epiphany, Telepathy, Tomboy (Mentor: GNOME Activity Journal team, TBD)
- Zeitgeist now supports Firefox/Epiphany, Telepathy and Tomboy. GAJ is missing the design as well as the implementation to show these logs.
Benefits: Web activity, chatting, and note taking will be accessible over GAJ.
Requirements: Python, GTK, Cairo
- NOTE: This is more a design project than it is an implementation project. We had several difficulties coming up with a proper design. We need some initial mockups in the proposal
3. Media
Please do not add your idea here directly; it will be triaged by administrators.
Totem Markers/Chapters support (mentor: BastienNocera + GStreamer Mentor?) Benefits: would be used by GNOME Usability to facilitate the sharing of analysis done on usability sessions on video
Requirements: some GTK+ required, comfortable with learning GStreamer internals
Note: Mock-ups for the windowed version, CMML and Annodex for the markers' backend.
DACP support in Rhythmbox (mentors: Michael Petullo, Zeeshan Ali)
Benefits: integration with Apple's iPhone/iPod Touch Remote.app application, as well as Android
Requirements: Some GTK+, iPhone or iPod Touch for testing, Windows or MacOS X version of iTunes
- Note: the protocol is fairly well documented, but the pairing process isn't. The goal would be to create both client and server helpers, so that Rhythmbox can be used with the Remote.app, or the Android equivalent, and that iTunes can be controlled with a proof-of-concept GTK+ application. It would also be possible to bridge the support through UPnP to control other applications or devices).
Totem as a UPnP/DLNA MediaRenderer (mentor: ZeeshanAli)
Benefits: User will be able to use a UPnP control point (e.g gupnp-av-cp) to remotely control totem in her home network.
Requirements: C, Vala, D-Bus
Note: There will be two parts of this project: 1. To complete Rygel's MediaRenderer D-Bus spec and implement the consumer side in Rygel. 2. Totem plugin that implements the spec.
Totem and Rhythmbox plugins for consuming media content provided by Rygel's Media Server Spec providers, and Grilo plugin for Eye of GNOME (mentor: IagoToral, JuanSuarez, ZeeshanAli)
Benefits: It would allow Totem And Rhythmbox to consume media content exposed over D-Bus by applications implementing the provider side of Rygel's Media Server specification (see MediaServerSpec for details). Currently Grilo is implementing this provider interface and is exposing content from various services (Youtube, SHOUTcast, Jamendo and others), so implementing these plugins would allow these applications to access content from those services (and other services that will be implemented in the future in Grilo or other applications that implement the Media Server Specification).
Benefits: It would allow developers to write plugins for eog that would let users to browse and retrieve images provided by other services. It would also provide a plugin implementing this interface using Grilo, which would allow eog users to access and browse images from flickr (there is a flickr plugin for Grilo, but more could come).
Requirements: C, GTK+
Note: Grilo is a framework focused on making media discovery and browsing easy for application developers. Rygel is a UPnP/DLNA media server. The Grilo project is working on frontend libraries to ease the development of consumers of Rygel's Media Server Specification, these libraries would be used in the implementation of these plugins.
Banshee - Customisable browser (mentor: AlexanderKojevnikov)
Benefits: Powerful browser for effortless music library navigation
Requirements: C#, GTK#
- Note: see bgo#540873 and its numerous duplicates. The following has already been suggested:
- Add the genre filter
- Show artists or album artists
- Composers and conductors filter
- Option to show the year next to the albums
- Option to sort the albums by album name, artist name or year
4. Sharing & Collaboration
Please do not add your idea here directly; it will be triaged by administrators.
- Collaboration server/client (aka Dropbox replacement) (mentor: SaleemAbdulrasool)
Benefits: would allow design/art people to easily share on-going work
Requirements: Some web services development, working with the GNOME sysadmin team, GTK+
Note: Some explanations, Mockups. Using git, or WebDAV on the servers are possibilities, so the current GNOME infrastructure is reused to the maximum.
Gedit/Gobby collaboration via Telepathy (mentor: JesseVanDenKieboom & Telepathy dev?)
Benefits: Allow user to edit collaboratively document with their contacts
Requirements: C, Gedit, Telepathy, d-bus
Note: This would be to continue the work done by jessevdk to integrate libinfinity in gedit to have it use Telepathy Tubes
Note: 18:12 < jessevdk> I can see 3 main parts to the project:
Note: 18:12 < jessevdk> 1) implement/provide/contribute some gtk+ widgets for telepathy (accounts list, etc.)
Note: 18:13 < jessevdk> 2) implement an internal infinote daemon running inside gedit sharing the open documents of a window
Note: 18:13 < jessevdk> 3) implement the telepathy stuff setting up the connection/stream tubes, etc.
Rich Tomboy Note Sharing Via Telepathy (mentor: SandyArmstrong, OlivierLeThanh)
Benefits: Allow users to grant each other access to browse all or part of their Tomboy note collection.
Requirements: C#, GTK#, experience with Telepathy APIs, UI design skills
Notes:
- Mentor is expecting a baby this summer, so your proposal needs to have a rock-solid plan and timeline to convince him that you can do this without constant supervision.
- UI mockups would be a very helpful addition to your proposal. Current assumption is that contact browsing would happen in the Search All Notes window, but we're willing to have that assumption challenged.
- You should already have discussed with Telepathy devs how this might be implemented, and have some technical details prepared in your proposal.
- Evidence of Telepathy-related patches would be very helpful.
- Any ideas for collaboration would be very welcome, but be realistic in your timeline. Full Gobby-style collaborative note editing is probably out-of-scope for now, but if you have some clear ideas for how to share edits to a single note between different users, that would be a great addition to your proposal.
5. Web
Please do not add your idea here directly; it will be triaged by administrators.
Front-end for common web services (mentor: ?)
Benefits: would allow Open Source/GNOME applications access to the services that might not be available to Open Source applications
Requirements: Some web services development, working with the GNOME sysadmin team
- Note: Amazon Web Services requires a 'secret' key, which means Open Source applications cannot ship with the key included. The web service would allow access to this service, whilst keeping the key private. The web service could also be used to unite common APIs under one roof (eg. Cover art discovery where adding/removing support for specific services would be done on the server, rather than in all the front-end applications)
- The feature would be extended beyond just cover art searches, and could include lyrics searches, acting as an aggregator for each type of data requested
Getting Things GNOME! integration with online services (mentor: Lionel Dricot)
Benefits: flexibility, integration, easy transition to GTG, tons of added appeal for GTG
Requirements: python, bazaar, gtk-builder, familiarity with GTG
Note: see an overview
Add Social Features to Snowy (Tomboy Online) (mentor: SandyArmstrong)
Benefits: Make it easy to connect with other Snowy users, and view their latest (public) notes. Allow users to share certain notes with certain users. Expose this information in web views, and also in the REST API for use by rich clients like Tomboy.
Requirements: python, django, XHTML, CSS, unit testing, understanding of web app security
Notes:
- Mentor is expecting a baby this summer, so your proposal needs to have a rock-solid plan and timeline to convince him that you can do this without constant supervision.
- Thorough unit tests and security verification will be needed to successfully complete this project.
- Must have evidence of patches to Snowy or other django-based projects.
- UI mockups would be helpful.
6. Developer
Please do not add your idea here directly; it will be triaged by administrators.
BuilDj: A build definition format for GNOME (mentor: AlbertoRuiz)
Benefits: would easy the entry barrier to create GNOME projects, improve the integration with IDEs of those projects and make maintainers life a lot easier as well. It also has the potential to allow the link/aggregation several targets from different tarballs/repos together.
Requirements: Python is a must and knowledge on building C/C++ software desirable, familiar with cross compiling issues is a plus but not mandatory
Snippets plugin for Anjuta (mentor: JohannesSchmid or TBA)
Benefits: Having a snippets plugin is in general nice to have when editing code
Requirements: C/GObject knowledge
- Note: The snippets plugin should make it easy to add code snippets with parameters using the code completion infrastructure already in place. It should also have a new interface for defining new snippets. The current macro plugin can be used as base if useful.
- Addition: Would be cool to integrate this will some code example engine such as the user can search for a common action (e.g. "Open and read a file") and he will be pointed to some template code doing exactly this.
Anjuta online integration (mentor: JohannesSchmid)
Benefits: Make it easier to start hacking on projects using anjuta
Requirements: C/GObject, some knowledge on web services
- Note: The goals are at least two:
- Implement a file format that can be used on website for one-click start with anjuta with a label like "Start hacking (in anjuta)". It will automatically import the project from the vcs, import it in anjuta and install all development dependencies using package-kit.
- Integrate with bugzilla in a way that patches can be automatically attached and commits can trigger certain actions (close bugs, add comment, etc.). This should at least work for GNOME Bugzilla while other bugzilla or launchpad would be cool of course.
see also Anjuta/Roadmap
libGTracker: High level GObject-friendly library to use tracker (mentor: IvanFrade (tracker))
Benefits: GNOME-style API to access tracker hiding the messy bits (dbus connection, results retrieval, signals on changes) to the programmer, avoiding duplicated code.
Requirements: Deep knowledge of Vala, SparQL.
Note: This library can be integrated with the data model, and can include the developing of a TrackerTreeModel
Allow dockable debugging widgets in the Nemiver Debugger (mentors: DodjiSeketeli, JonathonJongsma)
Benefits: Better use of the debugger screen real estate
Requirements: C++ and maybe some GTKMM knowledge.
- Note: The existing debugging widgets like call stack, variable inspector will
be reused and managed by the GNOME Docking Library
- This is purely a user interface task and does not involve touching the debugging back-end. On the other hand, it's one of the most demanded feature of the Debugger. It's thus an opportunity to have a big impact on users.
Enhance the operation of GNOME Shell LookingGlass (Mentor: GNOME Shell team, TBD)
LookingGlass is the debugging console built into GnomeShell, similar to FireBug.
- Add support for seeing which CSS rules apply to an element, and changing them. Potentially allow saving the changes back to the CSS file.
- Some sort of integration with gedit or Anjuta to allow jumping between the user interface and the code
GNOME Shell: Latency and IO bound operations (Mentor: GNOME Shell team, TBD)
- Since the GNOME Shell is the desktop compositor, any latency in GNOME SHell, because of IO or other causes will affect the overall experience of the shell. This project would involve:
- Adding instrumentation to the shell to measure the maximum latency
- Figuring out how to detect blocking IO being done in the main GNOME Shell thread, and creating ways of visualizing specific offenders
7. Other Ideas
(These ideas are for GNOME-related projects. They have not been evaluated by the GNOME SoC Admins.)
7.1. For GNOME-related projects
Unless otherwise noted, you may make proposals related to these projects with GNOME as your mentor organization. GNOME will seriously consider applications to work on projects that are relevant to GNOME since this will help improve the user experience.
- add a link here