Dear all,
Revised patch has followings
1. The TEXT part is contemplated also
2. The Elm_Widget_Smart_Class is parent class of elm_access not the
Elm_Layout_Smart_Class
3. The elm_access_edje_object_part_object_register() is added
- Why I does not integrated with _elm_access_add is there are
following APIs for the consistency
a. _elm_access_object_register(): is for the widget object
b. _elm_access_item_register(): is for the widget item
I have attached EXAMPLE code also. Thanks.
Sincerely,
Shinwoo Kim.
2012/6/7 Kim Shinwoo <kimcinoo....@gmail.com>:
> Dear Mr. Gustavo Lima Chaves,
>
> Hello. Thanks for your understanding, proposal and kind response!
>
>> Now I seem to get what you want. For accessibility reasons, you want
>> the user to be able to read the contents of TEXT/TEXTBLOCK parts on a
>> layout. Is it right? Then we'd have a "fake" widget encapsulating
>> them, for focusing (cycle) purposes, and THAT is the access object, if
>> I understand well.
>>
>> The problem I see so far with your current patch is that only
>> TEXTBLOCKs are contemplated (no TEXT), and what is worse, just
>> TEXTBLOCK parts which are actively touched with text_set() calls.
>> Wouldn't we want to have all text contemplated, if under accessibility
>> mode?
>
> Yeap, right. the patch is just "ONE SMALL STEP". The TEXT part should
> be contemplated also. One committer told me that it is better to send
> a patch as small as possible. This time is for the TEXTBLOCK part,
> next time will be for the TEXT part (Sorry, this is a cowardly excuse
> :-]) Anyhow, I will revise the patch to contemplate the TEXT part
> also.
>
>>
>> Besides, the elm_access thingie could be an internally visible widget
>> only, having the following creation call:
>>
>> elm_access_add(Evas_Object *parent,
>> const Evas_Object *obj,
>> const char* access_text);
>>
>> With that, we avoid that ugly _elm_access_textblock_register() one.
>> Ideally, these layout sub_d->obj access objects for text would be
>> created for each and every text/textblock part of a layout
>> automatically, just after elm_layout_file_set(), if in accessibility
>> mode.
>>
>> What do you think?
>>
>> To finalize, the access object would be a direct child of
>> Elm_Widget_Smart_Class, because it'll have very little logic (it just
>> needs to be a widget to enter the layout's child focusing cycle and
>> have the little access text logic).
>
> Yeap, that sounds pretty good to me!
> I agree the _elm_access_textblock_register() would be ugly.
> Integrated elm_access_add(); would be better than using the
> _elm_access_textblock_register(); I'll do.
>
> And yeap! I will revise the patch by using Elm_Widget_Smart_Class not
> the Elm_Layout_Smart_Class.
>
> Ok then, catch you later with revised patch.
>
> Sincerely,
> Shinwoo Kim.
>
>
>
> 2012/6/7 Gustavo Lima Chaves <gl...@profusion.mobi>:
>> * Kim Shinwoo <kimcinoo....@gmail.com> [2012-06-06 00:02:02 +0900]:
>>
>>> Dear Mr. Gustavo Lima Chaves,
>>>
>>> Hello.
>>> Thanks for your response again and sorry for my poor English.
>>>
>>
>> Hi, Kim Shinwoo :) No problem, I understand you clearly :)
>>
>>>
>>> In the "Focus 2", there is not a TEXTBLOCK part but a TEXT part("some
>>> edje text here"). The TEXT part would be covered by my patch with some
>>> cosmetic modifications.
>>> You might indicate the Scrolled Entry. You can check the needed
>>> functionality what I want to add from the example patch
>>> (example_elm.access.layout.texblock.uses.access.diff in the first
>>
>> Now I seem to get what you want. For accessibility reasons, you want
>> the user to be able to read the contents of TEXT/TEXTBLOCK parts on a
>> layout. Is it right? Then we'd have a "fake" widget encapsulating
>> them, for focusing (cycle) purposes, and THAT is the access object, if
>> I understand well.
>>
>> The problem I see so far with your current patch is that only
>> TEXTBLOCKs are contemplated (no TEXT), and what is worse, just
>> TEXTBLOCK parts which are actively touched with text_set() calls.
>> Wouldn't we want to have all text contemplated, if under accessibility
>> mode?
>>
>>> mail). As the "Scrolled Entry" in the "Focus 2", I want to give the
>>> focus to TEXTBLOCK(or TEXT) by using elm_access object. The focused
>>> object will be used as a "accessibility highlight object". If
>>> accessibility does not use the focus cycle, there should be another
>>> cycle for move accessibility highlight object. I already have some
>>> lines for the highlight cycle based on geometry value. But it would be
>>> redundant lines because of focus cycle. Raster also recommend to use
>>> the focus cycle.
>>
>> Besides, the elm_access thingie could be an internally visible widget
>> only, having the following creation call:
>>
>> elm_access_add(Evas_Object *parent,
>> const Evas_Object *obj,
>> const char* access_text);
>>
>> With that, we avoid that ugly _elm_access_textblock_register() one.
>> Ideally, these layout sub_d->obj access objects for text would be
>> created for each and every text/textblock part of a layout
>> automatically, just after elm_layout_file_set(), if in accessibility
>> mode.
>>
>> What do you think?
>>
>> To finalize, the access object would be a direct child of
>> Elm_Widget_Smart_Class, because it'll have very little logic (it just
>> needs to be a widget to enter the layout's child focusing cycle and
>> have the little access text logic).
>>
>>>
>>> Thank you for your Enlightening me always. Catch you later.
>>
>> Please tell me if I got the use case of the access object right, and what
>> do you think of my proposal.
>>
>>>
>>> Sincerely,
>>> Shinwoo Kim.
>>>
>>
>> --
>> Gustavo Lima Chaves
>> Computer Engineer @ ProFUSION Embedded Systems
>>
>> ------------------------------------------------------------------------------
>> 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
EXAMPLE_elm.access.layout.texblock.uses.access_3rd.diff
Description: Binary data
elm.access.layout.texblock.uses.access_3rd.diff
Description: Binary data
------------------------------------------------------------------------------ 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
