Dear Mr. Gustavo Lima Chaves,
Hello.
Thanks for your response again and sorry for my poor English.
> Could you explain better what is the needed funcionality? From what I
> know, TEXTBLOCK parts in layouts are already focusable by the layout's
> + elm focus infrastructure. Do you want something different than what you
> see at "Focus 2" test? Moreover, you don't define any focus cycle smart
> function for your new widget.
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
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.
> Eina_Bool (*focus_next)(const Evas_Object *obj,
> Elm_Focus_Direction dir,
> Evas_Object **next); /**< 'Virtual' function
> handling passing focus to sub-objects */
> Eina_Bool (*focus_direction)(const Evas_Object *obj,
> const Evas_Object *base,
> double degree,
> Evas_Object **target,
> double *weight); /**< 'Virtual'
> function handling passing focus to sub-objects <b>given a direction, in
> degrees</b> */
>
> Those are lines take directly from the elm widget base class definition.
> Thus, focus functions ARE present in every widget, not just layouts.
Then I have to implement focus cycle smart fucttion based on the
Elm_Widget_Smart_Class not the Elm_Layout_Smart_Class to use focus
cycle properly.
I will try to define both functions and any other necessaries.
> Let it without EAPI and layout will see it :) EAPI is to the library
> users.
Ok, I see. then how about others? (EAPI *elm_access*(); things) I just
followed those functions.. :)
Thank you for your Enlightening me always. Catch you later.
Sincerely,
Shinwoo Kim.
2012/6/5 Gustavo Lima Chaves <[email protected]>:
> * Kim Shinwoo <[email protected]> [2012-06-05 13:18:31 +0900]:
>
>> Deal Mr. Gustavo Lima Chaves
>>
>
> Hi, Kim Shinwoo
>
>> Thanks for your response
>>
>>
>> Is the tooltip can use focus cycle? I want to use elementary focus
>> cycle for the textblock (or others which cannot use the elementary
>> focus cycle like textblock in the elementary layout). The elementary
>> focus cycle means moving focus using by "Tab" key. (and I have learned
>> that arrow keys also support the focus cycle) So something like widget
>> is necessary.
>
> Could you explain better what is the needed funcionality? From what I
> know, TEXTBLOCK parts in layouts are already focusable by the layout's
> + elm focus infrastructure. Do you want something different than what you
> see at "Focus 2" test? Moreover, you don't define any focus cycle smart
> function for your new widget.
>
>>
>> Yeap, I inherited Elm_Widget_Smart_Class first, but the subclass of
>> Elm_Widget_Smart_Class can not use the elementary focus cycle. It
>> would need some more lines for using the elementary focus cycle. But I
>> have not enough time to implement accessibility feature, so I just
>> used Elm_Layout_Smart_Class and found it works properly. anyhow..
>> further works should be here.
>>
>
> Eina_Bool (*focus_next)(const Evas_Object *obj,
> Elm_Focus_Direction dir,
> Evas_Object **next); /**< 'Virtual' function
> handling passing focus to sub-objects */
> Eina_Bool (*focus_direction)(const Evas_Object *obj,
> const Evas_Object *base,
> double degree,
> Evas_Object **target,
> double *weight); /**< 'Virtual'
> function handling passing focus to sub-objects <b>given a direction, in
> degrees</b> */
>
> Those are lines take directly from the elm widget base class definition.
> Thus, focus functions ARE present in every widget, not just layouts.
>
>> > I've seen lots of other __UNUSED__ declarations with use afterwards:
>> > caution.
>>
>> You mean the __UNUSED__ "obj" is used in the function. I have revised
>> the patch and attached.
>
> OK, nice.
>
>>
>> > It's ok to have such internal functions, but they are definetely not
>> > EAPI. Remove it.
>>
>> The elm_layout uses this function, so I used EAPI for this function as
>> other APIs.
>
> Let it without EAPI and layout will see it :) EAPI is to the library
> users.
>
>>
>> Sincerely,
>> Shinwoo Kim.
>
> Best regards,
>
> --
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
