On Sat, Oct 23, 2010 at 8:06 PM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > Hi all, sorry taking so long to reply, but I was out of network access > + time to do it before. Find the answers inline, and I'm ignoring > couple as people already made good points on the rest of the thread. > > First, a disclaimer of what is being done and some "why"s: > > - before going alpha we're reviewing the API. That includes some > get_something becoming something_get, missing consts... some methods > that returned their internal list of items (Eina_List) are being > converted to return iterator-like pattern of _first_get + _next and > _last_get + _prev. --> THIS WILL BLOCK 1.0, thus will be done before > it. IF YOU FIND SOMETHING HERE, let us know. > > - some widgets were contributed without actual theme, or themes > that could not be released to svn and Raster requested that we did a > quick/simple theme for them. Most of those you complain. Okay, some > could be a bit better looking, but their ugliness do not block a > release, it's gfx work that can be changed later without major > worries. > > > On Fri, Oct 22, 2010 at 3:02 PM, Dave Andreoli <d...@gurumeditation.it> wrote: >> 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). > > missing EXTERNAL widgets or parameter is no big goal. Adding more will > not break api, it's much like yet-another-binding and although it's in > SVN I'd say they can lag behind such as Python and JS does. However > I think that with some community help we can bring them to shape! > The code is super-simply, a rough sed can be enough to get a new > widget. Adding missing properties is also easy, but just do for those > THAT MAKE SENSE :-) > > >> 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. > > theme stability. I'd say this does NOT block 1.0, it would be good to > have, but I don't see it happening that soon, if ever. Let's face it, > to make such themes rock stable that would require a major bump > whenever you break their interface, either we'd cap down the whole > widgets and make them stupid as GTK/Qt with introduction of new > widgets to make a fit for missing parts/signals/messages on the one > that should have it, we'll have a system nobody would like. If we > stop and try to brainstorm all possibilities of every widget, we'd > also never release and if ever do it, do a bloated nonsense thing. > HOWEVER, themes are quite stable for core widgets and they'll not > change radically soon, maybe some pad/fingersize expander gets added, > or scale... but that's it. > > > >> 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 > > Agreed, but from the user perspective, it's the same API. We're not > ever freezing the internals. As for the theme part, as I said before > we're not freezing it anytime soon (maybe not even 3.0). > > > >> COLORPICKER: the test is really ugly, why the colored arrows stratch >> in that way? > > just fix it. someone forgot to set min/max... and for the alpha > checker/pattern it also need better values for tile without stretch. > > > >> 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.... > > Well, to tell you the truth we don't like it as well. That was > demanded to get in by raster, the original code had to be redone to > get in EFL standards, and their theme could not be released to public. > So raster said "fix the code, do some theme for it" and that's what > got in. I guess the idea was to have something like iPhone's > combobox. > > >> 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. > > Agreed, but I guess no time to join both now :-/ Or anytime soon. If > people get to merge them, fine, but I don't see this as blocking a > release. These widgets are much like special purpose, could even be an > elm_extras library if people agree. > > BTW, if people are getting to these pickers "unification", you need to > consider different pickers require different number of entries to > show. Usually they're constrained by 3, but some can use 5 (previous, > previous, current, next, next). It would be good to have a way to > declare how many the C should set in edc... maybe by means of data > item? > > > >> HOVERLIST/HOVERSEL Do we need to drop hoversel in favor of overlist? they >> seems >> exacly the same widget > > as said by Nicolas, they're different. And the original code we got > was VERY different. Gustavo Lima and I discussed to figure out a way > to do it properly using hover infrastructure and so it is. > > However, the elc_hoversel could use elc_hoverlist. It would be > basically just a wrapper around it with a button. > > Glima: you forgot a couple of methods in hoversel, and the icon thing > should just set a string. See Leandro's toolbar/menu for reasons (if > you implement a desktop using popup windows, you can't move one object > from a canvas to another). > > >> MAGNETSLIDER do the same work as TOGGLE. One of the two need to go away. > > ehehehe... we had exactly the same discussion at ProFUSION when we got > this widget. But there is a difference that we really don't know why > it is required: it's tri state! :-( > > yes, the magnetic properties for magnetslider could be also > implemented into toggle, making it harder or easier to get to the > other side (ie: to avoid accidental changes). > > but adding 3 state to toggle would break its principle of a boolean > value. That's why it got in. > > >> 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...) > > don't think so, we have it done in efenniht and it is simple. > > > >> PHOTO/GENGRID do we need the PHOTO widget anymore? aren't the same? > > As said by Rafael, nothing to do. But we could do some extensive work > to make elm_image capable of everything elm_bg/elm_icon does, maybe > even elm_photo (frame + action/signal). However, making those > complex would help? I guess they are simple enough, with purposes > clear enough (maybe image/photo are not, then should be joined). > > >> * 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!) > > 1000000% agree with you. But we need help, as such we'll likely have > the current number. We're trying to avoid adding more, like the > hoversel that actually reuses thing, or the one we're redoing to use > toolbar instead another toolbar-like widget. > > >> * What about selection in entries? is there a way to select the >> text?...maybe I missed it. > > yes, as Sachiel said. Rafael Fonseca is working on profiles and it > should define a better default for desktop. > > >> * 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?) > > I guess every test should have a description string of what it does > and what's expected, yeah. > > but test != demo. We could use a demo app for sure, but as said above, > if we don't even have time to do what's required, a demo is not any > close to becoming priority. > > >> 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. > > it is, for a while already. The key thing that was missing was focus, > it's in place now. So even desktop will have some proper usage. > > if you consider the other libs, although they are 1.0 they're not the > final-never-changing target. Evas could use more vectors, filters, ... > but it's not there. Edje could use better lua support, but still not > there. And they're going 1.0. > > Although Raster keep saying that he'll target 6 month releases from > now on, I'm actually pushing for 3 month releases, much like kernel > guys do. The reason is that we avoid going into the same trap we're > now: "wait a bit, I want this in... if I miss it, it will take +6 > months to get it public" then the release is delayed, and > yet-another-thing shows... and 10 years are over :-) 3 months you > can be more strict, as it's not that far. > > >> 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 > > what's the fucking problem with 1.0, god damn cursed number? we're > already using it, we know it work, we just want to let people know > that, thus 1.0 as they seem to not trust anything else for an unknown > reason. > > we'll get 1.1, then 1.2... with the current design, even if we make > the so called "guarana + elementary" merge, enabling widgets to be > inheritable by means of a Smart Class superset, we'll not need to > release an 2.0. The public api is what matters at this point. >
Just remember to stick the big fat warning on elm_widget.h into every one that tries to write widgets outside of tree. > > -- > 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 > ------------------------------------------------------------------------------ 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
