Sebastian Dransfeld wrote: > Nick Hughart wrote: > >> dan sinclair wrote: >> >>> On 2-Aug-08, at 1:40 AM, Nick Hughart wrote: >>> >>> >>>> Vincent Torri wrote: >>>> >>>>> On Sat, 2 Aug 2008, dan sinclair wrote: >>>>> >>>>> >>>>> >>>>>> I'd say you're so eager to release something you're not thinking about >>>>>> the impression it gives. Changing things in a pre-1.0 is fine and >>>>>> expected. Releasing a 1.0 and then breaking it or making major changes >>>>>> a few months down the road is a very bad impression. >>>>>> >>>>>> >>>>> I don't think that if we release a 1.0 soon, the next the next major >>>>> release wiil be out in a few month. It will follow the same release >>>>> process (some years) >>>>> >>>>> >>>> The problem is, the two issues that have come up that are being >>>> considered as blockers are things that may affect how many people >>>> want to use the EFL. So waiting 3-4 years after a disappointing >>>> release may just push people away. We should at least try to address >>>> the shortcomings now or people will either have to wait years for the >>>> new release or get a release so soon that they have to readjust >>>> everything. Either way, I'm sure they won't be happy. >>>> >>> It all comes down to when you're doing the 2.0 release. If you do a >>> 2.0 release in a few months it looks like we just rushed a 1.0 out the >>> door to say we had a 1.0. Major releases should last a few _years_. If >>> we're seriously considering ripping out Embryo in a few _months_ >>> that's a pretty good sign it isn't ready to be released yet. >>> >>> If we know we're going to rip out Embryo and we push out Edje with >>> Embryo scripting just to remove it in the next release it isn't going >>> to make people happy. They'll have to port all their themes to the new >>> scripting language. >>> >>> We're better to wait until we have a foundation we want to work from >>> to get there. >>> >>> >>> >>>>>> You're releasing something before it should be released just to give >>>>>> the impression of a 1.0 for something that isn't 1.0. That leaves a >>>>>> worse taste as a developer then holding off the release until we're >>>>>> pretty sure what we've got will be it for the long haul. >>>>>> >>>>>> >>>>> Explain why you think that current efl can't be considered as 1.0, >>>>> please >>>>> >>> I never said the EFL in general wasn't ready for a 1.0. I'm >>> specifically talking about Embryo as we don't know it's future. Ecore >>> could probably be released once ecore_data is removed and we could do >>> a point release the splits it into separate packages. Evas, I don't >>> follow the Evas discussions so I have no idea. Edje needs the Embryo >>> question asked. Efreet could probably go as the API is stable and we >>> fixup any caching issues in a point release. e_dbus, no idea don't use >>> it. Eet is already 1.0. >>> >>> What this all comes down to, and what the major blocker for most of >>> this is, is Eina. Pretty much everything in CVS will end up depending >>> on it. Let's push to get that as a 1.0 first. >>> >>> >>> >>>>> It seems that you have the same opinion than raster has about >>>>> enlightenment, that is enlightenment will be 1.0 when there will be >>>>> no more improvements he will be able to think about. >>>>> >>>>> >>> No, I don't think that. I just think picking an arbitrary library is >>> silly. We should think about what needs to get released and what has a >>> stable API. >>> >>> >>> >>> >>>>> What the problem with doing releases ? It helps packagers and users, >>>>> people that use commercially the efl are satisfied because they know >>>>> they have a solid base set of libs they can work with. >>>>> >>>>> >>> There is nothing wrong with doing releases. I just don't see the point >>> of releasing for the sake of releasing when we already know we're >>> going to break the API. >>> >>> >>> >>>>>> If you want to push something out the door, what about Efreet, or >>>>>> getting Eina done then doing Ecore. We don't have to start with an >>>>>> Embryo release. We don't have to push Embryo until we're ready to push >>>>>> Edje. Pushing Edje has to wait until we push Evas (which also has to >>>>>> wait for Eina). >>>>>> >>>>>> >>>>> Heh, I would like to release all the efl as 1.0 (maybe after the >>>>> eina move). Then, in a few years push the 2.0 release (for e18 ?). >>>>> There are *lots* of stuff to do for a 2.0 release for evas and edje >>>>> (i don't really know for ecore). About evas, you see the discussion >>>>> between mainly Jose, Jorge and raster. About edje Gustavo told me >>>>> that raster has huge plans about it. So why not writing edje 2 with >>>>> these plans and with another scripting language than embryo when >>>>> thee plans will be known a little bit more ? >>>>> >>>>> >>>> I've made a similiar argument for EDJE, push it as is with embryo and >>>> don't expect the flash/silverlight/etc crowd to jump on board right >>>> away and make user interfaces. Use EDJE for what it can do now and >>>> then in the future we can do a 2.0 release that adds the extra >>>> stuff. But by that time, people may have throughly invested in >>>> embryo and it may cost them quite a bit to change all that. >>>> >>>> >>>>> About efreet, I agree too that it should be out after the eina move. >>>>> >>>>> >>>> I'd like to see the icon caching improved personally since right now >>>> it might as well not even be there, doesn't produce any significant >>>> speedups. >>>> >>> Isn't this just disabled at the moment? Sebastian would know for sure. >>> >> AFIAK it's in there, but he changed the system quite a bit. It is using >> a list to store the cache now, but it's only meant to include the most >> used icons iirc. Maybe it is disabled though, but I think he replaced >> it, not just disabled. >> > > There is an icon cache with 100 icons. Latest used icons are prepended > to the list. If an icon is in the cache, the cache does help. > > So for a scenario where a user only triggers efreet_icon through f.ex. a > small favorite menu in e17, the cache is good. But if the modules menu > is accessed it will blow the cache. So the cache should have a method to > weigh which icons are most used. > For one, why is it limited to 100 icons? I can see this overflowing fairly easy in E as it is now and this doesn't even include mime icons. With my tests I haven't seen the cache come into play at all, the time between searching for icons once and searching for that same set again results in nearly identical times. This is when searching for mimetype icons and unless the cache doesn't cover the searching this does I'd have to disagree that it has any useful effect. There aren't that many mimetypes in /usr/lib either so I don't think I'm exceeding the 100 icon limit in this case and actually this case should shine with this caching system. > Sebastian > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > 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 Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
