On Mon, 11 Dec 2017 13:11:53 +0900 Jean-Philippe André <[email protected]> said:
> Hi, > > > Just a word about panes and other new widgets: yes they got broken at some > point but should be fixed now that the "EO" theme API has been merged. > I think most of the existing Efl.Ui.Xxx widgets should soon become usable. > But I am not ready to commit yet for all of elementary (note: the model API > is still in flux and the [gen]list widget isn't here yet). > > > @netstar proposed branching off to EFL 2 and no one responded to that (as > far as I can tell). I just dopn't think that'd be good for the project as a while, no matter that pain of having to keep legacy and eo/interfaces going at once. > I very very much wish we had taken that route as the most painful part in > this interfaces rework is to keep legacy working. we are trying to do: https://www.youtube.com/watch?v=B_1bAnLqlMo yup. it's hard. :) it would have been easier to start fresh from the code we have and just nuke what we are not keeping. but as you say below, there are reasons. > Unfortunately we have reasons for not branching off, as follows: > - We need the existing ecosystem for testing (E, apps, Tizen, etc...). > Breaking compilation or runtime or existing apps would be a huge PITA. > Having a separate .so file (libefl.so.2) would mean a lot less > out-of-the-box testing. > Yes, we break stuff in legacy, but this is by accident, not by design. I > hope it is clear that we are still trying hard to keep things in order. > - We expect the existing ecosystem to progressively adapt to the EO API, by > modifying a UI component here and there, adding a new view or whatnot in > the application, etc... We don't expect an immediate port of existing > legacy apps to EO-only API. it likely will be a multi-year port for apps. certainly for enlightenment it will be a long long long path. > OTOH when it comes to bindings (Lua, C++, C# for now), everything is new, > so legacy doesn't really matter. > Cedric mentioned to me a couple of times how long it took large projects > using Qt4 to finally move on to Qt5. So we're trying to avoid that > bottleneck. > > > I would very much like releasing at least something. Maybe the distinction > between ALPHA and BETA is a good idea. (BETA for eo, eolian, ecore, and > ALPHA for evas, edje, elm). efl/interfaces is a mix of both. > Then we can commit to stop changing those "BETA" API's unless it's > absolutely necessary (unlike a lot of the changes happening now in the > interfaces). > As for specific APIs we can also make use of @beta in EO. > > > Best regards, > > > PS: I say "EO" here as I heard about the idea of calling this API the > "unified interface" (whilst I like the name, it boils down to UI and UI > means user interface^^). > > > On Mon, Dec 11, 2017 at 9:46 AM, Carsten Haitzler <[email protected]> > wrote: > > > On Sun, 10 Dec 2017 23:41:20 +0000 Andrew Williams <[email protected]> > > said: > > > > > Hi, > > > > > > I had not intended to seem like I was giving up - I am pushing hard to > > try > > > and have this discussion as I think it is important. The paragraph you > > > referenced was intending to point out that our mailing list discussions > > do > > > not have an open nature to them so others feel it is not worth > > > contributing. When words like “guarantee” and “zero value” are used can > > you > > > not see how that could be received? > > > > because i have seen history and those words are the truth given history > > and my > > experience. ok "zero value" is like "it's worth a few cups of coffee when > > we're looking at buying a car". not literally zero but very very very low > > value > > compared to the big picture. yes. they are strong words. i feel strongly > > about > > this. are you saying that i am not allowed to feel strongly about this and > > should tone everything down just in case you get discouraged. i have to > > pretend to not feel strongly and be dishonest about my opinion? i expected > > better of you. > > > > i KNOW who wants interfaces in things like c# and a subset is useless to > > them. > > they have to be able to build entire apps with the ui in that language. > > it's > > all of it or not bother. this applies to js, lua and python too. > > > > i also know that even the core is unstable and far from settled. that > > means the > > chances of a break are high. this means that apps cant really use any of > > eo and > > interfaces as the changes of "it will break" are close to 100%. somewhere, > > somehow something will break - even if just 1 or 2 small things, but enough > > where "i upgraded efl and app X now crashes, or doesn't start because > > symbol X > > not found" will be the result. it only takes one small thing to cause > > that. > > > > lots of the core interfaces like on efl loop are not re-using shared > > interfaces > > yet and actually should probably be doing just that. until we implement > > more of > > the higher level AND then stand back and go "there's a design pattern > > there. > > let's unify it under a single interface everyone inherits and shares so > > it's > > consistent" there will be such changes. > > > > i think you're jumping the gun on such a release without the attendant > > warnings > > of "this stuff will break". i have no confidence in what you proposed to > > release as stable as being solid enough to put the label on it you want - > > not > > now or even in a few weeks from now. perhaps in 2 or 3 months, but that's > > about the same timeline for getting all of the "target api set" up through > > ui > > done too as much is being done in parallel. then we'd need ~1 month for a > > release cycle at least. probably longer if we want to expose all these new > > eo > > based things as "stable beta". > > > > it's far more important to get the core lower levels right as everything is > > built on top, than to get leaf nodes in the class tree right... thus why > > they > > would require more conservative attention. > > > > > As I have pointed out before the interface parent ticket has new tickets > > > added faster than we are closing existing ones. I see also that > > completely > > > broken eo widgets are being pushed into master (see efl.ui.panes for > > > example) and abandoned. With that in mind can we realistically expect to > > > release the whole lot in one go this decade? > > > > it has to. it actually has to be done in the next few months. like ~2-3. > > not a > > subset. everything including the ui classes. yes. stuff is there that is > > broken. the panes actually did work. last i knew they worked, then ANOTHER > > change somewhere else in evas broke them, ami fixed them, now they > > re-broke and > > he didn't know. they were not pushed AS broken widgets... > > > > > I will work with the folk I have been chatting with to see if I can pull > > > together the requirements that are driving the desire to start building > > on > > > eo api rather than legacy. > > > > without them chiming in and saying why they want a small subset released > > and > > what they at all intend to build with it... i am sticking to my position on > > this - that it's dangerous to mark as stable (beta stable as you say). > > dangerous for the work being done, dangerous to extending timelines for the > > work as a whole, dangerous to people then using those api's as given the > > past > > it is a nigh guarantee that those api's will have to break. a lot changed > > and > > broke AS interfaces were worked on and we realized we need to do something > > in a > > certain way or need a feature or need to redesign something etc. ... so > > until > > those higher level changes have settled down at least to small things like > > arguing over a property, method or event name... i wouldn't say eo is > > releasable. futures still are not a done thing and they are central to eo's > > core. without them being actually used first by people able to stomach a > > break > > and redesign if it has to happen... chasing a "let's release as stable beta > > some subset of core" is a bit of a pipe dream. > > > > > Andrew > > > On Sun, 10 Dec 2017 at 11:33, Carsten Haitzler <[email protected]> > > wrote: > > > > > > > On Sun, 10 Dec 2017 09:35:05 +0000 Andrew Williams < > > [email protected]> > > > > said: > > > > > > > > > Hi, > > > > > > > > > > Apologies I was not aware of these plans that everyone agreed on. > > Can you > > > > > please point me to this plan? It is very difficult to make a case for > > > > > change without knowing the preceding plan that would need to change. > > > > > > > > that all of eo/efl interfaces is behind the same beta flag until done. > > > > it's the > > > > state you see now. there were and are no plans to pick and choose some > > > > interfaces to release as stable, and some not. at one point we were > > talking > > > > about making just eo stable but then we realized it needed lots of > > changes > > > > and > > > > this has never come up again. > > > > > > > > you want the plan? see the tickets for interfaces. that's the work to > > be > > > > done > > > > and the work done on the interfaces themselves feeds back to the lower > > > > levels > > > > all the time. > > > > > > > > > To require irc logs or ML emails asking for this change is to imply > > that > > > > > we, the community, are serving just this community - I thought we > > were > > > > > looking bigger picture than that. It would be a violation of trust to > > > > paste > > > > > private conversations or concerns into this email chain, perhaps > > those > > > > who > > > > > are in agreement will contribute to this conversation. > > > > > > > > if you're using them as a justification, then they should be quoted > > here. > > > > > > > > > I am confused about what you mean regarding consensus. I have seen no > > > > > discussion bar this about release plans or indeed the plan / > > priority for > > > > > interfaces. If we could publicly discuss or collaborate on that this > > > > would > > > > > be a lot easier. I agree that there has been little discussion on > > this > > > > > > > > that's because it is one blob of work and the "let's release different > > b > > > > its at > > > > different times" is not there because that was not agreed on, otherwise > > > > it'd be > > > > in tickets. > > > > > > > > what was agreed on is what is already there in code and tickets. the > > > > things to > > > > be eoified (well it is a rough list that gets more refined as time goes > > > > on). > > > > it's all behind the same ifdef. ... > > > > > > > > if you want to change this direction and state... you should convince > > many > > > > people it's a good idea. i, so far, am not convinced it is. you'd need > > to > > > > convince more than me too. > > > > > > > > > thread but from your first email it seemed like it would be a waste > > of > > > > time > > > > > discussing so I’m not surprised. This does not detract from the > > number of > > > > > people who have spoken to me that are disappointed we cannot be > > thinking > > > > > about releasing some of our work. > > > > > > > > every time i disagree you seem to take it as a "i give up". so what > > should > > > > i > > > > do" just shut up and pretend to agree? what is the point of a > > discussion > > > > when > > > > it has to become a "let me just lie and not express what i think to > > make > > > > someone else happy"? you expressed an opinion. i expressed a counter > > one. i > > > > believe the value does not justify the cost. i made that clear. > > convince me > > > > otherwise. otherwise this is not a discussion. > > > > > > > > > However if the plan you described is publicly available then I > > apologise > > > > > for the confusion. I can point these individuals to the document and > > we > > > > can > > > > > think harder about what the smallest change could be that provides a > > > > > solution for everyone. > > > > > > > > > > Thanks, > > > > > Andrew > > > > > On Sun, 10 Dec 2017 at 01:09, Carsten Haitzler <[email protected] > > > > > > > wrote: > > > > > > > > > > > On Sat, 09 Dec 2017 13:38:51 +0000 Andrew Williams < > > > > [email protected]> > > > > > > said: > > > > > > > > > > > > > This has become a circular argument, as many do around here, vis: > > > > > > > *) people are asking for us to try and agree on stable areas of > > the > > > > API > > > > > > so > > > > > > > we can start testing it externally > > > > > > > *) we won’t do that until there is proof that people are using > > our > > > > beta > > > > > > > APIs (which are currently unstable). > > > > > > > How can we break this loop? > > > > > > > > > > > > which people where are asking for a release of a small susbet of > > the > > > > api? > > > > > > show > > > > > > me. > > > > > > > > > > > > > I cannot believe that all of the new APIs are completely unstable > > > > until > > > > > > we > > > > > > > release - that is basically a house of cards that we hope one day > > > > will > > > > > > > become rigid. Some of what we have is more mature than other > > things > > > > - but > > > > > > > every single API we add immediately goes into the BETA flag for > > next > > > > > > > release.. > > > > > > > > > > > > you are asking for a change of plans that everyone working on > > > > eo/interfaces > > > > > > agreed on. you have to make your case for that CHANGE. don't tell > > me > > > > > > "people > > > > > > are asking". show me the emails here asking, and from who. show me > > the > > > > irc > > > > > > logs or the phab tickets. i'm not talking about the full release of > > > > what > > > > > > was > > > > > > planned but the subset you mentioned. see above. those changes come > > > > with a > > > > > > cost > > > > > > (locking yourself in). we'd be stupid to pay the cost with no > > evidence > > > > > > beyond > > > > > > your comment "people are asking". not to mention it'd also be > > ignoring > > > > the > > > > > > previous agreement on what to do. > > > > > > > > > > > > until the people working on eo/interfaces can ALL come to a > > > > consensus... > > > > > > nothing is going to change. and there is no input from most of > > them at > > > > this > > > > > > point, and no overwhelming evidence to ignore any input from them > > if it > > > > > > were to > > > > > > come. > > > > > > > > > > > > > If we cannot make any release in the way previously discussed > > then we > > > > > > > absolutely should have some other way of illustrating our > > confidence > > > > in > > > > > > an > > > > > > > API. Therefore an alternative I propose is to add an ALPHA flag > > > > (which is > > > > > > > mostly what BETA feels like at the moment) where new Eo goes and > > > > those > > > > > > > marked as BETA are the classes we feel could be eliciting > > feedback. > > > > > > > This way we are able to show where we know we have not tested as > > > > much and > > > > > > > can show a journey through creation, testing and integration > > into the > > > > > > BETA > > > > > > > area. > > > > > > > > > > > > > > Without this we are just hoping that some day all our classes > > will be > > > > > > > stable so we can roll a release... > > > > > > > > > > > > > > Andrew > > > > > > > On Sat, 9 Dec 2017 at 12:48, Carsten Haitzler < > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > > > On Fri, 08 Dec 2017 19:06:47 -0500 Cedric Bail <[email protected] > > > > > > > said: > > > > > > > > > > > > > > > > > > -------- Original Message -------- > > > > > > > > > > Subject: Re: [E-devel] What are we going to release? > > > > > > > > > > Local Time: December 7, 2017 5:06 PM > > > > > > > > > > UTC Time: December 8, 2017 1:06 AM > > > > > > > > > > From: [email protected] > > > > > > > > > > To: Andrew Williams <[email protected]> > > > > > > > > > > Enlightenment developer list < > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > > On Thu, 07 Dec 2017 13:45:51 +0000 Andrew Williams > > > > > > > > [email protected] > > > > > > > > > > said: > > > > > > > > > > > > > > > > > > > > Without a guarantee of no changes then you don't provide > > > > anything > > > > > > > > stable to > > > > > > > > > > build on top of. It's no different to what we do now. We > > could > > > > just > > > > > > > > say "we > > > > > > > > > > think these interfaces are ok now - you can try using them > > but > > > > we > > > > > > might > > > > > > > > > > still break them" which is is not some special beta > > release. > > > > it's > > > > > > just > > > > > > > > > > providing a "we think its more stable now" assessment. > > > > > > > > > > > > > > > > > > I am thinking of a stronger commitment on our part here. > > > > Basically > > > > > > as I > > > > > > > > said > > > > > > > > > in my email above, if a binding doesn't report a real big > > problem > > > > > > with > > > > > > > > what > > > > > > > > > is under that RC umbrella, then we do not break it. > > > > > > > > > > > > > > > > unless it's "absolutely will not break at all" then it's > > really no > > > > > > better > > > > > > > > in > > > > > > > > the end. > > > > > > > > > > > > > > > > > I am afraid that for a lot of this lower level, we are now > > > > starting > > > > > > to do > > > > > > > > > what we were doing before we release EFL 1.0. Trying to make > > it > > > > > > perfect > > > > > > > > > without having ever spend the time to prepare a proper > > release. > > > > We > > > > > > need > > > > > > > > to > > > > > > > > > focus and get things out. > > > > > > > > > > > > > > > > > > > but still if it's just what you were saying then what apps > > can > > > > be > > > > > > > > written > > > > > > > > > > using those api's - and will they be? > > > > > > > > > > > > > > > > > > EFL apps already exist. They can get migrated to the new API. > > > > That > > > > > > is the > > > > > > > > > main target of this release. > > > > > > > > > > > > > > > > other than some mechanical "sed work" like > > > > s/evas_object_del/efl_del/g > > > > > > ... > > > > > > > > which buys nothing really useful... what is really going to be > > > > done? > > > > > > and > > > > > > > > what > > > > > > > > will this demonstrate to us or anyone else api-wise? not much. > > > > > > > > > > > > > > > > > >> Why does it have to be black and white? releasing does not > > > > > > "guarantee > > > > > > > > no > > > > > > > > > >> changes", it probably does need to guarantee backward > > > > > > compatibility. > > > > > > > > The > > > > > > > > > >> challenge I see with our current situation is that we have > > > > > > published > > > > > > > > "beta" > > > > > > > > > >> which is not even close to stable and now don't have a > > clear > > > > next > > > > > > > > step to > > > > > > > > > >> get people involved. A "release candidate" might be an > > obvious > > > > > > step > > > > > > > > which > > > > > > > > > >> comes as part of a release plan, which is what I wanted to > > > > > > discuss. > > > > > > > > > >> > > > > > > > > > >> what we have is a release candidate so to speak that is > > > > clearly > > > > > > > > showing its > > > > > > > > > >> state - it's not stable. > > > > > > > > > >> > > > > > > > > > >> trying to release something as stable that is NOT (call > > it a > > > > > > release > > > > > > > > > >> candidate or whatever) is just being dishonest. > > > > > > > > > >> > > > > > > > > > >> I think that EFL and our community is in a different > > place to > > > > > > where > > > > > > > > it was > > > > > > > > > >> years before ecore. We should learn from (everyone's) > > > > experience > > > > > > and > > > > > > > > figure > > > > > > > > > >> how to apply that to our current situation. Our current > > > > reality is > > > > > > > > that > > > > > > > > > >> companies with real products want to build on what we > > have. > > > > That's > > > > > > > > pretty > > > > > > > > > >> exciting I reckon. > > > > > > > > > >> > > > > > > > > > >> and they need the full stack done to build them. not just > > some > > > > > > small > > > > > > > > > >> sub-bits. thus i point out what i did already... what apps > > > > with > > > > > > such a > > > > > > > > > >> subset of api's (efl core/loop/net?). they can't even > > build > > > > things > > > > > > > > with > > > > > > > > > >> efl.gfx. they need efl.ui and even then the efl.ui we are > > > > > > proposing > > > > > > > > means > > > > > > > > > >> them losing several widgets they have used before etc. > > ... so > > > > > > that's > > > > > > > > > >> already a sacrifice. > > > > > > > > > > > > > > > > > > No, they don't ! Do not forget that EFL Eo API is compatible > > > > with the > > > > > > > > legacy > > > > > > > > > API and that this is especially done to allow people to > > migrate > > > > their > > > > > > > > > application as time goes. Bits by bits. > > > > > > > > > > > > > > > > they absolutely do. e.g. c#. without the full stack it's > > > > pointless. and > > > > > > > > they're > > > > > > > > not going to migrate... except rewrite in a new language. you > > know > > > > > > that as > > > > > > > > well > > > > > > > > as i do. > > > > > > > > > > > > > > > > > [snip] > > > > > > > > > > > > > > > > > > >> Should we instead figure when we might start releasing and > > > > set an > > > > > > > > > >> expectation to the public? Something like "come back in > > 2019"? > > > > > > > > > >> > > > > > > > > > >> well we hoped to finish in 2016, then by end of 2017 ... > > we > > > > have a > > > > > > > > better > > > > > > > > > >> chance now as people are really focusing on it, but i > > actually > > > > > > suspect > > > > > > > > > >> 2019 is a safe bet. mid 2018 might be "optimistic" and > > end of > > > > Q1 > > > > > > 2018 > > > > > > > > is > > > > > > > > > >> "totally crazy optimistic if the world all aligns right". > > > > > > > > > > > > > > > > > > If we keep trying to release everything at once without > > > > commitment > > > > > > and > > > > > > > > not by > > > > > > > > > slice of useful bits, then sure we will still be at it in > > 2019 or > > > > > > maybe > > > > > > > > even > > > > > > > > > later. But we don't need to do so. Existing apps and existing > > > > > > bindings > > > > > > > > won't > > > > > > > > > stop working. The new API is designed to allow for a smooth > > > > > > transition. > > > > > > > > It is > > > > > > > > > designed to allow you to mix old and new together. This way, > > you > > > > can > > > > > > > > already > > > > > > > > > build a useful application by building with Efl_Core, > > Efl_Net and > > > > > > > > Elementary. > > > > > > > > > This is fine. > > > > > > > > > > > > > > > > it's not about "trying to release all at once". it's about not > > > > painting > > > > > > > > ourselves into a corner. not limiting ourselves before we > > really > > > > need > > > > > > to. > > > > > > > > > > > > > > > > every release we do means we stop doing eo work and instead > > > > stabilize a > > > > > > > > release. the more we do the more we push a final result into > > 2019. > > > > > > without > > > > > > > > a > > > > > > > > significant amount of the interfaces api available you won't > > > > really get > > > > > > > > much, if > > > > > > > > any, valuable feedback, and instead simply lose at least a few > > > > months > > > > > > of > > > > > > > > work > > > > > > > > time into release work. (1 month per release at least). > > > > > > > > > > > > > > > > i don't see how this gets us to our goal better or sooner than > > > > what we > > > > > > are > > > > > > > > doing now. what i do see is: > > > > > > > > > > > > > > > > 1. getting there later > > > > > > > > 2. not gaining anything really valuable in return for that > > delay > > > > > > > > > > > > > > > > but here's my take... the above is my advice, but delay-wise... > > > > i'm not > > > > > > > > responsible. but mark my words that the goal that MATTERS - > > > > interfaces > > > > > > > > that can > > > > > > > > be used in BINDINGS like C#, C++, JS, LUA etc. will only get > > > > delayed > > > > > > ... > > > > > > > > and > > > > > > > > you know well enough how much a release delays. we have a whole > > > > > > mountain of > > > > > > > > new coverity complaints. any eo api to be "stabilized for > > release" > > > > > > needs a > > > > > > > > lot > > > > > > > > of attention in review and actual use before that release goes > > out > > > > if > > > > > > you > > > > > > > > want > > > > > > > > any kind of stability guarantee to it. and you know full well > > that > > > > just > > > > > > > > these > > > > > > > > few api's are of nil use to the consumers of bindings like > > above > > > > until > > > > > > > > there > > > > > > > > is a LOT more there. > > > > > > > > > > > > > > > > but if you wish to take the risk and the blame when things get > > > > > > delayed... > > > > > > > > you > > > > > > > > go ahead. all i want is proof of actual use in the wild like > > you > > > > claim, > > > > > > > > because unless there is such proof, no lessons will ever be > > learned > > > > > > from > > > > > > > > this. > > > > > > > > think of it as a "KPI". proof that the "stable beta api" is > > used > > > > > > without > > > > > > > > the > > > > > > > > current unstable beta #define and so on... in more than a few > > > > trivial > > > > > > > > places. > > > > > > > > > > > > > > > > > Cedric > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------ > > ------------------ > > > > > > > > > Check out the vibrant tech community on one of the world's > > most > > > > > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > > > _______________________________________________ > > > > > > > > > enlightenment-devel mailing list > > > > > > > > > [email protected] > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment- > > devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > ------------- Codito, ergo sum - "I code, therefore I am" > > > > > > -------------- > > > > > > > > Carsten Haitzler - [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------ > > ------------------ > > > > > > > > Check out the vibrant tech community on one of the world's most > > > > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > > _______________________________________________ > > > > > > > > enlightenment-devel mailing list > > > > > > > > [email protected] > > > > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment- > > devel > > > > > > > > > > > > > > > -- > > > > > > > http://andywilliams.me > > > > > > > http://ajwillia.ms > > > > > > > > > > > > > > > > > ------------------------------------------------------------ > > ------------------ > > > > > > > Check out the vibrant tech community on one of the world's most > > > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > _______________________________________________ > > > > > > > enlightenment-devel mailing list > > > > > > > [email protected] > > > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > > > > > > -- > > > > > > ------------- Codito, ergo sum - "I code, therefore I am" > > > > -------------- > > > > > > Carsten Haitzler - [email protected] > > > > > > > > > > > > -- > > > > > http://andywilliams.me > > > > > http://ajwillia.ms > > > > > > > > > > > > -- > > > > ------------- Codito, ergo sum - "I code, therefore I am" > > -------------- > > > > Carsten Haitzler - [email protected] > > > > > > > > -- > > > http://andywilliams.me > > > http://ajwillia.ms > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > Carsten Haitzler - [email protected] > > > > > > ------------------------------------------------------------ > > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > enlightenment-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > -- > Jean-Philippe André > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
