On Thu, May 10, 2012 at 5:10 AM, Daniel Juyung Seo <seojuyu...@gmail.com> wrote: > Thanks for the great effort. > But I have a question about this commit. > > It describes that > - elm_object_xxx APIs will be deprecated later. Use elm_layout_xxx APIs > instead. > - all elm_layout_* namespaced fuctions will function on objects > inheriting from this base: > > So it means to set the actionslider text, we will be using > elm_layout_text_set(actionslider, "left", "Left"); > Isn't this confusing for app developers? > And app developers have to understand the inheritance structure of elementary. > > It will be great if you give me further explanation about this.
That's the single sane way to do it, and the case for every toolkit out there, be ObjC, C++ or C. The developer needs to understand the hierarchy in order to use, you can't call a method in a object that did not implement, but admittedly C makes it more cumbersome as you must type the namespace and class name, while C++ and ObjC does that for you. If you think about that now, although not having to think about the hierarchy to type the name, the user indeed needs to know if the object supports parts setting, and which. If you call part set on a box, it will do nothing. We could keep the backwards compatibility thing and do not deprecate it, but in my opinion it is bad because: Once we allow extending Elementary from outside, more libraries will create more components and these may have their own common methods. Imagine a library provides a base widget BW and dozen widgets, all with the same methods. You'll have some my_bw_method(). You cannot/should not create elm_object_method(), thus you'll generate some inconsistency here as out-of-library widgets can't use the same pattern. All in all the elm_object_ methods were mostly hacked in afterwards, and that hurts. As we did not had any common "layout" to inherit, every widget did the same code over and over again: Button, Checkbox, Frame... all had text set on their own. Again, we lacked the inheritance, then there was no other way than "move this to the base widget operations" to solve the problem. Now we do have and we better use it. > Anyhow, thanks for the great job. Glima is doing a nice work, but man it's being quite harder than we anticipated. The problem is that some internals are completely upside down given the "unplanned organic growth" of elementary. If we started to create Elementary from scratch like that, we'd have less code and by far less inconsistencies. For instance, the theme API breakage is due that, some objects did not followed the same name scheme as the others :-/ -- 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
