On 11/08/16 12:12, Davide Andreoli wrote: > 2016-08-11 11:32 GMT+02:00 Tom Hacohen <t...@osg.samsung.com>: > >> On 10/08/16 22:30, Davide Andreoli wrote: >>> 2016-08-10 16:35 GMT+02:00 Tom Hacohen <t...@osg.samsung.com>: >>> >>>> On 10/08/16 14:51, Davide Andreoli wrote: >>>>> 2016-08-10 15:48 GMT+02:00 Tom Hacohen <t...@osg.samsung.com>: >>>>> >>>>>> On 10/08/16 14:45, Davide Andreoli wrote: >>>>>>> 2016-08-10 15:22 GMT+02:00 Tom Hacohen <t...@osg.samsung.com>: >>>>>>> >>>>>>>> On 09/08/16 20:37, Davide Andreoli wrote: >>>>>>>>> Starting from this commit: >>>>>>>>> https://git.enlightenment.org/core/elementary.git/commit/?id= >>>>>>>> 015db15c626b9b06116fcc8f7ec61bbae3c6cc30 >>>>>>>>> >>>>>>>>> combobox now inherit from Genlist and Multibuttonentry, this is >>>> causing >>>>>>>>> some name clashes, in particular >>>>>>>>> I found the item_append() function to be present (and needed) in >> both >>>>>>>>> parent class. >>>>>>>>> >>>>>>>>> This is an issue in bindings, where you use it like: >>>>>>>>> cbox.item_append(...) >>>>>>>>> what function do I need to call in this case? the one from genlist >> or >>>>>> the >>>>>>>>> one from multibuttonentry? >>>>>>>>> do you want to add the item in the genlist or in the mbe? >>>>>>>>> >>>>>>>>> TBH I also found the new combobox multi selection functionality >> quite >>>>>>>>> broken atm, for example it's >>>>>>>>> quite impossible to make the widget the right size, it always >> appear >>>>>>>> super >>>>>>>>> small, unless you perform >>>>>>>>> hacks like the table+rect one, or use and edje layout (like is done >>>> the >>>>>>>>> elementary_test) >>>>>>>>> >>>>>>>>> If we don't a have a solution/explanation for the name clash I >>>> suggest >>>>>> to >>>>>>>>> revert this commit for the >>>>>>>>> 1.18 release and fix/discuss better in the next cycle >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> davemds >>>>>>>> >>>>>>>> Hey, >>>>>>>> >>>>>>>> My reply will be based on my basic checks and a few assumptions, if >>>> you >>>>>>>> think any of the assumptions are wrong, please correct me. But given >>>> the >>>>>>>> quick glance I took of the code, and our chat on IRC, I think I'm on >>>> top >>>>>>>> of it. >>>>>>>> >>>>>>>> >>>>>>>> The Eo API is not stable. This obviously includes eo functions like >>>>>>>> eo_add, but also eo properties, like multiple inheritance. Combobox >>>>>>>> inherits from box, and is extended (composite if I had to assume) by >>>>>>>> genlist. This means that any genlist calls on combobox objects are >>>>>>>> actually BETA are not "released". This means one of two things: if >> you >>>>>>>> can use combobox without these calls, all is well. If you rely on >>>> using >>>>>>>> these calls, then combobox should be marked as beta too as it's not >>>>>>>> useful without the Eo api. That is it. >>>>>>>> >>>>>>>> >>>>>>> I can understand your point here, but the problem is that legacy >> users >>>>>> can >>>>>>> use this legacy functions: >>>>>>> o = elm_combobox_add() >>>>>>> elm_genlist_item_append(o) >>>>>>> elm_multibuttonentry_item_append(o) >>>>>> >>>>>> I understand. >>>>>> >>>>>>> >>>>>>> those functions are not BETA, and people can use them. While you >>>>>>> say they are (conceptually) BETA. >>>>>>> >>>>>>> Infact we already have bindings for the combobox in python-efl. >>>>>>> >>>>>>> To be more clear: the only way to actually use the combobox widget in >>>>>>> any useful way is to use functions from other widgets (composited) >>>>>>> And if composited is conceptually BETA then the full widget should be >>>>>>> marked as BETA. >>>>>> >>>>>> That's what I said. So the widget should be marked as beta. >>>>>> >>>>>> >>>>> It's a bit too late for this, it was also in the 1.17 release (without >>>> beta) >>>> >>>> Well, it's not a problem, because as I said, it's undefined behaviour >>>> (the way it was used), and it shouldn't have been used that way. It >>>> relied on unreleased API. Combobox itself is not an API break, just >>>> certain usages. So we just released a useless widget in 1.17, I'm fine >>>> with that. Doesn't matter. Read my previous mail for more info. >>>> >>> >>> It probably doesn't matter for you but maybe does matter for all the >> people >>> (like me) that have used the combo widget released in 1.17. >>> Yes! it has been released, not under beta, with legacy functions, and >>> without any note to not use it. >>> >>> So we have done a big mess and a HUGE error releasing this widget, and >>> the fact that you don't admit this is quite disturbing. >>> >>> I have now deprecated the combobox widget in python-efl, with a >>> BIG FAT WARNING to not use it anymore. >>> https://build.enlightenment.org/job/base_pyefl_build/ >> lastSuccessfulBuild/artifact/build/sphinx/html/elementary/combobox.html >>> >>> I suggest that someone do the same for the C api/docs, and >>> again I suggest to revert the multi_selection/Multibuttonentry ability. >> >> I think you misunderstood my email. It's a big fuckup. It's bad that it >> happened. But what do you want us to do now? It was released in a >> non-working state and the recommended usage was beta but was never told. >> Seriously, what do you want us to do now? There's nothing to do... > > > The only thing to do (that I can think of) is what I have done in pyefl: > a BIG FAT WARNING to not use that widget in legacy code. > > well... and maybe check if there are other widgets that suffer for the > same problem: rely on composition (thus BETA) but released in legacy.
Yeah, that's a good way to go. -- Tom. ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
