Re: [E-devel] E CVS: libs/eet raster
On Sun, 20 Apr 2008, Enlightenment CVS wrote: Enlightenment CVS committal Author : raster Project : e17 Module : libs/eet Dir : e17/libs/eet Modified Files: configure.in maybe NEWS or Changelog should mention the release, no ? 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
Re: [E-devel] Evas transforms/filters/etc.
So, what kind of api should be provided for 'filters for evas objects'? And how can general/loadable such filters be defined and obtained? Gustavo has given one possible suggestion (still needs the issue of general/loadable ones addressed, and may want to replace the 'set' with an 'add', or even an 'append/pre-pend' and others). Does anyone else have another? No other suggestions or comments yet? :) Before I suggest some possible approaches here (and frankly I'm torn between several - ranging from conservative to fairly radical ones), let me make some further comments on this.. just for fun. I've mentioned before that one needs to have strict typing of 'filters' that operate on evas objects, and that one type that can be taken to apply to all renderable objects are those filters which operate on image surfaces - ie. which are functionally equivalent to first rendering the obj to a buffer surface and then applying the filter to that (and eventually compositing the buffer surface to a dst surface). Let's agree to call such filters surface-filters. We know several such that are commonly used - blur, bumpmap, convolution kernel derived, simple color modifiers, etc.. and one other kind that's often found are the simple 2D geometric-transform ones. We can define these from a given 3x2 matrix (normally used to define affine transformations), or more generally from a 3x3 matrix (for projective transforms of 2D space). However, given say a 3x2 matrix, one can also define geometric transformations on 'vgfx' kinds of 'objects' by operating on their vertex data, and lets call such kinds of filters vertex-filters. If we're given a 'vgfx' kind of evas object - say a polygon or a rectangle, we may then consider 'geometric transforms' (from say a given affine 3x2 matrix) via these two different kinds of filters, the surface and the vertex ones... The results will not always be the same. Should one also consider these kinds of vertex filters for evas objects which have some 'vector' aspect (eg. for rect objs, or for poly objs)? And if so, how should one express these two different types of filters via the api? You might say: No. Who cares... evas is mostly a raster based canvas lib.. or at least that's the most commonly used object - image objects... Unfortunately, evas image objects are not really like raster surfaces at all.. in fact, they behave more like rectangles which have been given an image as a fill pattern (or fill texture) which is set to a repeat extend (or spread) mode by default! So, should one consider these kinds of vertex filters in evas, or not? I'll give you my answer to that: NO, I don't think one should. I don't think they're needed or desirable for most of the things that people want to do (but I won't go into details as to why I say that for now). PS. Here's a distantly related issue though: One of the most common things that people want to do with images is to rotate them (possibly in a 3D perspective way), flip them, blur them, etc. How can one make it easy to express such things for evas image objs (with filters) via the api? I'll give you my own partial answer to this as well - an answer that isn't really mine but rather is from a suggestion due to raster, and that is to: Add a fill policy flag with two possible values, say FILL_POLICY_EXTEND and FILL_POLICY_SCALE. The former (extend) is the current behavior, wherein an image is scaled to the specified fill size and then that fill extends (from the specified fill origin) to cover the image object size (repeating only for now), ie. image objects act like rectangles with the image itself as a fill pattern for the rect (the object region). The latter (scale) fill policy will ignore any fill properties and instead the image will be scaled to fill the image object size, ie. the image object now acts like a surface which has the image scaled to fit. This makes it very easy to deal with most uses of images where one wants to simply transform an image in a certain way, and not worry about fill pattern sizes, transforms, extend modes, origins, and also object transforms - ie. when one wants an image obj to be like an image, not like a rect with an image as fill texture. For example, if you wanted to say rotate an image, or just blur an image, ... then with the current semantics of image objs you'd have several ways of setting a filter on the image obj and/or on the fill, as well as setting particular fill sizes and origins and obj sizes... all cumbersome and inefficient.. one really just wants to transform or blur the image obj and be done with it - and that's what such a new fill policy would allow.. for image objects to behave like image surfaces (subject possibly first to a scaling of the image to the object size). - This SF.net
Re: [E-devel] Evas transforms/filters/etc.
PS. Here's a distantly related issue though: One of the most common things that people want to do with images is to rotate them (possibly in a 3D perspective way), flip them, blur them, etc. How can one make it easy to express such things for evas image objs (with filters) via the api? I'll give you my own partial answer to this as well - an answer that isn't really mine but rather is from a suggestion due to raster, and that is to: Add a fill policy flag with two possible values, say FILL_POLICY_EXTEND and FILL_POLICY_SCALE. The former (extend) is the current behavior, wherein an image is scaled to the specified fill size and then that fill extends (from the specified fill origin) to cover the image object size (repeating only for now), ie. image objects act like rectangles with the image itself as a fill pattern for the rect (the object region). The latter (scale) fill policy will ignore any fill properties and instead the image will be scaled to fill the image object size, ie. the image object now acts like a surface which has the image scaled to fit. This makes it very easy to deal with most uses of images where one wants to simply transform an image in a certain way, and not worry about fill pattern sizes, transforms, extend modes, origins, and also object transforms - ie. when one wants an image obj to be like an image, not like a rect with an image as fill texture. For example, if you wanted to say rotate an image, or just blur an image, ... then with the current semantics of image objs you'd have several ways of setting a filter on the image obj and/or on the fill, as well as setting particular fill sizes and origins and obj sizes... all cumbersome and inefficient.. one really just wants to transform or blur the image obj and be done with it - and that's what such a new fill policy would allow.. for image objects to behave like image surfaces (subject possibly first to a scaling of the image to the object size). I should've added that such an addition is not, strictly speaking, required... especially if one restricts filters/transforms to be of surface types - it'd just make things a bit simpler and more efficient for everyone. - 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] Imlib2 patch
On Wed, 16 Apr 2008 19:50:24 -0400 Jose Gonzalez [EMAIL PROTECTED] wrote: Dariusz Knociński wrote: [...] Strictly speaking, this is still incorrect. The reason being that the map-range functions are doing an initial interpolation in rgb colorspace. It should be doing all of the interpolation in hsv color space, not partly in rgb space then the rest in hsv one. Yes. I know, function MapHsvaRange working very not efficient, but I have not spare time for corect this, at the current time I think :-) Regards -- Dariusz Knociński - 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] [PATCH] more works and fixes for wallpaper fetcher
On Sat, Apr 12, 2008 at 7:58 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: at first we could write a C app that php would execute to generate it, just generate and output it to STDOUT and it would do for web, but really, if someone take some time to write php bindings for eet basic, we'd start to rock! I have no idea about PHP bindings, but I can do Perl ;) Here are the Perl bindings for basic Eet: http://chady.net/projects/eet-perl For now it can only encode and read basic datatypes: strings and numbers. Maybe later more work can be done to support more functionality. If someone wants to give it a spin and offer your suggestions/improvements it would be appreciated. Regards, -- Chady 'Leviathan' Kassouf http://chady.net/ - 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-20 07:09:31 -0700
Build log for Enlightenment DR 0.17 on 2008-04-20 07:09:31 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: ecore_li http://download.enlightenment.org/tests/logs/ecore_li.log engage http://download.enlightenment.org/tests/logs/engage.log 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, 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, 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, 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] Imlib2 patch
Kim Woelders wrote: Dariusz Knociński wrote: Hi All, I wrote new version of some procedures in Imlib2 library and attached patches for that mail. In file color-helpres procedures : void __imlib_rgb_to_hsv( int r, int g, int b, float *h, float *s, float *v ); void __imlib_hsv_to_rgb( float h, float s, float v, int *r, int *g, int *b ); I have changed the range of parameters hue from 0-100 to 0-360, and saturation and value from 0-100 to 0-1. This is correct to last version of documentation on the web page. In file grad.c procedures : void __imlib_MapRange( ImlibRange * rg, int len ) void __imlib_MapHsvaRange( ImlibRange * rg, int len ) I have changed internal variable inc from: inc = ((ll - 1) 16) / (len); to: inc = ((ll - 1) 16) / (len-1); This patch repair bug for small values of parameter len, for example from 2 to 16. And I apply two small screenshots of application imlib2_colorspace befor and after patch. The patch applies/compiles cleanly and seems to fix the problem in imlib2_colorspace - haven't checked beyond that. I'll commit this if there are no objections and noone beats me to it :) On second thought - This might break stuff that relies on the old behavior. Maybe the documentation should be changed in stead? raster? /Kim - 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] EFL error handling (was: checking a part's type?)
On Fri, Apr 18, 2008 at 11:01 AM, Michael 'Mickey' Lauer [EMAIL PROTECTED] wrote: We could put checks like this in edje_object_part_swallow. But I can't help to think was programmed to work this way for a reason I ignore. All ELFs are written in this way, without error checking and reporting, i think it's for performance reason and I like it :) I sincerely hope that this was an ironic statement. The complete lack of error handling in the EFL (well, apart from image loading) is dooming like the sword of damocles. I'm afraid as EFL gets more popular this will be a _major_ hindrance for professional adoption and I'd really like us to revisit this before it's too late (read: stable APIs). I very much agree with Mickey, as I said before. While I do like the library not breaking for minor purposes, I think that most silent ignore of errors is bad. I'd like to see most of the calls to return at least a boolean with Yes/No. However I _REALLY DOUBT_ someone from core will have the time to go through the API and change methods to use that, so we could find out a newbie that wants to contribute, this is a good way to get started! Someone would like to try? This also holds for bindings, at least proto/python-efl would need to be adapted to check for such errors. PS: Evas and some other parts have magic checks on library entry points, they can be configured by setting MAGIC_DEBUG (on by default) and then using env-vars EVAS_DEBUG_SHOW and EVAS_DEBUG_ABORT. So this kind of check _IS_ already done in some parts of the code, is not about blindly going and replace all functions to return Evas_Bool. -- 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] R: Re: R: checking a part's type?
On Fri, Apr 18, 2008 at 9:25 AM, Cedric BAIL [EMAIL PROTECTED] wrote:
On Fri, Apr 18, 2008 at 2:05 PM, andres [EMAIL PROTECTED] wrote:
All ELFs are written in this way, without error checking and reporting, i
think it's for performance reason and I like it :)
We can simply modify the function to return 1 on success or 0 on error
*poker face*
I see you rational, well measured idea and raise you a loony wiki article:
http://wiki.enlightenment.org/index.php/Edje_Interface_Specification
In all seriousness if there is love for my idea I commit to implement it.
If there isn't, I will be more than happy with Dave's solution.
Their is. It will be a real win if we can just check if an Edje_Object
really provide all the needed stuff. We could even improve it as some
type of declaration inside the EDC like the html DOCTYPE (In case we
want to check during theme creation). So I am definitevely for number
2 (A parser + compiler and welcome .edt inside Edje). It's sound
really like a good idea to me.
I like theme-creation checking. What we should do is have a standard
to write such requirements and make tools to check for it. I see that
Entrance, at least, have such thing as a table.(see README,edje).
While fields separators are open, the required fields are:
PART;part_name;state1,state2,..,stateN;TYPE;Required;Desc
SIGNAL:signal_name;signal_source;Required;Desc
This is easy to parse in any language and easy to read without any
special tool. We can also write simple awk/python/sed scripts to
output this in nice formated tables (html, ascii) for inclusion in
documentation.
One could like to have it as edje, doing blocks, but I think it will
be harder to write such parsers, so it doesn't worth the pain:
part {
name: part_name;
type: RECT;
required: 1;
desc: free form text;
}
signal {
name: sig_name;
source: *;
required: 1;
desc: free form text;
}
--
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] RELEASE: Eet 1.0.0
On Sun, Apr 20, 2008 at 3:42 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: Eet 1.0.0 (Alpha version 0.9.99900) is now available. Please see: http://enlightenment.org/p.php?p=about/efl/eet for more information. Excellent! Here we go -- 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] Evas transforms/filters/etc.
On Sun, Apr 20, 2008 at 5:19 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: PS. Here's a distantly related issue though: One of the most common things that people want to do with images is to rotate them (possibly in a 3D perspective way), flip them, blur them, etc. How can one make it easy to express such things for evas image objs (with filters) via the api? I'll give you my own partial answer to this as well - an answer that isn't really mine but rather is from a suggestion due to raster, and that is to: Add a fill policy flag with two possible values, say FILL_POLICY_EXTEND and FILL_POLICY_SCALE. The former (extend) is the current behavior, wherein an image is scaled to the specified fill size and then that fill extends (from the specified fill origin) to cover the image object size (repeating only for now), ie. image objects act like rectangles with the image itself as a fill pattern for the rect (the object region). The latter (scale) fill policy will ignore any fill properties and instead the image will be scaled to fill the image object size, ie. the image object now acts like a surface which has the image scaled to fit. This makes it very easy to deal with most uses of images where one wants to simply transform an image in a certain way, and not worry about fill pattern sizes, transforms, extend modes, origins, and also object transforms - ie. when one wants an image obj to be like an image, not like a rect with an image as fill texture. For example, if you wanted to say rotate an image, or just blur an image, ... then with the current semantics of image objs you'd have several ways of setting a filter on the image obj and/or on the fill, as well as setting particular fill sizes and origins and obj sizes... all cumbersome and inefficient.. one really just wants to transform or blur the image obj and be done with it - and that's what such a new fill policy would allow.. for image objects to behave like image surfaces (subject possibly first to a scaling of the image to the object size). I should've added that such an addition is not, strictly speaking, required... especially if one restricts filters/transforms to be of surface types - it'd just make things a bit simpler and more efficient for everyone. Jose, I'm running out of time to reply to all of these ideas, I expect to get back some development time after the company I started start to calm down on the real world side (we were getting infrastructure and like, phone, network, ...). But I really fear to loose all these ideas. I know we have mail archive, but it would help a lot if one (you, others) could move this to Wiki and do some structure, much like Dresb and I did for some ideas. Then people can check when we're about to start working on it. What do you think? -- 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] Evas transforms/filters/etc.
On Mon, 21 Apr 2008 01:04:55 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On Sun, Apr 20, 2008 at 5:19 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: PS. Here's a distantly related issue though: One of the most common things that people want to do with images is to rotate them (possibly in a 3D perspective way), flip them, blur them, etc. How can one make it easy to express such things for evas image objs (with filters) via the api? I'll give you my own partial answer to this as well - an answer that isn't really mine but rather is from a suggestion due to raster, and that is to: Add a fill policy flag with two possible values, say FILL_POLICY_EXTEND and FILL_POLICY_SCALE. The former (extend) is the current behavior, wherein an image is scaled to the specified fill size and then that fill extends (from the specified fill origin) to cover the image object size (repeating only for now), ie. image objects act like rectangles with the image itself as a fill pattern for the rect (the object region). The latter (scale) fill policy will ignore any fill properties and instead the image will be scaled to fill the image object size, ie. the image object now acts like a surface which has the image scaled to fit. This makes it very easy to deal with most uses of images where one wants to simply transform an image in a certain way, and not worry about fill pattern sizes, transforms, extend modes, origins, and also object transforms - ie. when one wants an image obj to be like an image, not like a rect with an image as fill texture. For example, if you wanted to say rotate an image, or just blur an image, ... then with the current semantics of image objs you'd have several ways of setting a filter on the image obj and/or on the fill, as well as setting particular fill sizes and origins and obj sizes... all cumbersome and inefficient.. one really just wants to transform or blur the image obj and be done with it - and that's what such a new fill policy would allow.. for image objects to behave like image surfaces (subject possibly first to a scaling of the image to the object size). I should've added that such an addition is not, strictly speaking, required... especially if one restricts filters/transforms to be of surface types - it'd just make things a bit simpler and more efficient for everyone. Jose, I'm running out of time to reply to all of these ideas, I expect to get back some development time after the company I started start to calm down on the real world side (we were getting infrastructure and like, phone, network, ...). But I really fear to loose all these ideas. I know we have mail archive, but it would help a lot if one (you, others) could move this to Wiki and do some structure, much like Dresb and I did for some ideas. Then people can check when we're about to start working on it. What do you think? I think that's an excellent idea. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] Evas transforms/filters/etc.
On Mon, Apr 21, 2008 at 1:04 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Jose, I'm running out of time to reply to all of these ideas, I expect to get back some development time after the company I started start to calm down on the real world side (we were getting infrastructure and like, phone, network, ...). But I really fear to loose all these ideas. I know we have mail archive, but it would help a lot if one (you, others) could move this to Wiki and do some structure, much like Dresb and I did for some ideas. Then people can check when we're about to start working on it. What do you think? Ah, I'd like to write a small prototype of this idea. It would get an ARGB buffer, get the filters as a linked list/array negotiate buffers and then process, giving the output as another ARGB buffer to check the results. Then modify this to add hardware accelerated surfaces (OpenGL). Filtes would be rotation, shear and blur since they're easier to work and can do lots of the simulation. But if someone feels in the mood to do so before, keep me informed. -- 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
