Sure, there are some tweaks to be made. Epiphany's rollover to Webkit is almost finished, and GTK+ Webkit passed ACID3, but Gnome is still looking to unify the bookmark and history underpinnings. Telepathy is still on track to take over the communications layer the way GStreamer took the A/V part. On the whole, though, the roadmap for Gnome 2.24 is really tame.
- Better GNOME Panel theming
- Integration of Bookmarks and Browsing History for GNOME-wide access (SoC Project 2007, unfinished and suggested for SoC2008)
- Exchange MAPI Connector (Can connect to MS Exchange 2007 servers)
- Camel DB Summary (Drastically reduce Evolution memory)
- Use libgames-support on Python games
- User interface for choosing layouts not only per-country but also per-language
- New library for the applets
- Compatibility layer for old Bonobo applets and remove Bonobo usage in the Panel
- New interaction model for managing applets: activate/deactivate an applet instead of adding/removing it, eg. Possibly, a mode for editing the panel contents
- Managing of gnome-keyring certificates and keys.
- Evolution encryption integration (e-d-s integration, auto-contact creation, photo ID synchronization)
- Pidgin/Telepathy (Gossip, etc) encryption plugin
- Digitally signed documents in Evince
- Support for reverse connections
- Support for connection logging
Some of the stuff in SoC2008 looks really interesting, but that's not often completed if we look at it historically. The stuff that stands out to me are the sweeping changes aimed at integrating low-level stuff. The Telepathy work looks great. The movement of Cheese effects into a library so that any Gnome application can ask for a video or a picture, or apply the effects to a picture the app already has. The inclusion of DPAP, which would do for F-Spot what DAAP did for Rhythmbox. I'm especially looking at Soylent on this one, though they need to change the name -- yes, I understand that it's made of people! The continuing move to link Gnome to online services is also a great move, and Liferea hooking up with Google reader would be one more step in that process, though I can't imagine actually using it.
On the developers side, the Anjuta work, long a great IDE in Gnome, is really important to the long-term development og Gnome. If Vala proves itself as great as it seems, things will be even better and Gnome can move away from Mono.
As I pointed out in the beginning of this post, though, few of the SoC projects are planned for Gnome 2.24, and not many appear on the "Later Versions" list, either. We'll see if Gnome has basically reached its zenith.
The full list of SoC2008 Gnome projects and descriptions is below.
by Ruben Vermeersch, mentored by Stephane Delcroix
NOTE: This proposal is an updated version of the F-Spot Gegl proposal
[1], retargeted towards visible usability work.
The F-Spot sidebar currently acts as a tag browser, with some minimal
image information. I would like to change the behavior of this to a more
versatile design, where the sidebar can perform multiple actions
depending on the context. This would allow integration of an image
information pane, editing commands, external sources, ... This is based
on jimmac's mockups [2].
One of the main problems I would like to address is the poor usability
of the editing toolbar near the bottom of the Edit Image view. Turning
this view into a sidebar pane, like Picasa would increase
discoverability of the editing commands.
As a side goal, it should become far easier to add new editing commands
through plugins. I will convert the editor commands to use F-Spot's
plugin architecture.
Ongoing work can be found in the form of a first-draft patch [3]. As
such, the first step would be to review and integrate this patch. This
will serve as a starting point towards improving the usability of
F-Spot. I will focus on the editors first, but I would also like to
improve the image information display.
NOTE: This proposal is an updated version of the F-Spot Gegl proposal
[1], retargeted towards visible usability work.
The F-Spot sidebar currently acts as a tag browser, with some minimal
image information. I would like to change the behavior of this to a more
versatile design, where the sidebar can perform multiple actions
depending on the context. This would allow integration of an image
information pane, editing commands, external sources, ... This is based
on jimmac's mockups [2].
One of the main problems I would like to address is the poor usability
of the editing toolbar near the bottom of the Edit Image view. Turning
this view into a sidebar pane, like Picasa would increase
discoverability of the editing commands.
As a side goal, it should become far easier to add new editing commands
through plugins. I will convert the editor commands to use F-Spot's
plugin architecture.
Ongoing work can be found in the form of a first-draft patch [3]. As
such, the first step would be to review and integrate this patch. This
will serve as a starting point towards improving the usability of
F-Spot. I will focus on the editors first, but I would also like to
improve the image information display.
by Arnold Joseph Noronha, mentored by Lars Lindner
Liferea is a fantastic Feed Reader written in Gtk+. Its lightweight, yet has lots of features. Its not officially part of the Gnome project, but is very related to Gnome -- probably the most well integrated reader for Gnome. I propose to integrate Liferea with Google Reader.
Use Case 1: Most people use their computer from multiple locations, and would like to synchronize their reading lists. Using Google reader to maintain the synchronized list, is a very ideal situation. Consider this: at home, you'd like the convenience of a well integrated, lightweight feed reader. At office, you might not be able to install new software, so a web based reader suits you pretty well.
Use Case 2: Apart from that, using Google Reader as a backend can save bandwidth, and minimize total update time: since now I need to act only if Google tells me a post is updated. In fact downloading a single stream from the Google Reader backend will tell me which are the feeds that have been updated, and what the changes are. Compare this to current readers, where if I have hundred blogs on my reading list, each one needs to be fetched, even if some of them are updated rarely. After my project, every update of all of these hundred feeds will make _exactly one download_ !
Use Case 3: Also, many people including myself, like the "Share a post" feature of Google reader. I would like to be told when a friend of mine shares a post, and would also like to share posts that I read.
Liferea currently has read-only support for Google reader. This means I can't update the "Read" status for a post.
My approach as to how to "integrate" Google Reader, is different and elegant, and I'm really hoping you will consider my project.
Liferea is a fantastic Feed Reader written in Gtk+. Its lightweight, yet has lots of features. Its not officially part of the Gnome project, but is very related to Gnome -- probably the most well integrated reader for Gnome. I propose to integrate Liferea with Google Reader.
Use Case 1: Most people use their computer from multiple locations, and would like to synchronize their reading lists. Using Google reader to maintain the synchronized list, is a very ideal situation. Consider this: at home, you'd like the convenience of a well integrated, lightweight feed reader. At office, you might not be able to install new software, so a web based reader suits you pretty well.
Use Case 2: Apart from that, using Google Reader as a backend can save bandwidth, and minimize total update time: since now I need to act only if Google tells me a post is updated. In fact downloading a single stream from the Google Reader backend will tell me which are the feeds that have been updated, and what the changes are. Compare this to current readers, where if I have hundred blogs on my reading list, each one needs to be fetched, even if some of them are updated rarely. After my project, every update of all of these hundred feeds will make _exactly one download_ !
Use Case 3: Also, many people including myself, like the "Share a post" feature of Google reader. I would like to be told when a friend of mine shares a post, and would also like to share posts that I read.
Liferea currently has read-only support for Google reader. This means I can't update the "Read" status for a post.
My approach as to how to "integrate" Google Reader, is different and elegant, and I'm really hoping you will consider my project.
by Tobias Mueller, mentored by SrinivasaRagavan
This application proposes the rewrite of Evolutions Account Management.
Right now, it saves XML in GConf and doesn't such all it's features such as caching or notifying. Also, accounts for calender or addressbooks are not handled by the e-d-s yet.
I am going to rewrite this and try to provide a nice control applet for the accounts.
This application proposes the rewrite of Evolutions Account Management.
Right now, it saves XML in GConf and doesn't such all it's features such as caching or notifying. Also, accounts for calender or addressbooks are not handled by the e-d-s yet.
I am going to rewrite this and try to provide a nice control applet for the accounts.
by John Ross Stowers, mentored by John Carr
Synchronization of data with mobile devices is a capability severely lacking in the current GNOME desktop. This project will implement synchronization of PIM data such as emails, contacts and calendar data, with mobile devices, predominately mobile phones.
The implementation will be atop Conduit [1], using the SyncML protocol (through libsyncml [2]). The project will have two primary tasks of work,
1. Binding the libsyncml library to allow it to be called from Python and implementing a SyncML server and client in Conduit using this binding.
2. Utilizing this new capability within Conduit to allow PIM (contact,calendar and email data) sync from Evolution to/from mobile phones.
All this shall be done in the current spirit of Conduit, which is to require minimal, or zero, user-intervention in setting up a sync.
[1] http://www.conduit-project.org
[2] http://libsyncml.opensync.org/
Synchronization of data with mobile devices is a capability severely lacking in the current GNOME desktop. This project will implement synchronization of PIM data such as emails, contacts and calendar data, with mobile devices, predominately mobile phones.
The implementation will be atop Conduit [1], using the SyncML protocol (through libsyncml [2]). The project will have two primary tasks of work,
1. Binding the libsyncml library to allow it to be called from Python and implementing a SyncML server and client in Conduit using this binding.
2. Utilizing this new capability within Conduit to allow PIM (contact,calendar and email data) sync from Evolution to/from mobile phones.
All this shall be done in the current spirit of Conduit, which is to require minimal, or zero, user-intervention in setting up a sync.
[1] http://www.conduit-project.org
[2] http://libsyncml.opensync.org/
by Arun Tejasvi Chaganty, mentored by Johannes Schmid
Anjuta is a very powerful development environment because of its tight
integration with other tools (like GDB, Valgrind, autotools). Vim is just as
powerful of an editor, however for the most part it remains isolated from the
rest of the development cycle, solely satisfying the role of an editor. I
propose to embed a gvim editor into Anjuta to get the best of both worlds.
Essentially, this means the implementation of the IAnjutaEditor interface,
however, because of the nature of gVim several other aspects have to be
considered:
1. The gVim editor has to grab all the keyboard events because of it's modal
interface. Support for switching in and out of the editor must be
implemented.
2. Vim has a lot of complex commands for selection, movements, deletion etc.
This makes the implementation of the interface slightly more complicated.
3. Unlike other editors, where commands to navigate between open files,
creating/opening files, etc. are separable, in vim they are a part of the
editor. This means that there has to be a way for vim to tell Anjuta that
it's changing files, etc. This will be the most complex part of the project.
Also in the scope of the project is to create functions in vim so that it can
control some of Anjuta's features (build, start debugging, create to-do notes).
Anjuta is a very powerful development environment because of its tight
integration with other tools (like GDB, Valgrind, autotools). Vim is just as
powerful of an editor, however for the most part it remains isolated from the
rest of the development cycle, solely satisfying the role of an editor. I
propose to embed a gvim editor into Anjuta to get the best of both worlds.
Essentially, this means the implementation of the IAnjutaEditor interface,
however, because of the nature of gVim several other aspects have to be
considered:
1. The gVim editor has to grab all the keyboard events because of it's modal
interface. Support for switching in and out of the editor must be
implemented.
2. Vim has a lot of complex commands for selection, movements, deletion etc.
This makes the implementation of the interface slightly more complicated.
3. Unlike other editors, where commands to navigate between open files,
creating/opening files, etc. are separable, in vim they are a part of the
editor. This means that there has to be a way for vim to tell Anjuta that
it's changing files, etc. This will be the most complex part of the project.
Also in the scope of the project is to create functions in vim so that it can
control some of Anjuta's features (build, start debugging, create to-do notes).
by Felix Kaser, mentored by Daniel Siegel
One of the things that the GNOME Desktop lacks to appear as an integrated and cohesive Desktop Environment, compared to e.g. Mac OSX, is the lack of a deep media integration across the Desktop.
Deep media integration means the user should be able to access his documents and media files from the GtkFileChooser without being forced to remember where he saved his files, and should be able to query for files not only by their paths/URIs, but also by their metadata (e.g. ID3 tags for music files, EXIF information for photos and so on) and by the last access it was done to the file (though this is possible, in a quite generic way, with the GtkRecentManager tools).
GtkMediaManager wants to solve this problem introducing an API to query, browse and tag files across the desktop, providing on one side, media listing in the GtkFileChooser with a queriable interface, and on the other side, a simple API for other applications to hook their files and relevant metadata inside the manager.
GtkMediaManager will be written in C and will use either use Xesam or plugins for application-specific database to query and store information and metadata about the media files. It will also be integrated with the GtkFileChooser, providing a set of widgets to easily query by attributes depending on the file type we want, and it finally will be integrated with GtkRecentManager, which will provide GtkMediaManager information about the files recently used by media applications.
One of the things that the GNOME Desktop lacks to appear as an integrated and cohesive Desktop Environment, compared to e.g. Mac OSX, is the lack of a deep media integration across the Desktop.
Deep media integration means the user should be able to access his documents and media files from the GtkFileChooser without being forced to remember where he saved his files, and should be able to query for files not only by their paths/URIs, but also by their metadata (e.g. ID3 tags for music files, EXIF information for photos and so on) and by the last access it was done to the file (though this is possible, in a quite generic way, with the GtkRecentManager tools).
GtkMediaManager wants to solve this problem introducing an API to query, browse and tag files across the desktop, providing on one side, media listing in the GtkFileChooser with a queriable interface, and on the other side, a simple API for other applications to hook their files and relevant metadata inside the manager.
GtkMediaManager will be written in C and will use either use Xesam or plugins for application-specific database to query and store information and metadata about the media files. It will also be integrated with the GtkFileChooser, providing a set of widgets to easily query by attributes depending on the file type we want, and it finally will be integrated with GtkRecentManager, which will provide GtkMediaManager information about the files recently used by media applications.
by Johan Svedberg, mentored by Diego Escalante Urrelo
In todays Internet-centric computing with highspeed connections becoming
the standard everywhere, the task of downloading large files is more
common than ever. This is where a download manager comes in. It assists
the user by making this task an easy and efficient experience.
Unfortunately GNOME currently lacks the type of modern download manager
which can be found in other desktop environments. I think it would be
very nice if we could fill this hole during the summer of 2008! So in
this application I will describe how I would organize the project of
implementing a download manager for GNOME.
In todays Internet-centric computing with highspeed connections becoming
the standard everywhere, the task of downloading large files is more
common than ever. This is where a download manager comes in. It assists
the user by making this task an easy and efficient experience.
Unfortunately GNOME currently lacks the type of modern download manager
which can be found in other desktop environments. I think it would be
very nice if we could fill this hole during the summer of 2008! So in
this application I will describe how I would organize the project of
implementing a download manager for GNOME.
by James R. Liggett, mentored by Naba Kumar
Since its introduction in 2005, the Git revision control system has become increasingly popular, especially with large projects. However, it is also a very complex system with myriad options and controls; many developers often find themselves perplexed by Git's approach to managing source code. While there are several GUI tools designed help users overcome some of these challenges and simplify a Git user's workflow, most are stand-alone applications that only support the simplest tasks, such as browsing revision history. Also, there are only a few IDE's that provide Git integration.
The goal of this project is to provide a simple to use interface, usable to both new and experienced users alike. The finished plugin will provide the most commonly used git features for project contributors, all integrated into the same application that they write their code with. Such a close integration will allow the user to work on these tasks without any disruption to existing coding workflows with nothing more than a few clicks for most tasks.
Since its introduction in 2005, the Git revision control system has become increasingly popular, especially with large projects. However, it is also a very complex system with myriad options and controls; many developers often find themselves perplexed by Git's approach to managing source code. While there are several GUI tools designed help users overcome some of these challenges and simplify a Git user's workflow, most are stand-alone applications that only support the simplest tasks, such as browsing revision history. Also, there are only a few IDE's that provide Git integration.
The goal of this project is to provide a simple to use interface, usable to both new and experienced users alike. The finished plugin will provide the most commonly used git features for project contributors, all integrated into the same application that they write their code with. Such a close integration will allow the user to work on these tasks without any disruption to existing coding workflows with nothing more than a few clicks for most tasks.
by William Fagan, mentored by Johannes Schmid
Source control is a mandatory tool in the open source community allowing people from around the world to work together. One of the biggest problems with new developers starting a project is getting it set up to share with the world. If Anjuta could get rid of the barrier that all of the different VCS programs brought on by adding intuitive use for the new developers we could start to see many more projects come about that most users were too timid to start.
Source control is a mandatory tool in the open source community allowing people from around the world to work together. One of the biggest problems with new developers starting a project is getting it set up to share with the world. If Anjuta could get rid of the barrier that all of the different VCS programs brought on by adding intuitive use for the new developers we could start to see many more projects come about that most users were too timid to start.
by Andrzej Wytyczak-Partyka, mentored by Gabriel Burt
The contribution of this project is a dpap-sharp library and and f-spot add-in for sharing photo albums over a network between instances of f-spot and Apple iPhoto (c) using the Digital Photo Access Protocol (DPAP).
The library is an equivalent of the daap-sharp library which is already used by Banshee & others. It is important that the produced library is not only intented for work with f-spot, but with any other desktop program.
The contribution of this project is a dpap-sharp library and and f-spot add-in for sharing photo albums over a network between instances of f-spot and Apple iPhoto (c) using the Digital Photo Access Protocol (DPAP).
The library is an equivalent of the daap-sharp library which is already used by Banshee & others. It is important that the produced library is not only intented for work with f-spot, but with any other desktop program.
by Sebastian Pölsterl, mentored by Zaheer Abbas Merali
Something that annoyed me for years is that there isn't a simple way to watch and record TV shows using GNOME. Since Totem 2.22 there's at least a way to watch TV when all the steps necessary to set it up have been completed. You have to tell Totem which DVB card to use (when you have multiple) and create a list of channels manually using dvb-utils from the command line and put the file in the right place. Even though it's possible to watch TV there's no way to easily browse and search EPG and record TV shows.
I want to simplify the process of setting up your DVB card and recording TV shows, and provide a way that other applications can easily make use of this features, too.
This would require a daemon that runs in the background and manages your DVB card(s) and their data. It detects your DVB cards, scans them for channels, stores the list of channels, provides access to EPG and is responsible for recording TV shows. When you want to record a TV show it should check if it conflicts with another scheduled recording and warn the user or solve the issue when an additional DVB card is available that is not already busy at this time. Of course, when the TV show starts it should tune to the correct channel, too.
In order to make this feature accessible by other applications, a D-Bus interface would be the interface to the outside world. Using D-Bus has the advantage that you can choose from a set of programming languages to write a client application in, because D-Bus libraries for the most common languages are available.
Beside the daemon I want to provide a GUI application that the user can actually use to setup his cards and schedule recordings. This could be a independent application or a plug-in for Totem. Using EPG you could show a list of channels and their corresponding schedules. Clicking on a show should show you detailed information about the show (from EPG) and provide a way to record this particular show (similar to [2]). In addition, a really nice feature would be that you can search EPG or let the daemon record all TV shows, whose EPG data contains a particular keyword.
An other application that can take advantage of the the daemon is the OnTV applet[1]. It would be a easy way to get informed what's up next, get a list of scheduled recordings and schedule recordings. Again, D-Bus should make it simple.
I think there are many more ways to improve your TV experience in this fields (e.g. automatically re-encode recordings to save disk space). Therefore, it may make sense to equip the daemon with a plug-in interface, as well.
Nevertheless, from a user's point of view it should be as easy and intuitive as possible to do the basic steps from setting up the DVB card(s) to recording shows. This would finally make my dream of a GNOME application that let's you watch and record TV come true.
Without doubt many people would profit from this project, because doing all this steps manually is really cumbersome and discourages most people. An easy, straightforward way would improve the GNOME experience a lot.
I'm aware that this project is very big, but I'm convinced that it's possible to get the daemon and a first UI application working until the final deadline. In addition, I'm willing to start working on the project before the coding phase officially begins.
[1]: http://johan.svedberg.com/projects/coding/ontv/
[2]: http://jaganath.files.wordpress.com/2006/12/guide.PNG
Something that annoyed me for years is that there isn't a simple way to watch and record TV shows using GNOME. Since Totem 2.22 there's at least a way to watch TV when all the steps necessary to set it up have been completed. You have to tell Totem which DVB card to use (when you have multiple) and create a list of channels manually using dvb-utils from the command line and put the file in the right place. Even though it's possible to watch TV there's no way to easily browse and search EPG and record TV shows.
I want to simplify the process of setting up your DVB card and recording TV shows, and provide a way that other applications can easily make use of this features, too.
This would require a daemon that runs in the background and manages your DVB card(s) and their data. It detects your DVB cards, scans them for channels, stores the list of channels, provides access to EPG and is responsible for recording TV shows. When you want to record a TV show it should check if it conflicts with another scheduled recording and warn the user or solve the issue when an additional DVB card is available that is not already busy at this time. Of course, when the TV show starts it should tune to the correct channel, too.
In order to make this feature accessible by other applications, a D-Bus interface would be the interface to the outside world. Using D-Bus has the advantage that you can choose from a set of programming languages to write a client application in, because D-Bus libraries for the most common languages are available.
Beside the daemon I want to provide a GUI application that the user can actually use to setup his cards and schedule recordings. This could be a independent application or a plug-in for Totem. Using EPG you could show a list of channels and their corresponding schedules. Clicking on a show should show you detailed information about the show (from EPG) and provide a way to record this particular show (similar to [2]). In addition, a really nice feature would be that you can search EPG or let the daemon record all TV shows, whose EPG data contains a particular keyword.
An other application that can take advantage of the the daemon is the OnTV applet[1]. It would be a easy way to get informed what's up next, get a list of scheduled recordings and schedule recordings. Again, D-Bus should make it simple.
I think there are many more ways to improve your TV experience in this fields (e.g. automatically re-encode recordings to save disk space). Therefore, it may make sense to equip the daemon with a plug-in interface, as well.
Nevertheless, from a user's point of view it should be as easy and intuitive as possible to do the basic steps from setting up the DVB card(s) to recording shows. This would finally make my dream of a GNOME application that let's you watch and record TV come true.
Without doubt many people would profit from this project, because doing all this steps manually is really cumbersome and discourages most people. An easy, straightforward way would improve the GNOME experience a lot.
I'm aware that this project is very big, but I'm convinced that it's possible to get the daemon and a first UI application working until the final deadline. In addition, I'm willing to start working on the project before the coding phase officially begins.
[1]: http://johan.svedberg.com/projects/coding/ontv/
[2]: http://jaganath.files.wordpress.com/2006/12/guide.PNG
by Stanislav Slušný, mentored by Federico Mena-Quintero
There have been several complaints about memory consumption and speed of Evolution Data (EDS) server recently. Some developers even attempted to completely rewrite it. The ultimate goal is to measure EDS performance, reduce its memory usage and make it faster. The focus will be given to its calendar part. This subtasks will lead to the goal:
* Implementation of interval trees. More effective data structure will improve both speed and memory usage. Now, when searching for events in some time range, all events are scanned. Even really old ones. The better data organization is needed.
* Implementation of logging facility, which allows evaluation of the performance and memory analysis. The data and logs from community will be gathered.
* Analysis of calendar queries and their lifetime.
* Design and implementation of typical scenarios, which will be used to measure both speed and memory usage.
* Performance and memory profiling. Even developers are using rather vague language like "EDS consumes too much memory" now. Careful statistics will be gathered.
* Performance measurement of EDS cache. Every EDS client uses the cache, even clock applet. There have been suggestions, that the cache should be removed. Performance evaluation and optimization will be carried out.
* The results will be processed and presented in a understandable way to the community. Patches, that will fix most serious findings will be prepared.
Electronic calendars are becoming more and more popular these days. As EDS was written during the early days of Evolution, it needs some optimization to make calendar experience as smooth as possible. Currently, EDS has a reputation of process, that consumes too much memory. Software has a rich history of people spending large chunks of their life optimizing things that don't matter. Therefore, before implementing any changes, the profiling process will be carried out.
* Implementation of interval trees. More effective data structure will improve both speed and memory usage. Now, when searching for events in some time range, all events are scanned. Even really old ones. The better data organization is needed.
* Implementation of logging facility, which allows evaluation of the performance and memory analysis. The data and logs from community will be gathered.
* Analysis of calendar queries and their lifetime.
* Design and implementation of typical scenarios, which will be used to measure both speed and memory usage.
* Performance and memory profiling. Even developers are using rather vague language like "EDS consumes too much memory" now. Careful statistics will be gathered.
* Performance measurement of EDS cache. Every EDS client uses the cache, even clock applet. There have been suggestions, that the cache should be removed. Performance evaluation and optimization will be carried out.
* The results will be processed and presented in a understandable way to the community. Patches, that will fix most serious findings will be prepared.
Electronic calendars are becoming more and more popular these days. As EDS was written during the early days of Evolution, it needs some optimization to make calendar experience as smooth as possible. Currently, EDS has a reputation of process, that consumes too much memory. Software has a rich history of people spending large chunks of their life optimizing things that don't matter. Therefore, before implementing any changes, the profiling process will be carried out.
by Corvalan Cornejo Gabriel, mentored by Olivier Crête
The Telepathy project is building a unified framework for many different kinds of real-time communications. It uses the D-Bus messaging system to provide a simple interface for client applications.
Empathy is working on creating a nice user interface based on the Telepathy backend. This project aims to provide to GNOME its own Instant Messenger featuring voice calls and video calls (VoIP).
I want to develop around the VoIP protocol used in Telepathy / Empathy. Especially, improving the video conference feature. To achieve that, some improvement must be done in the core of the stream process (using Libstream-engine and Gstreamer) and in the user interface (Empathy). The objective of this project is to have a fonctional interface for audio/video conference, maybe like the Ichat from Mac OSX)
Empathy is working on creating a nice user interface based on the Telepathy backend. This project aims to provide to GNOME its own Instant Messenger featuring voice calls and video calls (VoIP).
I want to develop around the VoIP protocol used in Telepathy / Empathy. Especially, improving the video conference feature. To achieve that, some improvement must be done in the core of the stream process (using Libstream-engine and Gstreamer) and in the user interface (Empathy). The objective of this project is to have a fonctional interface for audio/video conference, maybe like the Ichat from Mac OSX)
by Pavel Kostyuchenko, mentored by Johannes Schmid
The ultimate goal of my project is to integrate Anjuta with Glade and some other technologies, add some new features related to those technologies, making a good RAD tool from Anjuta.
IMHO, the most important for RAD part of Anjuta is GUI designer i.e Glade. So, the main thing I'm going to do is to complete integration of Anjuta and Glade. The key points of integration are:
- create stubs with appropriate prototype for new signals;
- navigate to the implementation of the signal on signal selection or custom action and from the implementation to the corresponding object;
- allow user to choose an existent callback function with appropriate prototype for signal;
- manage additional files that user may add via Glade;
- track widgets names and rename callback functions and names in the get_object calls;
- make it all language-independent;
- module preview. It is similar to the preview in many GUI designers with one big difference: not only GUI is used to do preview but also code. It is more likely a programming technique than IDE feature but IDE could make thing simplier and faster;
- autocomplete in the editor using widgets names e.g. to insert "gtk_builder_get_object(, "widgetname")" into code;
- templates library of modules (GUI + code), including custom modules with ability to "inherit" the module.
The ultimate goal of my project is to integrate Anjuta with Glade and some other technologies, add some new features related to those technologies, making a good RAD tool from Anjuta.
IMHO, the most important for RAD part of Anjuta is GUI designer i.e Glade. So, the main thing I'm going to do is to complete integration of Anjuta and Glade. The key points of integration are:
- create stubs with appropriate prototype for new signals;
- navigate to the implementation of the signal on signal selection or custom action and from the implementation to the corresponding object;
- allow user to choose an existent callback function with appropriate prototype for signal;
- manage additional files that user may add via Glade;
- track widgets names and rename callback functions and names in the get_object calls;
- make it all language-independent;
- module preview. It is similar to the preview in many GUI designers with one big difference: not only GUI is used to do preview but also code. It is more likely a programming technique than IDE feature but IDE could make thing simplier and faster;
- autocomplete in the editor using widgets names e.g. to insert "gtk_builder_get_object(, "widgetname")" into code;
- templates library of modules (GUI + code), including custom modules with ability to "inherit" the module.
by Alexandre Inacio Rosenfeld, mentored by John Carr
This proposal will implement full iPod support in the data synchronization application Conduit.
iPod today is one of the most popular portable media players. But until recently, the closed nature of the iPod operating system and it's internal database kept Linux users with no easy way to use their iPods with their own data.
iPod support in Linux has improved recently, but the experience is still much worst then it could be. The user's songs and videos must be transfered manually and many times media players have either no support for iPod or they implement their own, usually incomplete, iPod support.
Users in other operating systems are used to plug their iPods and their data are automatically synchronized. That is made simple by the Apple iTunes application. It provides both a media library and an automatic synchronization feature for iPods.
In Linux, there is a program that makes it simple to synchronize between many services, applications and devices, called Conduit. But todays iPod support for Conduit includes Notes, Photos and Calendars only. This proposal will implement the Audio and Video parts that are missing for a full iPod support in Conduit.
Connecting the entire user desktop and any online services supported through Conduit to the iPod, will bring the iPod support in Linux to a whole new level. Advanced users will be able to setup any application, online service or files to be directly uploaded to theirs iPod, and media applications will be able to use the Conduit DBus interface to add support for iPods in just a few lines of code. There is also a plan to create an interface very similar to the iTunes iPod support, allowing novice users to easily set their synchronization options from a list of supported applications.
This proposal will implement full iPod support in the data synchronization application Conduit.
iPod today is one of the most popular portable media players. But until recently, the closed nature of the iPod operating system and it's internal database kept Linux users with no easy way to use their iPods with their own data.
iPod support in Linux has improved recently, but the experience is still much worst then it could be. The user's songs and videos must be transfered manually and many times media players have either no support for iPod or they implement their own, usually incomplete, iPod support.
Users in other operating systems are used to plug their iPods and their data are automatically synchronized. That is made simple by the Apple iTunes application. It provides both a media library and an automatic synchronization feature for iPods.
In Linux, there is a program that makes it simple to synchronize between many services, applications and devices, called Conduit. But todays iPod support for Conduit includes Notes, Photos and Calendars only. This proposal will implement the Audio and Video parts that are missing for a full iPod support in Conduit.
Connecting the entire user desktop and any online services supported through Conduit to the iPod, will bring the iPod support in Linux to a whole new level. Advanced users will be able to setup any application, online service or files to be directly uploaded to theirs iPod, and media applications will be able to use the Conduit DBus interface to add support for iPods in just a few lines of code. There is also a plan to create an interface very similar to the iTunes iPod support, allowing novice users to easily set their synchronization options from a list of supported applications.
by Soare Andrei, mentored by Federico Mena-Quintero
This project is about reducing the memory fragmentation in GNOME. Responsible for fragmentation are memory allocations (malloc / new) and deallocations (free / delete), which appear throughout the code in a random fashion, thus leaving many free spaces. Unfortunately, these are used very often by programmers. I will analyze the source code of the main applications that come bundled in GNOME, the ones that tend to use the most memory, find the places where the most allocations occur and find a way to reduce them, similar to the work that has been done to reduce memory usage in Firefox 3.
This project is about reducing the memory fragmentation in GNOME. Responsible for fragmentation are memory allocations (malloc / new) and deallocations (free / delete), which appear throughout the code in a random fashion, thus leaving many free spaces. Unfortunately, these are used very often by programmers. I will analyze the source code of the main applications that come bundled in GNOME, the ones that tend to use the most memory, find the places where the most allocations occur and find a way to reduce them, similar to the work that has been done to reduce memory usage in Firefox 3.
by Charlotte Curtis, mentored by Philip Van Hoof
SuperRandom is a predictive playback plugin that would select songs to play in Rhythmbox based on similarity to the current song or to a set of selected songs. The similarity parameters would be determined through a combination of signal analysis and feature extraction of the songs and the information contained in the id3 tags.
by Clemens Buss, mentored by Christian Kellner
The core problem, which gives rise to the wish for a feature like tags on a modern desktop, is that file systems, the Kernel VFS in particular, are incapable of gluing metadata to files.
The power of tags to bring some kind of order to a set of data in a convenient and intuitive way can be seen in a lot of web applications. The use of tags in GMail, for instance, constitutes an unprecedented break with the limitations of sorting files in folders. The usual way of sorting files in a folder-hierarchy (taxonomy) is time-consuming and still not satisfying, because it is often not clear which single folder e.g. a mail should be assigned to.
This leads to an unsatisfying lack of organization.
While it is obviously an asset to use tags to organize mails one could pose the question why one should not use the same principle to organize files. In fact, the use of tags could be a leap forward for the organization of files at least as big as for the organization of e.g. mails (or bookmarks, photos etc. like in other Web2.0 applications).
On the GNOME Desktop there already exists the concept of emblems. They are either user-defined symbols or live-metadata(read-only, link etc.) which are represented together with the icon of the file or folder in Nautilus.
It is unfortunate that at present the user-assigned emblems are not usable and retrievable by other programs.
It is equally unfortunate that conceptually there is no difference between a user-defined and a live-metadata emblem.
Adding the concept of tagging, which is pretty close to what emblems are today, one can end up in the following scenario:
Emblems will be the visual representation of tags as well as of live-metadata. As one neither wants to represent every tag nor all live-metadata as an emblem it should be kept flexible (perhaps user-defined) which of those actually lead to a graphical representation in the interface.
In this way the meaning of an emblem will not be ambiguous any more. Tags and live-metadata are not the same, whereas before both somehow constituted emblems. An emblem will become the sole representation of those on the UI side.
The storage of tags should be implemented using GIO/GVFS and the project would put its first focus on the implementation of tags on the GVFS side. Secondly, the concept described above, emblems being a visual representation of live-metadata and tags, would be implemented.
Then, depending on the time left, some of the ideas of how to handle tagging and emblems on the user interface side could be implemented. It would be interesting to look at how to design a dialog/tool for connecting tags with an emblem, the integration in the GTK+ File Chooser/Save dialog or the accessibility of tags to desktop retrieval tools.
The core problem, which gives rise to the wish for a feature like tags on a modern desktop, is that file systems, the Kernel VFS in particular, are incapable of gluing metadata to files.
The power of tags to bring some kind of order to a set of data in a convenient and intuitive way can be seen in a lot of web applications. The use of tags in GMail, for instance, constitutes an unprecedented break with the limitations of sorting files in folders. The usual way of sorting files in a folder-hierarchy (taxonomy) is time-consuming and still not satisfying, because it is often not clear which single folder e.g. a mail should be assigned to.
This leads to an unsatisfying lack of organization.
While it is obviously an asset to use tags to organize mails one could pose the question why one should not use the same principle to organize files. In fact, the use of tags could be a leap forward for the organization of files at least as big as for the organization of e.g. mails (or bookmarks, photos etc. like in other Web2.0 applications).
On the GNOME Desktop there already exists the concept of emblems. They are either user-defined symbols or live-metadata(read-only, link etc.) which are represented together with the icon of the file or folder in Nautilus.
It is unfortunate that at present the user-assigned emblems are not usable and retrievable by other programs.
It is equally unfortunate that conceptually there is no difference between a user-defined and a live-metadata emblem.
Adding the concept of tagging, which is pretty close to what emblems are today, one can end up in the following scenario:
Emblems will be the visual representation of tags as well as of live-metadata. As one neither wants to represent every tag nor all live-metadata as an emblem it should be kept flexible (perhaps user-defined) which of those actually lead to a graphical representation in the interface.
In this way the meaning of an emblem will not be ambiguous any more. Tags and live-metadata are not the same, whereas before both somehow constituted emblems. An emblem will become the sole representation of those on the UI side.
The storage of tags should be implemented using GIO/GVFS and the project would put its first focus on the implementation of tags on the GVFS side. Secondly, the concept described above, emblems being a visual representation of live-metadata and tags, would be implemented.
Then, depending on the time left, some of the ideas of how to handle tagging and emblems on the user interface side could be implemented. It would be interesting to look at how to design a dialog/tool for connecting tags with an emblem, the integration in the GTK+ File Chooser/Save dialog or the accessibility of tags to desktop retrieval tools.
by Filippo Argiolas, mentored by Daniel Siegel
Cheese has been one of the best innovations that made 2.22 a great
GNOME Release. It's amazing to use the webcam to take funny photos and
it's great how it integrates with the whole desktop.
Looking at the effects it provides though, it still lacks something to
realize its whole potential. Some cool hardware accelerated effect
(some distortion and artistic realtime image manipulation) would
greatly improve the variety of fancy and funny photos achievable and
would stimulate a bit more the hedonistic side that every user has.
So my purpose is to write a gstreamer plugin capable of trasforming
the webcam video data to GL textures that can be manipulated with hardware
accelerated techniques and resend them as video data to the gstreamer
pipeline. My plugin would take advantage of modern video adapters'
programmable pipeline supporting GLSL shaders.
This plugin will be easily integrated with Cheese that already uses
gstreamer based effects.
I'll also write some simple effect for the new plugin:
- some photobooth-like distortion effect (squeeze, mirror, dent,
bulge, fisheye, light-tunnel and probably more)
- some color manipulation effect (negative, sepia, black&white,
thermal signature, and probably something more complex like
convolution filters, chromakey, etc)
All this effects, being gstreamer based, won't be restricted to Cheese
use only but they could be, of course, used in other video editing
software (e.g. PiTiVi), or wherever gstreamer is used to manage
video data.
Later, if time would allow or even after GSOC program ends, I'd like
to add some UI improvements to Cheese, like switching to Clutter to
display video, improve the effect selector with live previews of
applied effects, and some Clutter based animation here and there.
Cheese has been one of the best innovations that made 2.22 a great
GNOME Release. It's amazing to use the webcam to take funny photos and
it's great how it integrates with the whole desktop.
Looking at the effects it provides though, it still lacks something to
realize its whole potential. Some cool hardware accelerated effect
(some distortion and artistic realtime image manipulation) would
greatly improve the variety of fancy and funny photos achievable and
would stimulate a bit more the hedonistic side that every user has.
So my purpose is to write a gstreamer plugin capable of trasforming
the webcam video data to GL textures that can be manipulated with hardware
accelerated techniques and resend them as video data to the gstreamer
pipeline. My plugin would take advantage of modern video adapters'
programmable pipeline supporting GLSL shaders.
This plugin will be easily integrated with Cheese that already uses
gstreamer based effects.
I'll also write some simple effect for the new plugin:
- some photobooth-like distortion effect (squeeze, mirror, dent,
bulge, fisheye, light-tunnel and probably more)
- some color manipulation effect (negative, sepia, black&white,
thermal signature, and probably something more complex like
convolution filters, chromakey, etc)
All this effects, being gstreamer based, won't be restricted to Cheese
use only but they could be, of course, used in other video editing
software (e.g. PiTiVi), or wherever gstreamer is used to manage
video data.
Later, if time would allow or even after GSOC program ends, I'd like
to add some UI improvements to Cheese, like switching to Clutter to
display video, improve the effect selector with live previews of
applied effects, and some Clutter based animation here and there.
by Zhang Shunchang, mentored by Philip Van Hoof
The goal of this project is explicit: use Seahorse(http://live.gnome.org/Seahorse) widgets for Evolution's (http://live.gnome.org/Evolution) encryption and key selection, which is a GNOME application for managing encryption keys. It has already integrated with nautilus, gedit and other places for encryption, decryption and other operations. So this project will make Evolution have a more consistent interface.
Seahorse provides some useful D-Bus interfaces, such as query information of user's keys, import/export keys, import keys from key-server. Then we can use it to modify the Evolution's key selection and encryption. We need to draw/modify the Evolution's UI of key selection, so we can use GTK+/GLib to do it.
The goal of this project is explicit: use Seahorse(http://live.gnome.org/Seahorse) widgets for Evolution's (http://live.gnome.org/Evolution) encryption and key selection, which is a GNOME application for managing encryption keys. It has already integrated with nautilus, gedit and other places for encryption, decryption and other operations. So this project will make Evolution have a more consistent interface.
Seahorse provides some useful D-Bus interfaces, such as query information of user's keys, import/export keys, import keys from key-server. Then we can use it to modify the Evolution's key selection and encryption. We need to draw/modify the Evolution's UI of key selection, so we can use GTK+/GLib to do it.
by Gaëtan Podevijn, mentored by Xavier Claessens
Empathy use a home made system for themes. To be more user friendly, it would be nice that Empathy can offer a lot of themes.
To do that, Empathy should have a good theme engine. This engine could manage theme using HTML/CSS technology. Moreover, Empathy could use a lot of Adium's themes. However, Empathy should manage the theme that are presents for the moment.
This will be implement with a new API and with Webkit to be able to use HTML/CSS themes.
The Empathy web page is here:
http://live.gnome.org/Empathy
Empathy use a home made system for themes. To be more user friendly, it would be nice that Empathy can offer a lot of themes.
To do that, Empathy should have a good theme engine. This engine could manage theme using HTML/CSS technology. Moreover, Empathy could use a lot of Adium's themes. However, Empathy should manage the theme that are presents for the moment.
This will be implement with a new API and with Webkit to be able to use HTML/CSS themes.
The Empathy web page is here:
http://live.gnome.org/Empathy
by James Sharpe, mentored by Jens Granseuer
Many users will judge a desktop environment by the default configuration provided by the distribution. Gnome has long been missing the ability to select different backgrounds for each workspace. Other competing window managers have long had this ability and differently styled workspaces can help provide visual cues to the user as to which workspace they are currently working on. The recent adoption of compositing window managers further raises the expectations of the user from the desktop system. Addition of this feature will bring Gnome forward to compete at the forefront of the desktop windowing environments.
A intuitive, simple interface will be key to this functionality; for existing and new users to not be confused by an overly complex system, but at the same time providing a feature rich interface to enable power users to fully customize their desktop environment.
Many users will judge a desktop environment by the default configuration provided by the distribution. Gnome has long been missing the ability to select different backgrounds for each workspace. Other competing window managers have long had this ability and differently styled workspaces can help provide visual cues to the user as to which workspace they are currently working on. The recent adoption of compositing window managers further raises the expectations of the user from the desktop system. Addition of this feature will bring Gnome forward to compete at the forefront of the desktop windowing environments.
A intuitive, simple interface will be key to this functionality; for existing and new users to not be confused by an overly complex system, but at the same time providing a feature rich interface to enable power users to fully customize their desktop environment.
by Rui Tiago Cação Matos, mentored by Ghee Seng Teo
Printing on the Free Desktop is an "horror story". I'm not the one making that claim, Eric S. Raymond did it[1] around 4 years ago, but I agree with it. Meanwhile things have improved but not by much. In particular, the GNOME desktop, unfortunately, still lacks an integrated printer management tool that is easy to use, acronym free and actually works.
As proposed on the GNOME project's GSoC 2008 list of projects I intend to research the problem space thoroughly and finally implement a well integrated printing management tool that gets the job done and leaves the user free to actually print instead of fighting printing configuration.
Said tool shall work as best as possible with the current de-facto printing system on the Free Desktops, CUPS. It should also use modern hardware abstraction, policy definition and session management frameworks (HAL, PolicyKit and ConsoleKit) to make intelligent decisions about local and networked printer hardware on the dynamically connected computer systems we use today.
[1] http://catb.org/~esr/writings/cups-horror.html
Printing on the Free Desktop is an "horror story". I'm not the one making that claim, Eric S. Raymond did it[1] around 4 years ago, but I agree with it. Meanwhile things have improved but not by much. In particular, the GNOME desktop, unfortunately, still lacks an integrated printer management tool that is easy to use, acronym free and actually works.
As proposed on the GNOME project's GSoC 2008 list of projects I intend to research the problem space thoroughly and finally implement a well integrated printing management tool that gets the job done and leaves the user free to actually print instead of fighting printing configuration.
Said tool shall work as best as possible with the current de-facto printing system on the Free Desktops, CUPS. It should also use modern hardware abstraction, policy definition and session management frameworks (HAL, PolicyKit and ConsoleKit) to make intelligent decisions about local and networked printer hardware on the dynamically connected computer systems we use today.
[1] http://catb.org/~esr/writings/cups-horror.html
by Abderrahim Kitouni, mentored by Jürg Billeter
Vala is an upcoming programming language for the GObject system, it's a high level programming language like Java or C#, but does not need big runtime. Instead it just relies on the GNOME platform and compiles to C/GObject code.
I would be a big plus for the GNOME community to have an IDE for such a language. As the GNOME IDE, Anjuta is the best candidate for this. My project is to write a plugin for Anjuta to work with Vala.
Vala is an upcoming programming language for the GObject system, it's a high level programming language like Java or C#, but does not need big runtime. Instead it just relies on the GNOME platform and compiles to C/GObject code.
I would be a big plus for the GNOME community to have an IDE for such a language. As the GNOME IDE, Anjuta is the best candidate for this. My project is to write a plugin for Anjuta to work with Vala.
by Cosimo Cecchi, mentored by Nicolas Trangez
One of the things that the GNOME Desktop lacks to appear as an integrated and cohesive Desktop Environment, compared to e.g. Mac OSX, is the lack of a deep media integration across the Desktop.
Deep media integration means the user should be able to access his documents and media files from the GtkFileChooser without being forced to remember where he saved his files, and should be able to query for files not only by their paths/URIs, but also by their metadata (e.g. ID3 tags for music files, EXIF information for photos and so on) and by the last access it was done to the file (though this is possible, in a quite generic way, with the GtkRecentManager tools).
GtkMediaManager wants to solve this problem introducing an API to query, browse and tag files across the desktop, providing on one side, media listing in the GtkFileChooser with a queriable interface, and on the other side, a simple API for other applications to hook their files and relevant metadata inside the manager.
GtkMediaManager will be written in C and will use either use Xesam or plugins for application-specific database to query and store information and metadata about the media files. It will also be integrated with the GtkFileChooser, providing a set of widgets to easily query by attributes depending on the file type we want, and it finally will be integrated with GtkRecentManager, which will provide GtkMediaManager information about the files recently used by media applications.
One of the things that the GNOME Desktop lacks to appear as an integrated and cohesive Desktop Environment, compared to e.g. Mac OSX, is the lack of a deep media integration across the Desktop.
Deep media integration means the user should be able to access his documents and media files from the GtkFileChooser without being forced to remember where he saved his files, and should be able to query for files not only by their paths/URIs, but also by their metadata (e.g. ID3 tags for music files, EXIF information for photos and so on) and by the last access it was done to the file (though this is possible, in a quite generic way, with the GtkRecentManager tools).
GtkMediaManager wants to solve this problem introducing an API to query, browse and tag files across the desktop, providing on one side, media listing in the GtkFileChooser with a queriable interface, and on the other side, a simple API for other applications to hook their files and relevant metadata inside the manager.
GtkMediaManager will be written in C and will use either use Xesam or plugins for application-specific database to query and store information and metadata about the media files. It will also be integrated with the GtkFileChooser, providing a set of widgets to easily query by attributes depending on the file type we want, and it finally will be integrated with GtkRecentManager, which will provide GtkMediaManager information about the files recently used by media applications.
by Gabriel Geraldo França Marcondes, mentored by Nickolay Shmyrev
As technologies increase their capacities, people want more and more flexibility and facilities. As consequence, new softwares bring features for giving people what they want. Talking to computer is one of these wanted facilities.
Speech is the better way for people to communicate between themselves, and it would be very nice if computers could be totally controlled by this way. Not surprisingly, speech recognition is an increasing branch of computer science.
This project consists of bringing a new resource to this world. The idea is to implement speech notes on Tomboy. That would be an easier way to take notes, faster and more expressive than typing.
As technologies increase their capacities, people want more and more flexibility and facilities. As consequence, new softwares bring features for giving people what they want. Talking to computer is one of these wanted facilities.
Speech is the better way for people to communicate between themselves, and it would be very nice if computers could be totally controlled by this way. Not surprisingly, speech recognition is an increasing branch of computer science.
This project consists of bringing a new resource to this world. The idea is to implement speech notes on Tomboy. That would be an easier way to take notes, faster and more expressive than typing.
by Sunil Kumar Ghai, mentored by Trent Lloyd
Avahi is a Free Software implementation of Zeroconf stack. It implements Automatic IPv4LL address allocation, Multicast DNS (mDNS) and DNS based service discovery (DNS-SD) specifications for Zeroconf (aka Bonjour in Apple MacOS X) Networking.
This project aims to integrate Link-Local Multicast Name Resolution (LLMNR) protocol in Avahi, which would result in Avahi being able to take part in both Apple-style and Microsoft-style Zeroconf networking.
Avahi is a Free Software implementation of Zeroconf stack. It implements Automatic IPv4LL address allocation, Multicast DNS (mDNS) and DNS based service discovery (DNS-SD) specifications for Zeroconf (aka Bonjour in Apple MacOS X) Networking.
This project aims to integrate Link-Local Multicast Name Resolution (LLMNR) protocol in Avahi, which would result in Avahi being able to take part in both Apple-style and Microsoft-style Zeroconf networking.
by Sven Pfaller, mentored by Travis Reitter
Communication is one of the most important parts of human life. In recent times computers and software made it not only easier to communicate, but helped to create new dimensions of interaction. Whether it's email, chatting, voice or video, social platforms or blogs, everyone communicates somehow. This is an exciting development. But it is also a challenge for existing desktop systems to better integrate these new technologies. This is where Soylent comes in.
The Soylent Project is an attempt to really make people a part of the Gnome Desktop. Therefore it will provide a library, called libsoylent, that can be used by Gnome applications to have easy access to people-centric functionality. This includes system-wide access to contacts and groups, aggregating and managing individuals' static information (e.g. name) and dynamic information (e.g. whether he / she is online) and much more.
Communication is one of the most important parts of human life. In recent times computers and software made it not only easier to communicate, but helped to create new dimensions of interaction. Whether it's email, chatting, voice or video, social platforms or blogs, everyone communicates somehow. This is an exciting development. But it is also a challenge for existing desktop systems to better integrate these new technologies. This is where Soylent comes in.
The Soylent Project is an attempt to really make people a part of the Gnome Desktop. Therefore it will provide a library, called libsoylent, that can be used by Gnome applications to have easy access to people-centric functionality. This includes system-wide access to contacts and groups, aggregating and managing individuals' static information (e.g. name) and dynamic information (e.g. whether he / she is online) and much more.
by Vasiliy Kirilichev, mentored by Lawrence Ewing
The support of color profiles can considerably expand the base functionality of any graphic software. It is very important at a big quantity of an available multimedia of the equipment to try to ensure the functioning into a principle that I see, I receive. It is the important problem not only to professionals in the field of schedules and polygraphy, but also usual users. With arrival on the market mass, accessible to the broad audience of digital phototechnics the problem of a color rendition became very actual for them, because it is very unpleasant to receive at a press not wanted color. Usually pictures on the monitor screan looks bright and natural, but on the paper they looks not so brilliant. The decision of this problem was offered enough for a long time, now it is standard to use color structures. They correct the image in view of physical opportunities of devices of a conclusion. So it is is possible to facilitate a life of users and present them too more functionality with adding the support of color profiles in f-spot. And the program will not be so hard as, for example, gimp.
The support of color profiles can considerably expand the base functionality of any graphic software. It is very important at a big quantity of an available multimedia of the equipment to try to ensure the functioning into a principle that I see, I receive. It is the important problem not only to professionals in the field of schedules and polygraphy, but also usual users. With arrival on the market mass, accessible to the broad audience of digital phototechnics the problem of a color rendition became very actual for them, because it is very unpleasant to receive at a press not wanted color. Usually pictures on the monitor screan looks bright and natural, but on the paper they looks not so brilliant. The decision of this problem was offered enough for a long time, now it is standard to use color structures. They correct the image in view of physical opportunities of devices of a conclusion. So it is is possible to facilitate a life of users and present them too more functionality with adding the support of color profiles in f-spot. And the program will not be so hard as, for example, gimp.
by William Christopher Farrington, mentored by Xavier Claessens
One of the key focuses of the GNOME desktop is to include a variety of applications which do one thing well, and only that one thing. As a result, the Empathy developers -- who are at the moment seeking inclusion in GNOME 2.24 -- have raised comments asking for the IRC-specific aspects of Empathy to be broken apart into a separate application, using libempathy(-gtk) and telepathy. The goal of this separate application would be to provide all the flexibility, feature coverage, and usability in XChat-GNOME, but using GNOME-specific technologies. This application would also feature a flexible plug-in system using Python.
One of the key focuses of the GNOME desktop is to include a variety of applications which do one thing well, and only that one thing. As a result, the Empathy developers -- who are at the moment seeking inclusion in GNOME 2.24 -- have raised comments asking for the IRC-specific aspects of Empathy to be broken apart into a separate application, using libempathy(-gtk) and telepathy. The goal of this separate application would be to provide all the flexibility, feature coverage, and usability in XChat-GNOME, but using GNOME-specific technologies. This application would also feature a flexible plug-in system using Python.
mmm when the miniatures view in file dialogs?? anybody???
ReplyDeleteand plz get rid of that monkey in your veins.
I've got two more improvements for GNOME:
ReplyDelete1) Ability to restore from trash.
Every other desktop environment has had this for years. Both KDE and XFCE have it. Why doesn't GNOME? Since GVFS is supposed to allow for this capability, I'm expecting to see it in the next Gnome release. It's time to start actually patching the gaps between GNOME and a modern desktop enviroment from this decade. GVFS was a good start, and now I expect some follow-through.
2) Decouple Evolution and the taskbar calendar. Not everyone uses evolution. More to the point, why should I be forced to enter my email account password just to enter an appointment on my calendar? Especially when I typically use a stand-alone, non-networked calendar applet.