Hi, A good point - we do need consistency at the core. Additionally as Eo was designed to make binding easier then allowing a :bool event type is probably not in the spirit of things.
Whilst it is convenient I'd also say that (event->info) is unclear - given the noun nature it looks like a check for a non-null info entity. Even if I do figure that it's a bool it is still not clear what it represents. A "focussed" member in a struct is much clearer for the reader of the code. Thanks, Andy On Fri, 22 Dec 2017 at 03:25 Carsten Haitzler <[email protected]> wrote: > On Thu, 21 Dec 2017 18:17:58 +0000 Andrew Williams <[email protected]> > said: > > > Hi, > > > > I'm sorry but seriously? > > "Well, common or not is nothing that counts here IMO." > > > > In an exercise such as this consistency is one of the most important > > concepts. > > No? > > Andy > > well in C bu5hm4n makes a point - you'd have to cast to a struct type then > deref it to get to the bool... where if (event->info) ... will do just as > well.. > > BUT in other languages it's better this way because the type will be able > to be > immediately expressed (the bool) without having to jump through a container > that contains a single bool element... > > so in general this kind of pattern is probably not bad as it's convenient > in > all languages. it does come with a downside: once you make the event info a > bool its not able to extend in future with more data. > > the question is - is the convenience worth it to give up the ability to > ever > extend? > > this is also part of a larger design pattern question: > > focus,changed > > vs. > > focus,in + focus,out > > also if focus,changed doesn't HAVE to carry the focus bool in the event > info. > you can get the focus state from the object itself by getting its focused > property, so the event info focus data is redundant. > > so is having 2 events better than 1 or vice-versa? and this is a design > question everywhere. mouse,down + mouse,up vs just mouse,button + flag for > down vs up? mouse,in + mouse,out vs mouse,crossing + flag ? we should be > consistent in design here. > > the important thing i think is design consistency. also we should not have > redundancy unless there are VERY good reasons to have it. by that i mean > "there > are 2 or 3 or 4 ways to do this depending on which side of the bed you > woke up > on today". bigger-picture-wise this makes it harder to learn and work with > efl > because you read code and the code in one place may not be consistent with > another. also developers will be given the need to choose the way and make > a > decision, and this will slow them down when there are 2 or 3 ways to do the > same thing. i DO see a point to multiple ways if there is a significant > difference (lots less code, faster execution by a good margin etc. etc.), > otherwise this raises the bar to learn and maintain without IMHO a good > pay-off. > > > On Thu, 21 Dec 2017 at 18:11 <[email protected]> wrote: > > > > > Hi, > > > > > > On Thu, Dec 21, 2017 at 12:19:41PM +0000, Andrew Williams wrote: > > > > Hi, > > > > > > > > Stumbling upon the efl_ui_focus_object.eo defintion: > > > > > > > > focus,changed : bool; [[Emitted if the focus state has > changed]] > > > > > > > > > > The now active property. > > > > > > > I am unsure what the purpose of the bool is. My guess is that it's > what > > > the > > > > focussed value used to be or has become. > > > > Following the docs it implies a relation to whether or not focus has > > > > changed. > > > > None of our code seems to use this - they all call > > > > efl_ui_focus_object_focus_get within the callback. > > > > > > the old code always used elm_widget_focus_get and that was replaced > with > > > efl_ui_object_focus_get, instead of sometimes using the flag ... > > > > > > > For that matter is it common to pass a primitive value in the place > of > > > void > > > > *? All the other callbacks I have used pass structs which are far > easier > > > to > > > > understand. > > > > > > Well, common or not is nothing that counts here IMO. > > > > > > if (event->info) { ... } else { ... } > > > > > > Is handy and does not need any casting or something, a struct would > > > require at least a cast to that struct, which is not that nice. > > > > > > > > > > > Thanks for any help on this, > > > > Andy > > > > -- > > > > http://andywilliams.me > > > > http://ajwillia.ms > > > > > > > > ------------------------------------------------------------------------------ > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > > > > enlightenment-devel mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > ------------------------------------------------------------------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > > enlightenment-devel mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > > http://andywilliams.me > > http://ajwillia.ms > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > enlightenment-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > Carsten Haitzler - [email protected] > > -- http://andywilliams.me http://ajwillia.ms ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
