The Enlightenment Project is dedicated to providing advanced graphical libraries, tools, and environments. Currently, the project is made up of three different components: Enlightenment DR16, Enlightenment DR17, and the Enlightenment Foundation Libraries. While we are best known for the Enlightenment Window Manager itself there is a long history of providing advanced libraries and tools to support the window manager and other applications, such as Imlib, Imlib2, and FNLib which extend far beyond the window manager itself in scope. We are please to offer the following proposed ideas for students wishing to participate in the Google Summer of Code 2008.
If you are interested in a project below and have questions or comments, please feel free to join us in #e on FreeNode.
It was our intention to provide some sample applications so that students new to the SoC could have an idea of what a well put together application might look like. However, our friends at Wesnoth have beat us to the punch. So, with their permission, here is a link to some of the applications submitted to their project. Note that such elaborate applications are not required. But there are certainly elements to many of them that are quite beneficial. For example, a list of deliverables, a timeline, mockup images if applicable, etc. All these types of things might go into a well thought out application.
Please Note: Student applicants are not limited to the ideas on this page. If you think you have a suitable idea, by all means, please propose it.
The idea here is to implement an Expose like window switching feature. This feature request is complicated by the fact that there is no native compositing manager for Enlightenment. There have been efforts to create compositing managers (Bang, Bling) which have met with limited success. Those modules can be used as references... but the suitability of using them as a base should be determined by the student/mentor pair.
Skills Required:
Strong C background.
Experience with OpenGL.
fundamental understanding of how a compositing engine works.
Medium: Let's remember that although it's standard, there are some variations like KDE's and possible other applications, so it's desired that real applications are tested, including KDE and Gnome flagships.
New version of (The X Resize, Rotate and Reflect Extension - XRandR) provides the flexibility X11 always required, making it possible to do lots of reconfigurations without restarting it or dealing with xorg.conf, however applications and window managers will have to support its new protocol, also providing a nice GUI to handle these options.
This project will require implementing the protocol bits in ecore_x and using them in E17, also providing applets (gadgets) to change settings quickly and dialogs to configure more complex setups, like multi-screen layouts.
Most of real-world user interface have to layout objects on screen given some constraints, like put these objects side by side, but since they have different heights, they should be aligned to the top or put these objects side by side, but make this object the same height as the largest. These are also the base of most widgets toolkits, as they produce scalable interfaces. Edje somehow satisfy basic needs of applications that have fixed amount of widgets that are known at conception time, to more advanced needs one need to use either ETK, EWL or E17 own implementation.
Writing an object layout library would help to avoid code duplication and make it easier to integrate different toolkits, actually removing the need of such toolkits for some applications like Rage.
Most frameworks need great step-by-step code examples with associated documentation so new users can try these simple applications to feel how it works, also serving as cookbook.
The basic set of libraries is already well documented API-wise, including function examples, however one willing to enter this whole new world is faced with a big problem: how to start a real application? We have some sparse introduction texts and some examples, but putting together in a wiki or book, with a repository of basic, step-by-step, examples would be of great help.
Andres Blanc is doing a great work on Edje (see EDC Reference and his book) and other basic documentation, so it's not a start from scratch, but actually learning and helping writing professional documentation.
We should keep the text and examples in CVS so developers could keep them up to date with API changes.
There are already Python bindings for EFL basics, including most of Evas, Edje, basic Ecore, some of Ecore_X, ETK and Epsilon, but there are still lots of great code missing bindings, like Efreet, Ecore_Con, Epdf, Edvi, Egs, Eet and Edb. Another important missing binding is E17 (window manager) API (gadcon and others) so we could write gadgets in Python, using the multitude of libraries, providing feeds/rss display, stock monitoring, system resources graphs and so on. Python already proved as an excellent tool to write such things, as we could see in projects like SuperKaramba and nowadays KDE's Plasma.
Interesting bindings:
E17 API (Gadcon, widgets)
Ecore_{Con,File,IPC,Job,Txt,FB,DirectFB,SDL,Win32} (complete or write these)
Eet (would be excellent to integrate with Python's pickle and even provide eetimport, see zipimport)
Create a new library to manage RSS/ATOM feed (Easy)
Get online contents in easy way
Mentor(s): Undetermined
It is very nice to have a feed parsing library to share between application. E already provide utilities to asynchronously retrieve remote content (e_con_url) and parse xml (exml), we just need to provide some utilities around those to deliver easy of use.
Skill Required:
Strong C background
Good understanding of XML and RSS/ATOM specifications
Description: Epsilon is a library to generate easily thumbnails following the [www.freedesktop.org fdo-specs]. Currently Epsilon uses imlib2 to scale down the images to thumbnail size. This dependence should be drop in favor of Evas.
The API interface should be improved to provide more scaling option.
It should be possible to store the resulting thumbnails inside not just PNG file like the fdo-specs told us, but also inside eet file. Attributes and images should be stored inside the eet file. The resulting file should provide an improved thumbnails load time.
Result: should provide a working replacement for enlightenment e_thumb. Possibly, a new proposal for Freedesktop thumbnail solution based on eet file format, at least format independent solution to be negotiated by applications. (Today FDO is PNG only).
Eagle is an abstraction layer atop Graphical Toolkits to make GUI programming as easy as possible. Eagle reaches this by narrowing what's possible to do and providing high level components with easy to use API. It's designed much like Python's DBAPI is for databases, Eagle handles the UI. But currently Eagle just support GTK, it would be amazing to use Evas and Edje to provide similar features.
Eagle is a great solution to help automation of simple tasks, things very useful in embedded and mobile worlds, where one can't type commands easily, so it provides a big opportunity for simple applications for OpenMoko, Maemo and like systems.
Evas and Edje can provide unique look and feel for Eagle, also being very light on resources, which is fundamental for such systems.
Demanding: Candidates are not expected to know Eagle or EFL, code is quite trivial, but it is quite big task. However basic widget set is easy to do and is very helpful already.
Refactor Edje internals to make more extensible (Challenging)
Edje is the most complex known Evas smart object and does great already, but it started without clear requirements and code evolved as requirements were discovered. Now that requirements are known and almost all are implemented, it could use a refactor to make code simpler and more extensible, allow more control from programming side, as done lately by Dave Andreoli for his edje_editor.
Among desired extensions, we could name dynamic parts and state creation, easier and more flexible ways to specify complex transitions, user defined transition paths (ie: Bézier curves, user function in C or Embryo).
Evas was designed and implemented to be the fastest raster graphics around, this led to secondary features as rotation and general purpose filters to be postponed. But now it's a good time to add these features and we think that providing them as "filter objects" is the best option.
Filter objects would act like today's clips in the sense that they could be chained to provide the desired effect. Implementation of such will be a bit complex in order to achieve maximum performance, since we'd need to keep current performance for non-filtered objects and provide the correct filter pipeline to render filtered objects.
Render pipelines should be optimized as much as possible by means of hardware acceleration (ie: OpenGL's shaders). Filters should work in Software and Hardware engines - software will need to possibly play tricks to get speed, but in the end the principle is the same. You need buffers per filter object to render to, but design is flexible. In the end there should be global canvas controls to enable to disable filter objects for a canvas (even though they are there) or ask them to take shortcuts etc. Also, there is a promising project called Gallium3D that plans to provide optimizations for both hardware and software, so let's "believe" it will work as planned.
This work will require hacking into canvas core, mainly on the render part, probably requiring extensions to engine's API
Difficult: Evas is quite complex and this will require changing its internals, this might be very difficult. Candidates should have real experience with C and OpenGL and good knowledge of rendering pipelines if they don't know Evas already, so it's just one stack to learn.
Evas is very extensible and already runs on various systems, including framebuffer, X11/XRender (both xlib and xcb), OpenGL, SDL and Windows (Direct3d, DirectDraw). Some engines were written but have lagged behind and could be updated while some new could be written.
Interesting engines:
DirectFB demand from embedded systems, mainly set top boxes since most hardware manufactures just provide acceleration for it.
OpenGL/ES really interesting due huge demand on embedded systems (phones, game consoles, mid/umpc/tablets), could be based on existing OpenGL.
OpenVG also interesting on embedded systems, mainly for future systems as still just few devices provide proper acceleration for it.
Cairo exists in CVS, but it's outdated. Should be easy to do.
Qt4/Arthur
Qtopia exists in CVS, but requires update to Qtopia4 and also Evas api changes.
MacOSX/Quartz
Clutter does it worth or OpenGL is enough?
PS: although this is listed under Evas, adding Ecore_Evas support would be desired as well.
Complete migration of Evas and Edje to engines (Medium)
Mentor(s): Nathan (RbdPngn) Ingersoll, dan (dj2) sinclair
We are in the process of slowly abstracting the display layer of EWL into a series of engine plugins. This allows for greater portability to new display systems and defines clear interfaces for drawing system interaction.
There are currently two display systems that are used directly in the main library which need splitting into an engine interface. These are Evas (for drawing the display) and Edje (which describes the theme layout, provides image data, and additional theme meta-information).
Implement an optimized tree view for the list widget (Medium)
Mentor(s): Nathan (RbdPngn) Ingersoll, dan (dj2) sinclair
The tree view in EWL is implemented using a Model View Controller (MVC) style API. This gives us a great amount of flexibility in the actual implementation of the view as it is abstracted from the data. Unfortunately, we currently only provide a very heavy view that errs on the side of correctness.
This task would require the implementation of a more optimized view, which can make more assumptions about the presentation of the data. For instance, displaying fixed size rows within the tree.
Mentor(s): Nathan (RbdPngn) Ingersoll, dan (dj2) sinclair
This is related to the previous task, but more targeted at the existing view code. This code has been developed to provide a flexible display system and err on correctness, but there are certainly ways that this could be improved.
This task would require the profiling of the existing tree view, identification of key optimization points, and implementation of these optimizations.
Addition of tutorials for the missing widgets (Easy)
Mentor(s): Nathan (RbdPngn) Ingersoll, dan (dj2) sinclair
In an effort to provide a useful environment to our end users, we have written tutorials for many of the widgets that have been developed. Unfortunately, these tutorials currently cover less than 50% of the total widgets available.
A student taking on this task would develop thorough tutorials describing the API usage and best-practices for the remaining widget. In addition, they would be responsible for reviewing the existing tutorials for correctness and for possible improvements.
Mentor(s): Nathan (RbdPngn) Ingersoll, dan (dj2) sinclair
Similar to the previously entioned tutorial task, we are also in need of thoroughly documented example applications. This is an expansion on the tutorials as they only cover small sub-sets of the API. These examples would provide full applications with common widget use cases.
The primary goal would be to develop one or more applications which demonstrates the use of 50% or more of the existing widgets. In addition, the code must be thoroughly commented to provide reasoning, implications and recommendations when using the API.
Implementation of obstacles in Ewl_Text (Very Difficult)
Mentor(s): Nathan (RbdPngn) Ingersoll, dan (dj2) sinclair
There is currently no way to set obstacles into Ewl_Text. This task would be for the implementation of obstacles, other widgets, in the Ewl_Text object.
This task would necessitate adding obstacles to Evas_Textblock before they can be added to Ewl_Text.
Description: Write a program that, from a text file, create a presentation tool (a bit like Beamer does with LaTeX). The syntax of the text file should be very simple (no xml). The theme of the tool must be described by an edje file. Application can be written either in Python or C. This application should use the power of edje for all transition effect and text placements.
Result: give a tool to demonstrate the power of the EFL. Make any presentation done with this tool end with people just saying woow ! :-)
Description: Write a program that can display PDF, DVI or Postscript documents. The rendering is done in an Evas obbject with the (existing) libraries Epdf, Edvi and Egs. The difference with Evince will be the GUI, which should be written in full Edje, to have fantastic effects, animations, etc...
Design and implement one or more virtual keyboard system. These could be regular "full sized" that loads a map like QWERTY or innovative solutions that use dictionaries and statistics to provide faster typing while minimizing clicks and visual/interaction area.
EFL is being considered by lots of embedded and mobile systems provider, from phones (like OpenMoko) to internet tables (like Nokia/Maemo and Intel/Ubuntu) to TV-connected set top boxes. All of these require input without using a physical keyboard, either by use of remote control or touchscreen, so providing a virtual keyboard is a must. Our graphics infrastructure provide enough power to bring eye candy, what we (and almost everyone else) lack is a innovative, efficient solution.
Ideas range from phone's T9 enhanced by touchscreen capabilities to concentric circles of options, click based, drag based, dictionary assisted.
Description: Exhibit is an EFL/ETK based image viewer. Similar in nature to gqview. This project will be to provide users the ability to upload images to online sharing services such as Flickr, Picasa, DeviantArt
