User Details
- User Since
- Feb 26 2013, 8:15 AM (517 w, 4 d)
- Availability
- Available
Mar 4 2019
access_info (and the related event) seems suspicious considering we aren't stabilizing access at all, so this should be beta.
Feb 21 2019
@Jaehyun_Cho
The access_root was already removed. The remaining methods are still static methods inside Efl.Access.Object. I wasn't planning to separate them, since the static methods in regular class are perfectly ok with all languages.
However If You insist I can move it to some Efl.Access.Event_Manager class as we previously discussed.
@Jaehyun_Cho
Aren't examples that You provided only the implementation detail that C# developer should not care about? From C# dev perspective mixin only adds method to class, nothing else.
Feb 12 2019
@segfaultxavi
I think it all depends on how we define accessibility event. Those events are in fact defined in AT-SPI2 protocol: https://gitlab.gnome.org/GNOME/at-spi2-core/blob/master/xml/Event.xml
Generally the events from this interface translates 1-1 to dbus signals which are received by external process (screen-reader). It also serves as a flag for screen reader that this object may emit such events in the future.
The interface can be theoretically removed, however the idea was that atspi bridge should talk to objects only via efl_access_* interfaces. Instead it will require some knowledge of elementary classes. TBH i do not know if any other class will ever require to implement this interface. Only something like GIMP multi-window UI comes to my mind.
@woohyun
As a part of T7653 this interface can be removed completely and moved into efl_access_object. Additionally events can be refactored into regular methods, so instead of "window,created" we will have something like window_created_emit method or just emit with some parameter. Is this acceptable?
Feb 1 2019
In my opinion, many mixin cases in EFL can be modified as above (converted to interface or moves into class' method/properties) and its design would be better.
Jan 31 2019
Yesterday I was talking with @Jaehyun_Cho about the MIXINS and C#. I was able to understand C# binding generator a bit better. As it is already known, the C# bindings will
provide binding functionality (the possibility to call C code from C#), as well as extensions functionality (allow to call c# from c code).
Jan 28 2019
To answer Your questions:
- Yes, there will be no public methods, only single "access_object_create" protected method. It can be extracted into mixin, however I'm afraid it may again cause problems with C# bindings generator.
- Yes, the plan is to use efl_provider_find method as generic way to get access object from other objects. Alternatively, the dedicated method "access_obect_get" can be created, however I assumed that "provider_find" method fit this concept so may be reused.
Jan 23 2019
Jan 22 2019
Jan 21 2019
Nov 8 2018
As we discussed, the delay is reasonably short (< 20 ms) , so I think this patch is good to go in.
May 3 2018
@zmike I think this patch is still valid. @rcybulski is currently busy with other things, however he will be back to this in some time.
Mar 7 2018
For me it is ok to merge its.
Feb 26 2018
Feb 21 2018
Feb 12 2018
Feb 2 2018
Feb 1 2018
Jan 31 2018
Jan 30 2018
Nov 24 2017
Nov 19 2017
Nov 16 2017
Nov 15 2017
Nov 12 2017
Nov 1 2017
Oct 23 2017
Oct 18 2017
Sep 26 2017
Sep 18 2017
Sep 12 2017
Sep 8 2017
Sep 5 2017
May 31 2017
Dec 1 2016
Nov 3 2016
I agree, that there is inconsistency. however I would like to modify it in other direction:
Jun 7 2016
Please explain to me one thing. Why using callbacks to get accessible information is more convenient then using setters directly? Why setters are not enough in this case?
Dec 17 2015
Dec 15 2015
added D3452. Moreover elm_list do not support scrollto types, so that change will be skipped for now.
Dec 14 2015
It will be. Just in next patches :) Ill try to upload them today.