2010/10/21 Gustavo Sverzut Barbieri <barbi...@profusion.mobi>: > On Thu, Oct 21, 2010 at 9:08 AM, Davide Andreoli <dave...@gmail.com> wrote: >> Ok I have to say this: I'm really in disappoint whit this annunce! >> I dont think elementary is ready for this. >> At least for my experience every time you write an app using elm you need to >> patch/break/add stuff to elm itself. So freezing api is an hazard. > > Well, it was expected. So far there was no applications using the lib, > which is quite a "path to failure". Then we got Enlil, Ephoto, Eve, > Enjoy and Envision to use it, then we realized some problems and are > almost done fixing them (toolbar/menu). Also spotted room for > improvements by providing default layouts to be used, they got in. > Other than that, what do you see?
Ok I'm at home now, I will try to list the first stuff that I have in mind: * The first problem I see is that we need to define what API means in elementary. I think we have at least 3 different api to take in consideration (with api I mean stuff that need to be constant trough releases): the normal C API, the theme API and the EXTERNAL api. The C api is probably in a good shape, but the EXTERNAL stuff still need a lot of work (quite half of the widgets are implemented, and they could expose much more properties). Also we are not considering the theme API, lots of people seems to make custom themes for elm widgets, this means that if we change somenthing in the edc we can break existing apps in a bad way. We will also need some docs around this. In the end I think that for a release we need to define well all those 3 APIS. * Lots of widget need a good rewrite/cleanup: FLIP: The animation of the flip widget should be themeabe, not hard-coded as they are now, that kind of animation can be easily done directly in edje. This require quite a full rewrite of the widget COLORPICKER: the test is really ugly, why the colored arrows stratch in that way? DISKPICKER: wtf is this? if we want a rotation we need to make a rotation not a strange font size/ellipsis trick...I really hate this widget, it doesn't seems a disk either.... FLIPPICKER: Does this have to be 2 different widgets, we should just have one 'picker' widget, and then disk, flip or whatever should be just a theme/style stuff. HOVERLIST/HOVERSEL Do we need to drop hoversel in favor of overlist? they seems exacly the same widget MAGNETSLIDER do the same work as TOGGLE. One of the two need to go away. SLIDER I'm not on it atm but I remember it was an hell to make a custom style, probably the theme must be fixed. (it use a system like html tables...) PHOTO/GENGRID do we need the PHOTO widget anymore? aren't the same? * We must try to keep down the number of the widgets, they must be general widget, dont make a widget for every think (look at the iPhone api, you can do everything with 10 widgets!) * What about selection in entries? is there a way to select the text?...maybe I missed it. * The test app must be more 'sexy'. It's the first thing a developer will see, and usually is the one that make you choose if you will use the tk or not. We should remove numbers and explain what the test serve (look at list4 for example, ehat does it test?) Targetting elm at 1.0 means that we are satisfy as we are for the others libs that are 1.0 (evas, edje, ect) .... do we are? I dont think so. Btw I'm impressed of the work done on elm in the last few days, so I start thinking that planning a release is a good choice. What about releasing elm as 0.5 ? Than we can breaking stuff going to 0.6, 0.7 and so on, until 1.0 ps: at least move it outside TMP/ST ;) > > This is one of the problems I see... people use Elementary but do not > say what's good and what's not. They silently work around things. > We're trying to avoid that and above I've mentioned our findings. But > I've heard nothing from others! > > Samsung just complained about some missing widgets they'd like in. But > these are additions, not breaks. > > >> Im rewritig the fileselector and i will need to' break its api. And this >> will not happend in a week. >> Btw, I'm in holland now, writing from the phone, I will send another bad >> mail tomorrow from home > > Why do you need to break the API of a file selector?! Changing the > internals to make it look better, it's fine, but what public changes > do you need? From Elementary.h.in we're just missing a way to get > multiple files, but that's an addition we should do before the > release. > > NOTE: if you're talking about exta apis to control fileselector > behavior, then don't make it public. Although it's an add and thus not > an actual break, these things should be controlled by the elementary > profile only. If you're talking about making the fileselector its > own dialog, I'd veto it as well, I like the current flexibility... you > can make a middle ground between fileselector and fileselector button, > isolating the inwin/popup dialog part in another widget. > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
