On Thu, 20 Oct 2011 08:38:18 -0200 Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> said:

> I'd agree with discomfitor about his points. There are many widgets that are
> about different themes to the same concept and could be simplified (toggle,
> check, ... Selection of items...)

toggle and check are actually different. check has label_icon+ on/off state.
toggle has 2 named states (a, b) with label+icon. check has no concept of named
states at all. you could make a superset of it and roll it into check i guess...

> As I said many times I'm against eina-object. Not able to explain it in
> details from a phone, but I can try later if needed if no one else will
> 
> Last but not least I want some helpers in ecore_evas to manage lifetime of
> timer, idlers and so to an Evas_Object. Do it now or later?

later, but that was the point of eina-object in the end. to tie together ALL
these things. also provide a "indirect ptr" ref no longer direct reffing ptrs
(index+table) and ability to have properties, methods and multiple inheritance.

> On Thursday, October 20, 2011, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> > On Thu, 20 Oct 2011 04:04:38 -0400 Mike Blumenkrantz <m...@zentific.com>
> said:
> >
> >> On Thu, 20 Oct 2011 15:51:01 +0900
> >> Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> >>
> >> > Hey guys. time to talk of our next release cycle. this meant 1.1 of
> most efl
> >> > libs (and 1.5 for eet). this means we have lots of bug fixes and new
> >> > features here. i'm currently talking about:
> >> >
> >> > eina
> >> > evas
> >> > ecore
> >> > embryo
> >> > edje
> >> > efreet
> >> > e_dbus
> >> > eeze
> >> >
> >> > now coming AFTER this we want elementary to go 1.0 - so this is the
> last
> >> > change we have to "break api's" in elementary.
> >> >
> >> > e17 itself is an app so api is "not relevant" here, but we also want to
> work
> >> > full steam ahead on e17 release too.
> >> >
> >> > what i am proposing is that everyone finish their "pending work" for
> >> > everything above in the first list and get all pending changes to elm
> >> > upstream asap as well. i want to call a "2 week merge window" for core
> efl
> >> > (above) and then 2 weeks of bug fixing, then release. merge window
> starts
> >> > next monday (24th of october). that means from the 7th to the 20th no
> new
> >> > features can be added to trunk, only bug fixes.
> >> mmm this may be tough for eeze since supposedly users are having a lot of
> >> trouble with eeze mounting in e17 and I can't reproduce their problems.
> It
> >> would be great if I had some edevs working with me to test this so I can
> get
> >> bugs out.
> >
> > i haven't spotted bugs of late...
> >
> >> > i am opening the floor to anyone who thinks other libraries in svn
> should
> >> > also get the 1.0 treatment too - ethumb? epdf? emotion?
> >> I could prep esskyuehl for a release if people think it would be useful
> to
> >> have as a released library. I only have one or two trivial things to add,
> and
> >> it has been otherwise unchanged since May/June.
> >
> > no - leave that. it's still in proto and it actually isn't used by any of
> > e/efl elements currently, so no rush there.
> >
> >> >
> >> > some notes: eina will not have any eina-object model enabled for 1.1.
> evas
> >> > will have all the evas-gl stuff disabled in build and install for 1.1
> as its
> >> > not stable yet. any more notes people have to throw in?
> >> >
> >> I think if we work on an elm release after 1.0 (which would be starting
> in
> >> December?) it will be a big mistake. Elm right now is a giant
> clusterfuck, so
> >> we should probably do the following instead of going straight for the big
> 1.0:
> >>  * widget/feature freeze: NO MORE WIDGETS. PERIOD. there's too damn many
> as it
> >>    is and QA on them is terrible.
> >
> > well this is all part of 1.0 path. we can just ignore going 1.0 forever if
> u
> > want and not do this... :)
> >
> >>  * fix all existing widgets to work as intended: I say this in the
> general
> >>    sense as there are tons of widget api functions which do nothing, have
> >>    unintended side effects, or break the universe altogether.
> >
> > list please. (of api's not working(right)).
> >
> >>  * review all existing widgets and apis: we may decide that some widgets
> suck
> >>    and should be removed. remember that anything we ship with 1.0 is a
> widget
> >>    that we have to support FOREVER. so, for example, this means that
> >>    diskselector (a TERRIBLE widget imo) is something that will need to be
> >>    maintained for years to come. it also means that widget features must
> be
> >>    maintained. if a widget has stupid features, they should be removed.
> >
> > list please. (widgets we shouldnt have).
> > diskselector: actually api-wise its ok. it's IMPLEMENTATION is very much..
> to
> > be desired. this means we can release with it and fix its internals at a
> future
> > point.
> >
> >>  * finish all important TODO items for remaining widgets: there's tons of
> >>    these so I won't bother going into detail, but I think everyone can
> think
> >> of at least a few items which belong here.
> >
> > i need to finish up some performance issues in elm_factory.
> >
> >>  * merge similar widgets: anchorblock and anchorview are two separate
> widgets
> >>    which are essentially the same. why are they not one widget??
> >
> > sure. they can be merged. or get rid of anchorview entirely.
> >
> >>  * finish genlist/gengrid/factory merge: this has been talked about
> forever,
> >>    but it needs to actually get done. afterwards, genlist and gengrid
> >>    apis/internals need to be updated so that they match.
> >
> > no way is this ever going to happen any time soon. not for years. i‘d say.
> so
> > its not worth getting worked up about. leave genlist/grid as is for now.
> >
> >>  * rewrite MOST elm edc: if anyone has ever read through this, the
> majority is
> >>    pretty awful. additionally, we have great edje features now like group
> >>    inheritance which could cut down the size of the default theme
> >> considerably.
> >
> > this is really an optional thing. but i'd actually like to revamp all of
> e17
> > +elm theme stuff anyway - but that'd push off being able to do releases by
> many
> > months.
> >
> >> Looking at the scope of these items, I'd say it's at least a couple
> months'
> >> work to get elm in the kind of shape necessary to consider even a basic
> api
> >> freeze, after which point it will require even more time to fix bugs
> within
> >> the freeze.
> >
> > reality is we need to freeze is much sooner than that.
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler)    ras...@rasterman.com
> >
> >
> >
> ------------------------------------------------------------------------------
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Ciosco Self-Assessment and learn
> > about Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-dev2dev
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> 
> -- 
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Ciosco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ras...@rasterman.com


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to