* 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
