Re: [E-devel] Evas transforms/filters/etc.
I wrote: >>> I wish someone would point out an interesting, and/or common, >>> real-time gui use of something besides: one specialty filter (say a >>> blur or a bumpmap) followed by a geometric transform (and possibly >>> all clipped by a mask). >>> >>> >> in order to do cover flow-like we need: >>1 - projection; >>2 - mirror; >>3 - blur the mirror; >> >> >> > > That's one way, though in fact projection and mirror are > expressible as one transform. The simplest way to do this is to > perform the required transform and mask with a suitable gardient- > like image (could also be defined as a single especialty filter). > Would you like me to send you some simple software-based > examples of how you can do this? > > BTW, I should've mentioned that not only with software, but also with xrender, there are two basic, simple ways of obtaining this for 2d images using projective transforms and masks: 1. You can create a suitable gradient-like 'fade' alpha-image to use as a mask, and you can either first suitably mask the given image surface (possibly scaling the mask to 'fit' the image correctly) to a buffer image, and then use a projective transform (one which mimics a rotation around the y axis, and inverts it) on that resulting buffer image. 2. Or you can do it in one pass (no buffer images) by simultaneously transforming the given image (with the y-rotation&inversion transform) and mask with the fade using a similar transform (with possibly also does scaling, as well as y-rotating and maybe inverts too, depends on how you take the fade mask to be). There are other ways.. ones that are combos of these two, and other specialty ones if you have more to work with.. But again, it's a fairly simple thing to do with just one transform on the image and a 'fade' alpha-mask image (or gradient) which may also have a transform. With a 2d vgfx based api, it's a bit more tricky and you'd still need support for projective transforms of images from that api or specialty image filters in some way - which not all 2d vgfx apis have. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Patch valgrind deprecated macro
Hello, When compiling ecore on a system that has valgrind installed it failed because of a deprecated macro call: VALGRIND_MAKE_READABLE in the evas library. In the NEWS file distributed with valgrind, in the changes for the 3.2.0 version is stated: - There are some changes to Memcheck's client requests. Some of them have changed names: MAKE_NOACCESS --> MAKE_MEM_NOACCESS MAKE_WRITABLE --> MAKE_MEM_UNDEFINED MAKE_READABLE --> MAKE_MEM_DEFINED CHECK_WRITABLE --> CHECK_MEM_IS_ADDRESSABLE CHECK_READABLE --> CHECK_MEM_IS_DEFINED CHECK_DEFINED --> CHECK_VALUE_IS_DEFINED These deprecated calls have been removed in the Release 3.3.0 (7 December 2007) A patch follows. -- Charles Clément. Index: evas/src/lib/engines/common/evas_image_main.c === --- evas.orig/src/lib/engines/common/evas_image_main.c +++ evas/src/lib/engines/common/evas_image_main.c @@ -157,7 +157,7 @@ _evas_common_rgba_image_surface_alloc(Im if (im->image.data == NULL) return -1; #ifdef HAVE_VALGRIND - VALGRIND_MAKE_READABLE(im->image.data, siz); + VALGRIND_MAKE_MEM_DEFINED(im->image.data, siz); #endif return 0; - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-04-27 07:09:08 -0700
Build log for Enlightenment DR 0.17 on 2008-04-27 07:09:08 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 Systray Module sourcecode?
UHm guess you don't exactly know thepast histroy of GOs then sorry but I was talking about GOs rocket E17, not GOs space, and rocket E17 used E17 of course, you can still download it and try it, and you'll find the systray module for E17 in the distro too... Anyone please? Luca - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 Systray Module sourcecode?
On Sun, 27 Apr 2008, The DarkMaster wrote: > UHm guess you don't exactly know thepast histroy of GOs then > sorry but I was talking about GOs rocket E17, not GOs space, and rocket E17 > used E17 of course, you can still download it and try it, and you'll find > the systray module for E17 in the distro too... > Anyone please? Thanks, I know GOs was first released with E17 as a window manager, but as your mail wasn't specific (no link to a screenshot to know what you were talking about), I assumed you were refering to the latest version supported, which is compiz based. As for the systray, have you checked on http://www.e17-stuff.org/ for example ? This could be itask-ng maybe ? Nicolas - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 Systray Module sourcecode?
There are only a few people who will know where this source code has ended up if it still exists anywhere. If you have not coded anything for gOS please refrain from answering as you will be no help ;) Pomarede Nicolas wrote: > On Sun, 27 Apr 2008, The DarkMaster wrote: > > >> UHm guess you don't exactly know thepast histroy of GOs then >> sorry but I was talking about GOs rocket E17, not GOs space, and rocket E17 >> used E17 of course, you can still download it and try it, and you'll find >> the systray module for E17 in the distro too... >> Anyone please? >> > > Thanks, I know GOs was first released with E17 as a window manager, but as > your mail wasn't specific (no link to a screenshot to know what you were > talking about), I assumed you were refering to the latest version > supported, which is compiz based. > > As for the systray, have you checked on http://www.e17-stuff.org/ for > example ? This could be itask-ng maybe ? > > Nicolas > > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 Systray Module sourcecode?
I happened to have a copy locally, but like I've said before, it needs A LOT of work. A lot of applications may just not work at all and others will have various issues. Here it is regardless: http://mekius.net/files/misc/systray.tar.gz Pomarede Nicolas wrote: > On Sun, 27 Apr 2008, The DarkMaster wrote: > > >> UHm guess you don't exactly know thepast histroy of GOs then >> sorry but I was talking about GOs rocket E17, not GOs space, and rocket E17 >> used E17 of course, you can still download it and try it, and you'll find >> the systray module for E17 in the distro too... >> Anyone please? >> > > Thanks, I know GOs was first released with E17 as a window manager, but as > your mail wasn't specific (no link to a screenshot to know what you were > talking about), I assumed you were refering to the latest version > supported, which is compiz based. > > As for the systray, have you checked on http://www.e17-stuff.org/ for > example ? This could be itask-ng maybe ? > > Nicolas > > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 Systray Module sourcecode?
Nick you are just a GOD! Thank you very much, we'll try our best to work on it and see if we can make it a better tray :) Of course all the changes will be public! ;) Luca 2008/4/27 Nick Hughart <[EMAIL PROTECTED]>: > I happened to have a copy locally, but like I've said before, it needs A > LOT of work. A lot of applications may just not work at all and others will > have various issues. Here it is regardless: > > http://mekius.net/files/misc/systray.tar.gz > > Pomarede Nicolas wrote: > > > On Sun, 27 Apr 2008, The DarkMaster wrote: > > > > > > > > > UHm guess you don't exactly know thepast histroy of GOs then > > > sorry but I was talking about GOs rocket E17, not GOs space, and > > > rocket E17 > > > used E17 of course, you can still download it and try it, and you'll > > > find > > > the systray module for E17 in the distro too... > > > Anyone please? > > > > > > > > > > Thanks, I know GOs was first released with E17 as a window manager, but > > as your mail wasn't specific (no link to a screenshot to know what you were > > talking about), I assumed you were refering to the latest version supported, > > which is compiz based. > > > > As for the systray, have you checked on http://www.e17-stuff.org/ for > > example ? This could be itask-ng maybe ? > > > > Nicolas > > > > > > > > - > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't > > miss this year's exciting event. There's still time to save $100. Use > > priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] FreeBSD Update
Hello, I just joined mailing list. I'm on FreeBSD with e17. Wondering if someone can update the ports (x11/enlightenment-devel) on FreeBSD and get entrance over to it. THANKS!! Ben - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] EET minor details
Hi,
The SoC student for python-eet (Luiz Irber) is doing the project even
without Google's money, so while reading the code in order to do
proper mentoring I found some minor details. If you're ok with them,
the student can provide patches for these and I can commit.
1 - minor spell errors in the docs, easy to fix using aspell/ispell
2 - why descriptor macros don't use offsetof() macros (in GCC one can
do it using __builtin_offsetof()). Vincent, can you confirm if similar
stuff is available on Windows? This would improve readability.
3 - why not make EET_T_* and EET_G_* enums and use them in functions?
4 - in many places we use the construction:
len = strlen(str);
strcpy(copy, str);
why not use memcpy() since we already know the size?
5 - in other places it's bit worse:
copy = strdup(str);
len = strlen(str);
this should be replaced with (will save 1 walk of the whole string):
len = strlen(str);
copy = malloc(len + 1);
memcpy(copy, str, len + 1);
6 - from 4 and 5 it also look that we should keep the string size
around and use it instead of these str* variants...
7 - why endianess/bytesex is detected at runtime?
8 - eet_coder is sometimes accessed with type and others with (type -
1), is this correct? It would be better to convert to the correct (0
or 1 start) and go with it all along. This was a quick look, no real
attempt to understand surrounding code.
9 - minor weirdness in casts... not respecting const where it could
(eet_data_{get,put}_*), unneeded casts for malloc.
10 - some code paths could be split into functions and be reused, to name one:
if (data)
{
echnk = eet_data_chunk_new(data, size, ede->name,
ede->type, ede->group_type);
eet_data_chunk_put(ed, echnk, ds);
eet_data_chunk_free(echnk);
free(data);
data = NULL;
}
this is replicated all over the code...
11 - split dump code from decode... at least move the code inside if
(dumpfunc) to another func, it will make code easier to read and still
might make it a bit fast, because most used functions will be smaller.
As you can see it's a bunch of _MINOR_ stuff, very good to get
students used to E code and start contributing! If you're ok,
students could provide one patch for each item, these would be posted
to the ML and then we can commit.
--
Gustavo Sverzut Barbieri
http://profusion.mobi
Embedded Systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EET minor details
On Sun, 27 Apr 2008 23:31:27 -0300 "Gustavo Sverzut Barbieri"
<[EMAIL PROTECTED]> babbled:
> Hi,
>
> The SoC student for python-eet (Luiz Irber) is doing the project even
> without Google's money, so while reading the code in order to do
> proper mentoring I found some minor details. If you're ok with them,
> the student can provide patches for these and I can commit.
>
> 1 - minor spell errors in the docs, easy to fix using aspell/ispell
sure. not critical :)
> 2 - why descriptor macros don't use offsetof() macros (in GCC one can
> do it using __builtin_offsetof()). Vincent, can you confirm if similar
> stuff is available on Windows? This would improve readability.
because offsetof is a macro anyay - the contents of that macro is in effect the
same as in the EET_DATA_DESCRIPTOR_ADD* macros (except they just happen to
use temporary stack pointers instead of a 0 pointer and casting). the result is
the same and the eet macro method is portable, whereas the offsetof macro may
or may not be defined on your target. i see zero ue in changing the code for
the sake of changing it :)
> 3 - why not make EET_T_* and EET_G_* enums and use them in functions?
perfedctly possible - won't improve the code really in any useful way though :)
> 4 - in many places we use the construction:
>len = strlen(str);
>strcpy(copy, str);
> why not use memcpy() since we already know the size?
yes - we can. but in practice - you will not see any difference. they
essentially boil down to the same thing. memcpy() will copy something, compare
index position compared to size and if >= size, stop. the unrolling nature of
memcpy may be a little faster.. with long strings, but with short ones strcpy
will be as fast, or a bit faser as there is never a decision as to possibly
using mmx, sse or other optimised versions for used for larger chunks. in the
end - much of a muchness. the len = bit was used to make sure we allocate a
buffer of the right size so we have no overruns.
again - much of a muchness here. 6 or half-a-dozen. vanilla or chocolate. :)
> 5 - in other places it's bit worse:
> copy = strdup(str);
> len = strlen(str);
>this should be replaced with (will save 1 walk of the whole string):
> len = strlen(str);
> copy = malloc(len + 1);
> memcpy(copy, str, len + 1);
yes - that's better.
> 6 - from 4 and 5 it also look that we should keep the string size
> around and use it instead of these str* variants...
depends on the exact situation.
> 7 - why endianess/bytesex is detected at runtime?
because i was feeling too lazy to add the autofoo macros in. it's only
determined once @ runtime anyway (first use). much of a muchness really again.
> 8 - eet_coder is sometimes accessed with type and others with (type -
> 1), is this correct? It would be better to convert to the correct (0
> or 1 start) and go with it all along. This was a quick look, no real
> attempt to understand surrounding code.
i smell a bug here. i see 1. it should always be type -1 as the array starts @
0 but types start at 1 (type 0 is unknown and invalid). a list of sinple types
(basic types) allocates the wrong memory. it happens to work most of the time
as we almost never use this, and the types tend to go in order from smaller to
larger, thus almost always over-allocating (eg allocing a short instead of a
char, allocing an long long instead of an int, from long long -> float is goes
down, but i don't think a list of floats is ever used, as well as double -> char
(a list of chars is never used). so we have avoided this bug by just never
triggering it (as best i can see). fixed in cvs. (this my explain some
mysterious bugs... i need to double check if we actually did trigger this or
not).
> 9 - minor weirdness in casts... not respecting const where it could
> (eet_data_{get,put}_*), unneeded casts for malloc.
possible - tho const vs non-const generally is just to shut the damn compiler
up. a pointer is a pointer.
> 10 - some code paths could be split into functions and be reused, to name one:
> if (data)
>{
> echnk = eet_data_chunk_new(data, size, ede->name,
> ede->type, ede->group_type);
> eet_data_chunk_put(ed, echnk, ds);
> eet_data_chunk_free(echnk);
> free(data);
> data = NULL;
> }
> this is replicated all over the code...
actually only 5 instances. not that many. sure - it can be a function. we could
spend a LOT of time factoring out code into functions in many places in efl -
this is the least of this kind of thing. you'll find much worse :P i'm happy for
someone to spend time doing this :)
> 11 - split dump code from decode... at least move the code inside if
> (dumpfunc) to another func, it will make code easier to read and still
> might make it a bit fast, because most used functions will be smaller.
you likely are going to make the code larger - dumpfu
Re: [E-devel] EET minor details
On 04/27/2008 21:31, Gustavo Sverzut Barbieri wrote:
> Hi,
>
> The SoC student for python-eet (Luiz Irber) is doing the project even
> without Google's money,
FWIW... A Google t-shirt can still be obtained for these efforts.
(Will not be an SoC shirt, but a Google t-shirt.) :)
> so while reading the code in order to do
> proper mentoring I found some minor details. If you're ok with them,
> the student can provide patches for these and I can commit.
>
> 1 - minor spell errors in the docs, easy to fix using aspell/ispell
>
> 2 - why descriptor macros don't use offsetof() macros (in GCC one can
> do it using __builtin_offsetof()). Vincent, can you confirm if similar
> stuff is available on Windows? This would improve readability.
>
> 3 - why not make EET_T_* and EET_G_* enums and use them in functions?
>
> 4 - in many places we use the construction:
>len = strlen(str);
>strcpy(copy, str);
> why not use memcpy() since we already know the size?
>
> 5 - in other places it's bit worse:
> copy = strdup(str);
> len = strlen(str);
>this should be replaced with (will save 1 walk of the whole string):
> len = strlen(str);
> copy = malloc(len + 1);
> memcpy(copy, str, len + 1);
>
> 6 - from 4 and 5 it also look that we should keep the string size
> around and use it instead of these str* variants...
>
> 7 - why endianess/bytesex is detected at runtime?
>
> 8 - eet_coder is sometimes accessed with type and others with (type -
> 1), is this correct? It would be better to convert to the correct (0
> or 1 start) and go with it all along. This was a quick look, no real
> attempt to understand surrounding code.
>
> 9 - minor weirdness in casts... not respecting const where it could
> (eet_data_{get,put}_*), unneeded casts for malloc.
>
> 10 - some code paths could be split into functions and be reused, to name one:
> if (data)
>{
> echnk = eet_data_chunk_new(data, size, ede->name,
> ede->type, ede->group_type);
> eet_data_chunk_put(ed, echnk, ds);
> eet_data_chunk_free(echnk);
> free(data);
> data = NULL;
> }
> this is replicated all over the code...
>
> 11 - split dump code from decode... at least move the code inside if
> (dumpfunc) to another func, it will make code easier to read and still
> might make it a bit fast, because most used functions will be smaller.
>
> As you can see it's a bunch of _MINOR_ stuff, very good to get
> students used to E code and start contributing! If you're ok,
> students could provide one patch for each item, these would be posted
> to the ML and then we can commit.
>
--
Regards,
Ravenlock
signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EET minor details
On Sun, 27 Apr 2008, Gustavo Sverzut Barbieri wrote: > 1 - minor spell errors in the docs, easy to fix using aspell/ispell > > 2 - why descriptor macros don't use offsetof() macros (in GCC one can > do it using __builtin_offsetof()). Vincent, can you confirm if similar > stuff is available on Windows? This would improve readability. it is available in stddef.h Vincent - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
