On Sat, Jul 7, 2012 at 12:28 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sat, 7 Jul 2012 00:19:22 -0300 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> said: > >> On Fri, Jul 6, 2012 at 11:59 PM, Carsten Haitzler <ras...@rasterman.com> >> wrote: >> > On Fri, 6 Jul 2012 23:30:09 -0300 Gustavo Sverzut Barbieri >> > <barbi...@profusion.mobi> said: >> > >> >> On Fri, Jul 6, 2012 at 11:16 PM, Carsten Haitzler <ras...@rasterman.com> >> >> wrote: >> >> > On Fri, 6 Jul 2012 22:43:31 -0300 Gustavo Sverzut Barbieri >> >> > <barbi...@profusion.mobi> said: >> >> > >> >> >> On Fri, Jul 6, 2012 at 7:20 PM, Gustavo Lima Chaves >> >> >> <gl...@profusion.mobi> wrote: >> >> >> > * Gustavo Sverzut Barbieri <barbi...@profusion.mobi> [2012-07-06 >> >> >> > 18:59:35 -0300]: >> >> >> > >> >> >> >> On Fri, Jul 6, 2012 at 6:04 PM, Enlightenment SVN >> >> >> >> <no-re...@enlightenment.org> wrote: >> >> >> >> > Log: >> >> >> >> > better icons for video knobs...they are still not .awesome. but in >> >> >> >> > 14x14 pixel I cant do better than this >> >> >> >> >> >> >> >> since you're at it... >> >> >> >> >> >> >> >> why not have controls.c to use elm_ctxpopup? It would reduce the >> >> >> >> amount of work in terminology and could(*) look better. >> >> >> >> >> >> >> >> * nobody is using ctxpopup outside of tizen, but the contextual >> >> >> >> popup >> >> >> >> is nice (borrowed from iOS, shamefully) and if we use, we can make >> >> >> >> it >> >> >> >> look and behave sanely. >> >> >> >> >> >> >> > >> >> >> > Raster does not like its code (figured) and does not want to rewrite >> >> >> > it (that would help me a lot :P). I'm afraid he's not very fond of >> >> >> > elm >> >> >> > menus too, but we could try. Much better than that 'thing' we got now >> >> >> > on the terminal. >> >> >> >> >> >> this is insane. >> >> >> >> >> >> I also dislike the code, but I believe that avoiding it will not lead >> >> >> the code to be fixed. If we use it, more likely to fix. >> >> >> >> >> >> If we choose to just ignore it, then it's better to remove such widget >> >> >> from EFL and have less to maintain. >> >> > >> >> > you can't. its' released. something you always wanted and pushed for so >> >> > heavily. now you pay the price. i suspect you don't understand the >> >> > concept of stable and release, something i tried to impress on you >> >> > several times when you were pushing me to do a release (when i made eet >> >> > 1.0 and now we have to maintain the old eet disk format and the current >> >> > one as a result for as long as we don't go 2.0 and 2.0 means breaking >> >> > support and that drives people away, so we won't be breaking things for >> >> > a long while to come >> >> > - at least until about 2016). >> >> >> >> we agree to disagree on concepts. To me release is about stamping the >> >> quality of some set of code. I never like, agree or understand your >> >> point of future promises about it. >> > >> > you may not like it, but it is REALITY. it is a reality i learned from >> > imlib >> > and imlib2. people bitching and then leaving to use some other library >> > because their code kept breaking. >> > >> >> If you were a company selling software to customers, I'd even try to >> >> understand. But even these companies give a shit as you can see at >> >> major vendors. >> > >> > if you see your competition as gtk - they maintained aq stable unbroken api >> > for about 5 years until gtk2, 8 years until gtk3. (1998ish to 2003ish, then >> > 2.x for 2003ish to 2011ish). gtk isn't a company selling support. qt was >> > poorer at this as they are up to 4 and about to hit 5 now. admittedly for a >> > longer timeframe. let me just put gtk now as the "benchmark" for stability. >> > but even then, libc's have maintained compatibility for much longer. many >> > other libraries have done so too. windows has maintained compatibility >> > going forward for decades. if you don't believe this is important, then you >> > have yet to learn that lesson. i've learned it. i vowed to ensure that efl >> > is stable and supported once we release, and it shall be so, because doing >> > otherwise hurts us most amongst those that matter most - existing people >> > already invested in efl. people who have decided to give it a go and take >> > a risk. >> >> worth noting that Maemo struggled with Gtk for exactly the reason you >> praise as benefit. >> >> They needed mobile features that were not getting in because Gtk tried >> to provide stability to "enterprise applications"... which I doubt >> they had at a relevant amount given Gtk's license and API x Qt (which >> was preferred by closed source enterprise grade software house) or >> Java/AWS. > > gtk didn't ADD features. nothing to do with breaking compatibility.
actually what got in the way was the Gtk "windowed widgets". They struggled a lot to get to "windowless" widgets as EFL did forever... they call they got it, but I've heard there are some stuff left here and there. they did not change to avoid breaking compat. >> At the end, they were not flexible enough... and once competition >> (iPhone) got ahead, they had no chance other than completely move... I >> tried to put EFL in there, but we had NO RELEASES... :-) > > and we'd have been ditched for qt anyway. :) probably a good thing. IOW: I'm always right ;-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
