On Fri, 22 Oct 2010 19:02:39 +0200 Dave Andreoli <d...@gurumeditation.it> said:
> 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. priority #1 is the C library API. theme API is 2nd tier. the C API is not as right as it should be. externals are 3rd tier. first get C API right. theme api comes along with that. externals... they pretty much follow C api's. > * 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 not going to happen i don't think. as such it can stay. there is no harm in it staying as it is. it does a job and does it well. it's also relatively simple. :) > COLORPICKER: the test is really ugly, why the colored arrows stratch > in that way? ugly is something we do need to fix - but api is more important. > 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.... yes. that's just a matter of better theme. > 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. that's a good question. flippicker offers that the enitre widget view is available to the selected item - diskpicker doesn't offer that. only part of its space is available to the seleced item text etc. > HOVERLIST/HOVERSEL Do we need to drop hoversel in favor of overlist? they > seems exacly the same widget methinks hoverlist feature should just go into hoversel (it was there first and frankly i always thought i should eventually add some sort of scrollability once items get beyond the window/canvas/parent widget limits). > MAGNETSLIDER do the same work as TOGGLE. One of the two need to go away. this is a good question. i'd vote for just making an N state slider. but this will make the theme side of things rather nasty. so the 2 of them now are a practical thing due to theme - but it could be done in theme with enough script and messages. > 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...) slider also needs a way to "limit to slots". ie a slider that can just do 0, 2, 4, 6, 8, 10 (and it sjumps properly from each value slot as opposed to being continuous). it needs such an option anyway. the question is how to implement it. > PHOTO/GENGRID do we need the PHOTO widget anymore? aren't the same? well photoCAM and gengrid are definitely different. photocam and hpoto are different (photocam for big digital camera like jpeg photos. photo for photo thumbnails like you'd have in a contact manager or photo viewer list of photos etc.). > * 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!) that makes every widget much more complex. a lot of them are special cased for efficiency. > * What about selection in entries? is there a way to select the > text?...maybe I missed it. works like a charm. :) > * 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?) the problem is that you get long unwieldy names that become entire paragraphs then. what it does need is more sexiness - yes, but its less a demo and more a test suite. demo's are another matter :) > 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. that's the idea. the other libs will go 1.0 before elm does. > 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 ? it's already 0.7 :) > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
