On Fri, 23 Dec 2016 18:03:58 +0200 Andrii Kroitor <[email protected]> said:
> Hello everyone. > > Recently existing callbacks behavior was broken once again. This time by > https://git.enlightenment.org/core/efl.git/commit/?id=082ea9667343b7016d86143a625881a8c4aa30a4 > Before that commit "changed" callback was triggered only on user > changes, after - on user changes and changes from code. > I understand that in some cases this flow is needed. But previously you > could simply trigger your callback after setting value to spinner from > code to get desired missing behavior. > On the other side - now you can't distinguish value changes made by code > from value changes made by user without dirty and painful to support > hacks. If you don't want your callback to be > triggered by elm_spinner_value_set you need to add some flag meaning > "change from code", raise it before every call of value_set, check it > inside callback, remove it after the call. > And if you want to call it from spinner "changed" callback..? Good luck > here. This is possible, but requires additional wrappers around > spinner_add and spinner_value_set and replacement with custom signals. > > So this change added bigger problems than solved. you're right. a callback that was issues only on user changes that now is issued on "value_set" changes from code is bad. it basically then leads to "self-feeding callbacks" where code tries to modify spinner value due to a changed callback and triggers itself again. > Some time ago there was discussion on phab about introducing > "changed,user" callback to every widget (that has "changed" callback) > and making this callbacks behavior consistent through all widgets. > Main argument against this was "this will break some existing code". And > now only code-breaking part of that idea gets merged without even > providing sane way to preserve old flow for those who need it =\. you're right. i reverted the above commit. > I think it's time to fix this inconsistency. My vision is we should make > following changes: > > 1. "changed" callback should be triggered regardless of change initiator > 2. "changed,user" callback should be triggered on user-made changes > 3. (optional) there should be way to make changes from code as if they > were made by user. This includes not only issuing "changed,user" > callback, but also checking if that action is possible (i.e. widget > should be enabled, be in editable mode, etc.) > 4. (optional) add pre-changed callbacks? i agree. this should be consistent. there are cases where you want to know if it has been changed by user or code, by code only, by user only, and possibly know BEFORE the change has been made. the last one is hard because in some cases the change has already been made, so it's too late... e.g. we get a drag value change signal from edje... these are async long after the thing has already moved/been dragged there. the VALUE STORED by the slider for example may not be updated yet, but the dragging object has moved already. but i see the value. > I'd like to hear your opinion on this topic. this is really a matter for efl interfaces and a "changed" interface. all widgets that can change then inherit the same interface with those exact same events.... tada! consistency (at least in event naming and thus hopefully in event calling). that then opens up the issue of widgets with multiple things that can change... what is a change? should this go together with a value interface where a value is an opaque thing where you can get/set it as a boolean, an integer, a double. it may have a min, max, step etc. now technically checkboxes are values where they only do 0 and 1. a radio itself can be 0 or 1 but the group as a whole can be 0 to N ... (which one is selected). a slider is a N to M floating value possibly with steps, or a list of explicitly allowed values? is a button also a value? when pressed the value goes to 0, when released to 0? a scroller has 2 values. x and y. they could be seen as doubles between 0 and 1. the problem is w widget has 2 values. this is probably where we should GET an internal x value object and an internal y value object. the parent scroller also has a value but it "makes no sense" other than when it changes one of the child x/y objects changed 9and you should listen to the children if you care which one)... > -- > *Best Regards, > Andrii Kroitor > * Engineer, Tizen Platform Lab > > Samsung R&D Institute Ukraine > 57, Lva Tolstogo St., Kyiv 01032, Ukraine > email: [email protected] <mailto:[email protected]> > > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today.http://sdm.link/intel > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
