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. -- 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
