[E-devel] Deprecating Ecore_Desktop
All, We've had Efreet in CVS for a while now and it seems to be working well. Taking a look at the other apps in CVS the only one still using Ecore_Desktop that I noticed was Engage. Can the Engage maintainer please update the app to use Efreet so we can move Ecore_Desktop over into proto? Thanks, dan - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] image loading questions
Cool, glad to hear you guys think memory loading is a sane idea! haha, that is funny that we came up with the same plan, CodeWarrior. I'll try to come on IRC sometime again to disucss it further. :) On 7/16/07, Cedric BAIL <[EMAIL PROTECTED]> wrote: > On Monday 16 July 2007 12:26:51 Hisham Mardam Bey wrote: > > On 7/15/07, Eric Wasylishen <[EMAIL PROTECTED]> wrote: > > > Hi, I have a few questions related image loading. > > > > > > One thing I'm working on is an xmms2 client using ETK/evolve. I'd like > > > it to show album cover art; the way the xmms2 client lib handles this > > > is it gives you a pointer to an image file that was copied in to > > > memory but not decoded. People using gtk have a function in gdk_pixbuf > > > for this, which automatically determines the image format (probably > > > jpg or png for covers) and decodes it, but as far as I can tell > > > imlib2/evas lack this feature? (though I noticed epeg can load a jpeg > > > file from memory.) > > > > > > One option I though of is just copying the loader code for say JPG and > > > PNG from evas or imlib2 in to my app, and modifying it to do what I > > > need. Or, would loading images from memory be useful enough to go in > > > evas or imlib2? > > > > Would be nice to have in evas. > > Definitively. I started looking at this and only wrote a patch for eet. This > patch add a new eet_memopen_read. So you can add eet file also to your > idea :) > > Cedric > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On 7/14/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: On 7/14/07, Lars Munch <[EMAIL PROTECTED]> wrote: > Hi Gustavo > > On Fri, Jul 13, 2007 at 07:53:58PM -0300, Gustavo Sverzut Barbieri > wrote: > > Ok, reading evas docs it's really the expected behavior, at least it's > > documented: > > > > * EVAS_CALLBACK_MOUSE_OUT: event_info = pointer to > > Evas_Event_Mouse_Out * * ... Note that no out events will be * > > reported if the mouse pointer is implicitly grabbed to an object (the > > * mouse buttons are down at all and any were pressed on that object). > > An * out event will be reported as soon as the mouse is no longer > > grabbed (no * mouse buttons are depressed). Out events will be > > reported once all buttons * are released, if the mouse has left the > > object. > > > > > > So, how to solve it without brake every existent thing that depends on > > this? > > As you can see from this post I had a similar problem some months ago: > > http://article.gmane.org/gmane.comp.window-managers.enlightenment.devel/12444/match= > > I was also creating a virtual keyboard for a touchscreen and it was also > highly inspirred by the iPhone keyboard. > > I think the current behaviour are good for some parts like sliders, but > for other pars like push buttons I would like to be able to get an out > event as soon at the mouse leaves the part (clicked or not). Maybe we > could add an ungrab or regrab function? yes, maybe mouse_grab=0|1 and in evas test for this flag being set. BUT, i already tried a quick hack to avoid mouse_grabbed lines and it didn't work, maybe it's not that easy or I did some mistake, again a _quick_ hack :-P Ok, it turned out to be easy to extend this with mouse_grab idea, I'd like some review on these patches, but I've tested them together with an etk application (edje_viewer) and it seems to work fine. Patches are attached as TXT so gmail recognizes them as text/plain and avoid them being stripped by e-devel mail list. Notice that edje property is no_mouse_grab, because then we can keep compatibility with existent .edj files. I don't like evas_object_mouse_grab_set() very much, it looks like mouse will be immediately grab, which is not the case. But I don't have any better word for that. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ? configure.addopts ? configure.addopts-i686 Index: src/lib/Evas.h === RCS file: /var/cvs/e/e17/libs/evas/src/lib/Evas.h,v retrieving revision 1.100 diff -u -p -r1.100 Evas.h --- src/lib/Evas.h 10 Jul 2007 00:13:25 - 1.100 +++ src/lib/Evas.h 17 Jul 2007 21:08:04 - @@ -766,6 +766,9 @@ extern "C" { EAPI Evas_Bool evas_object_repeat_events_get (Evas_Object *obj); EAPI void evas_object_propagate_events_set (Evas_Object *obj, Evas_Bool prop); EAPI Evas_Bool evas_object_propagate_events_get (Evas_Object *obj); + EAPI void evas_object_mouse_grab_set(Evas_Object *obj, Evas_Bool no_mouse_grab); + EAPI Evas_Bool evas_object_mouse_grab_get(Evas_Object *obj); + EAPI void evas_object_event_callback_add(Evas_Object *obj, Evas_Callback_Type type, void (*func) (void *data, Evas *e, Evas_Object *obj, void *event_info), const void *data); EAPI void *evas_object_event_callback_del(Evas_Object *obj, Evas_Callback_Type type, void (*func) (void *data, Evas *e, Evas_Object *obj, void *event_info)); Index: src/lib/canvas/evas_callbacks.c === RCS file: /var/cvs/e/e17/libs/evas/src/lib/canvas/evas_callbacks.c,v retrieving revision 1.31 diff -u -p -r1.31 evas_callbacks.c --- src/lib/canvas/evas_callbacks.c 30 Apr 2007 04:22:42 - 1.31 +++ src/lib/canvas/evas_callbacks.c 17 Jul 2007 21:08:04 - @@ -218,12 +218,13 @@ evas_object_event_callback_call(Evas_Obj * EVAS_CALLBACK_MOUSE_DOWN: event_info = pointer to Evas_Event_Mouse_Down * * This event is triggered by a mouse button being depressed while over an - * object. This causes this object to passively grab the mouse until all mouse - * buttons have been released. That means if this mouse button is the first to - * be pressed, all future mouse events will be reported to only this object - * until no buttons are down. That includes mouse move events, in and out - * events, and further button presses. When all buttons are released, event - * propagation occurs as normal. + * object. If mouse_grab is true (default) this causes this object to + * passively grab the mouse until all mouse buttons have been released. + * That means if this mouse button is the first to be pressed, all future + * mouse events will be reported to only this object until no buttons are + * down. Th
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On Tue, Jul 17, 2007 at 06:15:51PM -0300, Gustavo Sverzut Barbieri wrote: > Notice that edje property is no_mouse_grab, because then we can keep > compatibility with existent .edj files. > > I don't like evas_object_mouse_grab_set() very much, it looks like > mouse will be immediately grab, which is not the case. But I don't > have any better word for that. > + EAPI void evas_object_mouse_grab_set(Evas_Object > *obj, Evas_Bool no_mouse_grab); > + EAPI Evas_Bool evas_object_mouse_grab_get(Evas_Object > *obj); Maybe evas_object_auto_grab_set(Evas_Object *obj, Evas_Bool auto_grab) ? (or _mouse_auto_grab_) Whatever we call it, the second parameter should NOT be no_*. It should be TRUE for "grab the mouse", and simply default to TRUE. Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On 7/18/07, Brian Mattern <[EMAIL PROTECTED]> wrote: > On Tue, Jul 17, 2007 at 06:15:51PM -0300, Gustavo Sverzut Barbieri wrote: > > Notice that edje property is no_mouse_grab, because then we can keep > > compatibility with existent .edj files. > > > > I don't like evas_object_mouse_grab_set() very much, it looks like > > mouse will be immediately grab, which is not the case. But I don't > > have any better word for that. > > > + EAPI void evas_object_mouse_grab_set(Evas_Object > > *obj, Evas_Bool no_mouse_grab); > > + EAPI Evas_Bool evas_object_mouse_grab_get(Evas_Object > > *obj); > > > Maybe evas_object_auto_grab_set(Evas_Object *obj, Evas_Bool auto_grab) ? > (or _mouse_auto_grab_) it's not that better... other suggestions? can_grab_mouse? > Whatever we call it, the second parameter should NOT be no_*. It should > be TRUE for "grab the mouse", and simply default to TRUE. yes, I agree, but how about edje files? Can I rely on people updating their edje files? Remember that edje files will not be recompiled since they have not changed, users may issue "make clean" to get it updated. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On Tue, Jul 17, 2007 at 06:15:51PM -0300, Gustavo Sverzut Barbieri wrote: > On 7/14/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > Ok, it turned out to be easy to extend this with mouse_grab idea, I'd > like some review on these patches, but I've tested them together with > an etk application (edje_viewer) and it seems to work fine. > > Patches are attached as TXT so gmail recognizes them as text/plain and > avoid them being stripped by e-devel mail list. > > Notice that edje property is no_mouse_grab, because then we can keep > compatibility with existent .edj files. Can't you just call it mouse_grab and default it to 1 to keep compatibility? Regards Lars Munch - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On 7/18/07, Lars Munch <[EMAIL PROTECTED]> wrote: > On Tue, Jul 17, 2007 at 06:15:51PM -0300, Gustavo Sverzut Barbieri wrote: > > On 7/14/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > > Ok, it turned out to be easy to extend this with mouse_grab idea, I'd > > like some review on these patches, but I've tested them together with > > an etk application (edje_viewer) and it seems to work fine. > > > > Patches are attached as TXT so gmail recognizes them as text/plain and > > avoid them being stripped by e-devel mail list. > > > > Notice that edje property is no_mouse_grab, because then we can keep > > compatibility with existent .edj files. > > Can't you just call it mouse_grab and default it to 1 to keep > compatibility? except that when it's not present in eet file (.edj) it will return 0. thus you can default it to be 1 if omitted during compile (edje_cc), but not while reading (file_set)... at least this is my understanding, I based my code on mouse_events, which is 1 by default. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Support custom click area for Evas_Object
On Mon, 16 Jul 2007 15:27:44 -0300 "Andre Magalhaes" <[EMAIL PROTECTED]> babbled: excellent. will track from bugzilla from now on - first i need to clean out my mailbox mess. > Added to bugzilla: > > http://bugzilla.enlightenment.org/show_bug.cgi?id=105 (evas patch) > http://bugzilla.enlightenment.org/show_bug.cgi?id=106 (edje patch) > > BR > Andrunko > > On 7/16/07, Andre Magalhaes <[EMAIL PROTECTED]> wrote: > > Hi, > > > > On 7/16/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > > > On Mon, 9 Jul 2007 19:20:57 -0300 "Andre Magalhaes" <[EMAIL PROTECTED]> > > > babbled: > > > > > > > Hey Raster, > > > > > > > > On 7/9/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > > > > > On Fri, 6 Jul 2007 18:00:08 -0300 "Andre Magalhaes" > > > > > <[EMAIL PROTECTED]> babbled: > > > > > > > > > > > Hi all, > > > > > > > > > > > > As this is my first post here, let me introduce myself. I am Andre > > > > > > Moreira Magalhaes, aka andrunko, and I work for INdT in Brazil. > > > > > > > > > > hey andre :) > > > > > > > > > > > Now let's go to the point. I am working on a project that requires > > > > > > that an Evas_Object to have a custom click area. This object is a > > > > > > non-retangular object (a circle for eg) with a transparent > > > > > > backgroung. When i click on the background of this object, if the > > > > > > click was in a transparent area this object shouldn't receive any > > > > > > event. I was investigating the Evas code and i found 3 ways that > > > > > > this could be done. > > > > > > > > > > currently evas doesn't do this. in theory it could - but it doesn't. > > > > > > > > > > > 1 - Change evas_object_was_in_output_rect to always return 0 if the > > > > > > rect is in a transparent area of the object (not desired) > > > > > > 2 - Change evas_object_event_callback_call to return a boolean value > > > > > > indicating if the object handled the event and if not, keep sending > > > > > > event to the other objects in the list. If the object handled the > > > > > > event, stop there. This would require a lot of changes. > > > > > > 3 - Change evas_object_was_in_output_rect to check a for a custom > > > > > > "in_output_rect" method on the object, and if this method is set, > > > > > > use it to check if the rect is in output rect. This would require a > > > > > > new function, evas_object_is_in_output_rect_cb_set (or something > > > > > > similar) that could be implemented whenever is needed. If this > > > > > > method is not set, check the clip rectangle as it's done today. > > > > > > > > > > actually i already designed for this. there is an is_inside and > > > > > was_inside method for objects. only line and polygon objects provide > > > > > them and they just return 1 - these CAN be called if a point is > > > > > inside the object rect and the code wants to determine if an event is > > > > > still inside the object based on private object data (eg polygon > > > > > outline, image pixel alpha channel data etc.). right now it basically > > > > > isn't used - but its intent was to be used for this. the problem is > > > > > this is actually relatively slow/expensive to do. you probably also > > > > > want a way of enabling or disabling this level of event processing > > > > > per object to save cost. so we probably need to add an object flag to > > > > > use these methods, if they exist, or disable them (disabled by > > > > > default), then provide methods for image objects at the least - then > > > > > actually use them, if they are provided, and the flag is enabled for > > > > > that object. implementing this won't be too hrd, but it won't be > > > > > trivial. you need to be able to figure otu any x,y co-ord within the > > > > > object and what pixel of the image that may map to based on > > > > > paremeters of the object, then go check that pixel's alpha channel > > > > > (if the image has an alpha channel). for polygon nd line objects you > > > > > need to do some half-plane point intersection math (easy but its order > > > > > (n) where n is the number of sides of the polygon). for lines its > > > > > strange - you might want perfect inclusion, but that's a very small > > > > > space unless its a thick line (doesn't exist currently). for text... > > > > > thats hard as you need to figure out what character is in that x,y > > > > > (that's easy) and then check the character glyph pixels to see if its > > > > > inside... > > > > > > > > > > but anyway - i added this mechanism in at the very start but have > > > > > never used it (or really needed it enough to implement the rest of > > > > > it). > > > > hmmm, i didn't know about this is_inside method, it's similar to what > > > > > > not surprising. it's hidden away for "one day when i might want to use > > > it" :) > > > > > > > i wanted but with some improvements :D. Attached there is a patch to > > > > implement it on evas_object_image and edje, and a callback to > > > > enable/disable it. I didn't like the
Re: [E-devel] Nightly builds - Was: Is this a community project?
On Tue, 17 Jul 2007 10:14:58 +1000 David Seikel <[EMAIL PROTECTED]> babbled: > Attached is the result of a first cut at a nightly build script. Early > days, baby steps, don't pick over the little details. We can start > with the basics and work up to more features later. > > For now I can run this on my boxen while it gets developed further. > Move it to the E servers and volunteer boxen when it's more mature. > > Currently it only compiles stuff that uses autofoo. Some things are > skipped, mostly due to being deprecated or broken and unmantained. > Most of what is skipped is in misc. Everything in e17, misc, and > e_modules is included except for the e17/test and e17/docs directories. can you... put the script in cvs somewhere? tough to talk about something we can't see. > Do we need more information, less information, actual build logs to be > stored somewhere, etc? Throw in e16, eterm, e17/test, and e17/docs > just for completion? personally - i think this needs an explicit list of things to build (and thus the order to build them in). doing it as a user is trivial - just need to do a --prefix=/path/to/user/owned/dir in configure. the rest is just a matter of $PKG_CONFIG_PATH, $PATH, $LD_LIBRARY_PATH then cvs update -dP for I in `cat build-list`; do build.sh; done >& build.log and a build.sh (or a shell func) that runs the autogen.sh, make and make install with a low priority with nice + ionice. the build log doesn't need to be fancy or pretty - just needs to be all the raw output of the whole build. > I think a nightly email to this list would be the most useful, just > stashing the results away on the web somewhere makes it too easy to > ignore. don't even think we need that much - just stashing the results in a web page somewhere is enough > For the curious, I'm modifying easy_e17.sh to do this, as I'm very > familiar with it. I've discussed this with morlenxus, and we have > agreed to add a few things to easy_e17.sh to make it better for this > type of work. > > TODO - > > Remove need to be root/use sudo. > Support things that don't use the autofoo three step. > Add qemu / scratchbox support for hardware / OSs we don't have test > boxen for. > Maybe create .rpm files on RPM based distros and .deb files on Debian > based distros. > > > BTW, while on the subject of automated testing, I've been asked if E17 > supports accessibility stuff. Apparently he wanted to use a particular > automated GUI test system that uses that. As far as I know, we do not > support that. Any thoughts? you will need to be more specific with "supports accessibility stuff". e make no particular efforts one way or another for "accessibility". if something works or not depends on the details of what it does. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Issue with Emotion
On Wed, 11 Jul 2007 13:27:48 +0200 Fabio Strozzi <[EMAIL PROTECTED]> babbled: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > every time I call emotion_object_audio_volume_get(emotion) just after > - or close in time to - emotion_object_play_set(emotion, 0), emotion > (evas? or ecore?) blocks unexpectedly. > The attached file reproduces this behaviour (for me, at least). > > The first argument must be a movie file. Pressing "space" toggles > playback, pressing "v" calls emotion_object_audio_volume_get. If you > press "b", it will call emotion_object_play_set(emotion,0) and then > emotion_object_audio_volume_get, causing the application to hang. > This also happens if you rapidly press "space" and "v" in that exact > sequence. > > I didn't investigate further because I'm quite unfamiliar with Posix > threads and Emotion internals, but IMHO this sounds much like a race > condition. > > Could someone test this? > > Thanks in advance well the app doesn't hang - the xine decoder seems to stop within emotion. something broke recently - crap. i don't know what it is. i need to narrow this down but emotion_test no longer works - rage doesnt work. g. fixed that - now found problem. xine deadlock it seems (within xine if you start and stop play and then query a parameter like audio volume while it is starting playing - not just opening). -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On Wed, Jul 18, 2007 at 12:56:17AM -0300, Gustavo Sverzut Barbieri wrote: > On 7/18/07, Brian Mattern <[EMAIL PROTECTED]> wrote: >> On Tue, Jul 17, 2007 at 06:15:51PM -0300, Gustavo Sverzut Barbieri wrote: >> > Notice that edje property is no_mouse_grab, because then we can keep >> > compatibility with existent .edj files. >> > >> > I don't like evas_object_mouse_grab_set() very much, it looks like >> > mouse will be immediately grab, which is not the case. But I don't >> > have any better word for that. >> >> > + EAPI void evas_object_mouse_grab_set >> (Evas_Object *obj, Evas_Bool no_mouse_grab); >> > + EAPI Evas_Bool evas_object_mouse_grab_get >> (Evas_Object *obj); >> >> >> Maybe evas_object_auto_grab_set(Evas_Object *obj, Evas_Bool auto_grab) ? >> (or _mouse_auto_grab_) > > it's not that better... other suggestions? > > can_grab_mouse? That makes even less sense. Maybe "grab" isn't a good choice. Really we're picking between two alternate methods of presenting mouse events. So, maybe evas_object_mouse_event_mode_set(obj, EVAS_EVENT_MODE_X) I'm at a loss atm as to what the two names should be though. (Maybe ORIGINAL and RAW... not happy with those...) > > >> Whatever we call it, the second parameter should NOT be no_*. It should >> be TRUE for "grab the mouse", and simply default to TRUE. > > yes, I agree, but how about edje files? Can I rely on people updating > their edje files? Remember that edje files will not be recompiled > since they have not changed, users may issue "make clean" to get it > updated. For edje files, you either need compatibility code (where the version is checked on load and the value is set properly), OR you can just make the edje option 'negative' (it doesn't have to be the same as the c api). However, with the above suggestion for an API, the 'original' mode would just be equal to 0. Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel