So here is a list of possible contribution with rising technical difficulty. If you have any questions don't hesitate to join irc #edevelop and ask there or on the developers mailing-list.
- Translate Edje french tutorial in English. It would be even better if it was merged inside EFL doxygen and part of our official documentation. You can find the source of the document there : https://phab.enlightenment.org/diffusion/ESVN/browse/trunk/DOCS/tutorials/fr/edje/ .
- Write a small application, ask questions on IRC and ML when you don't understand something and provide a patch to make the documentation more easy for you to understand with what you learned.
- Fix all doxygen warning and make sure that every page is accessible and easy to find.
- Improve our tests coverage by writing new tests.
- Add benchmark for Edje or Elementary in Expedite (could even be used to learn EFL and push new documentation in).
- Merge exactness into EFL, write tests and make sure elementary coverage start to be decent. This is also a big opportunity to fix all small little issue and bug you find along the way. It also implies improving exactness quite a lot.
- Improve Eina_Hash, by adding a CRC32 hash function as suggested by Intel engineer Lucas De Marchi on his blog. All the other improvement have already been pushed in EFL, the last one is the CRC32 assembly version and make a version of eina_hash that automatically detect the CPU and choose the best option.
- Add eiod, a daemon designed to handle request that can hang for some time. It could basically be a move of Enlightenment EFM daemon into eio. Some code cleanup and an additional daemon to monitor it (if you don't have systemd user session running). It should come with an Eio API to automatically connect to the daemon, start it if necessary, and just do your request as you ask.
- Many part of Elementary do call edje_object_size_min_restricted_calc which is a long running slow function. This function could be run in parallel with some little change (I do think it require some trick and maybe more easily doable with eo). The idea would be to queue a few request for this restricted calc and then bloc and wait for the result to come out. It is likely also to require the computation of a dependency graph per Edje_Object. Then integrate that new asynchronous API inside Elementary.
- Review code path in elementary that do generate the same content over and over again and cache the result appropriately. A good example is elm_widget_stringlist_get which result should always be cached.
- Add infrastructure in Eo and Edje to allow the caching of an object. Something that would make an eo object die with it current reference, be moved to a new pointer address and then have already initialized content that would be used by a higher up cache infrastructure like one that could be implemented in Edje and remove all the caching infrastructure we have in elementary.
- Improve elementary config so that it can apply a different profile per window. This could then be used to setup a few different profile (HD, Hi-DPI, touchscreen, TV, ...) and an helper dialog in Enlightenment when a new screen is plugged in.
- Add a new configuration library that will make it possible to handle configuration, backup, rollback, version increase and so on seem lessly with possible cloud storage some time in the future.
- Make Evas GL backend track use of a texture and implement a repacked. It would move all the hottest data (or even better if you can figure how, all the data that are used at the same time/together) into the same GL texture. This should limit the amount of texture change at rendering time and potentially improve rendering speed. This could use the heaviest skyline algorithm we have in Eina that are to costly to run in real time.
- Evas pipe rendering was an experiment into having multiple thread to divide the rendering. Sadly we discovered that one core is enough in almost all case except one to use all memory bandwidth. The only case where it make sense when doing smooth scaling. So the idea would be to detect the amount of data to be manipulate and dispatch that among the most meaningful amount of CPU to max out the bandwidth and frame rate.
- VAAPI is a video decoding API that would be meaningful to integrate in Evas as it start to be supported by more than one GPU vendor (AMD and INTEL are providing an implementation, and now that it is a state tracker in Gallium maybe other open source driver may benefit from it). So there is at least 2 tasks. The first one could be to implement the decompression of JPEG for asynchronous preloading using it. Only asynchronous preloading is meaningful as inline loading will take the same amount of time if not more and not help much. The second task would be to add a new native surface set so that we could directly bind a VASurfaceID to a GL surface. Look inside va_glx.h for some detail on that. The benefit would be for emotion to be able to directly stream a hardware surface to evas in a portable way.
- Make sure that there is a working zero copy path with emotion gstreamer backend when the hardware provide the support. It could even use Evas Native Surface on X and on Wayland for the case where there is no VAAPI. It should also be a good opportunity to fix the video code to be able to put that surface directly to screen with absolutely zero copy.
Rewrite Ecore_Con API to use Eo capability to work with Eo event and maybe with Ecore_Thread to. This should lead to significant performance improvement. Bonus point if you are able to implement it with coroutine support. A good reading for this design could be acidx blog: http://tia.mat.br/blog/html/index.html . Additionnaly providing a wrapper for legacy with it's Ecore_Event based API would be a good things.
- Add a Websocket Ecore_Con implementation to make life of people who need to integrate with web technology easier.
Elementary Genlist & Friends
- Refactor code elementary genlist and gengrid to reduce code duplication. After a first pass of cleanup, it should be possible to merge genlist and gengrid, where just a different layout function is called. That will be switched with something like a mode property.
- In general a good code cleanup of elementary is a must. That means start by looking at common pattern and refactor the code. Look for potential error while running elementary_test under valgrind. Look for rendering glitch and anomaly in that said test. See if all memory are properly freed by use valgrind. Look for know pattern of error (you found an error in one widget, try to see if other piece of code are using the same function and do the same mistake).
- Add multicolumn support to elementary list and genlist (it could be just a mode to a refactorised genlist).
Elementary general improvement
- Fix and improve elementary focus logic, by building a fully connected graph to ensure that there is no dark corners where you can't go to. This could be implemented in a few step. First cleanup current code, then implement graph computation on every change in the focus chain, with finally the focus being computed on demand.
- F̶i̶n̶i̶s̶h̶ ̶t̶h̶e̶ ̶a̶d̶d̶i̶t̶i̶o̶n̶ ̶o̶f̶ ̶a̶ ̶c̶o̶m̶b̶o̶b̶o̶x̶ ̶t̶o̶ ̶e̶l̶e̶m̶e̶n̶t̶a̶r̶y̶.̶
- Improve Elm file selector to be matching at least in functionnality and polished UI Enlightenment FM. If done well, we should have add a new File Manager widget, that would be usable for a File Manager and inside the File selector. It should be able to display the content of all EFL know type of file and maybe even provide an infrastructure to extend that capability to unknown type by using callback. Look also at what other toolkit and OS provide to have an idea of what needs to be done.
- Improve the map widget to support offline open street map data (with multiple custom vector renderer that would use Evas_Object_VG API). This could lead to a full application with routing and stuff like that. That is a huge work.
- Get an update LIve CD with all efl stuf ready to use and update ?
- Maybe an automatique iso creation with all update evry month and a stable all 6months ?