On Sat, 7 Aug 2010 08:35:10 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
>ok quick call out. > >eina, evas, embryo, ecore, edje, efreet, e_dbus, ethumb, eeze > >thats current plan for 1.0.0 alpha (elementary will follow a bit later). > >other than 11. xrandr patches i know are kind-of-pending (yes - reviewed and >sent back for changes), tom was going to do some munging on textblock api, and >cedric had lofty claims of an improved edje format. anyone got any list of >things that would stop a 1.0.0 alpha right now (alpha means we can just ignore >our existing bugs right now). > >so list of blockers: > >tom - evas textblock api changes (and edje_entry changes to match) >me/leif - ecore-x xrandr 1.3 changes >cedric - edje format changes > >general - i'd like to have efl have a single consistent formatting. we can't do >this always by human means - thus the attempts to have it automated. i'd like >to at the least make sure public headers are clean and well formatted. the >uncrustify stuff has been that attempt. there are teething problems, but i >think this can work nicely once the original code is tuned just a little and >then the formatting scripts applied (ie runs well on eet at the moment. eina >needs some fixups - and then its all the rest). > > Hi, I am in favor of this if possible, but I do have a little work that I would like to do on ecore_con prior to 1.0, though I do not believe it would be anything which would be considered a "breakage". Mainly I would like to refactor the bitfield enum mess that is currently there into something sane, and then (depending on how much work it actually turns out to be) add an option to do receive()/send() in threads which report back to main loop for increased throughput. Aside from this, I would appreciate it if someone (probably cedric since he is familiar with gnutls/openssl?) could look over my recent addition of ssl certificate support to ecore_con just to make sure that it is "good." Lastly, if there is anyone with some time on their hands I would greatly appreciate it if I could get a code review on eeze. To date I have 0 reported bugs, it does not leak, and it seems to work perfectly as a replacement for Hal in e's temperature and battery modules (the only places I have implemented its functionality), but it is possible that a quick readthrough by another set of eyes may reveal something that I am not aware of :) -- Mike Blumenkrantz Zentific: Our boolean values are huge. ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
