Re: [E-devel] [PATCH] Elementary widgets focus switch fix

2009-10-14 Thread Treviño
Carsten Haitzler wrote:
 On Tue, 15 Sep 2009 01:53:24 +0200 Marco Trevisan (Treviño) m...@3v1n0.net
 said:

Sorry for the late reply, but my computer is near to die and university
takes me much time (so thanks also for committing the other patches)...

 ok... hmmm... 1. i dont see any issue with focus and entires and illume. the
 kbd comes up when u click an entry - it stays up when u focus more than 1
 entry (ie click on another entry if one entry is already focused) and it goes
 down when u focus something that doesnt take input (eg a button). so it works.

Well, that works. I wasn't talking about changing the focus when
clicking over an entry, but when changing the focus from the sources
using elm_object_focus.

 well for me it does here. u'll have to explain what doesnt work for you a bit
 more in detail. 2. the on_focus func is called when an object is focused AND
 unfocused. see _on_focus_hook() in elm_entry - put in printfs. that is
 literally called  in both situations and the:
 
if (elm_widget_focus_get(obj))
 
 is there to figure out which.

Yeah. I know, in my tests before doing this patch I noticed this, but
the real problem was that the focus hook function for each entry doesn't
seem to be called when unfocusing it using the elm_object_focus
function. I don't know why, but at a certain point the loop over the
subwidgets stops and the unfocus is not called for the entry.

This is why I've forced it with this patch.

However to get better what is the issue that I meant, I've written a
simple example that is attached here.

If you run it with a standard elementary build, the unfocus action is
not performed when using the apposite button to switch the focused entry
(and there are also issues with the input, that is not always switched -
so it isn't just a theme issue).

Applying my patch (the 2nd one), instead the example works as expected
and I don't see neither theme or input issues.

Bye


PS: the 2nd patch should care about the entry window, but I recognize
that there's a not so clean implementation due to the static variable.
#include Elementary.h

Evas_Object *focused[4];
Evas_Object *win, *bg, *bx, *sc, *en, *bt, *lb;

static void entry_click_cb(void *data, Evas_Object *obj, void *event_info) {
	static Eina_Bool set = FALSE;

	if (!set) {
		elm_entry_entry_set(obj, Now use the button below to switch the focus!);
		elm_object_disabled_set(bt, FALSE);
		set = TRUE;
	}
}

static void swbt_click_cb(void *data, Evas_Object *obj, void *event_info) {
	static int i = 1;

	if (!lb) {
		lb = elm_label_add(win);
		elm_label_label_set(lb, Many entries with cursor - Buggy, isn't it?!?
		brThe _on_focus_hook function is not called when unfocusing...);
		evas_object_show(lb);
		elm_box_pack_end(bx, lb);
	}

	elm_object_focus(focused[i]);
	elm_object_disabled_set(focused[i], FALSE);
	i = (i+1) % 4;
}

EAPI int elm_main(int argc, char **argv) {

	win = elm_win_add(NULL, entry-scrolled, ELM_WIN_BASIC);
	elm_win_title_set(win, Entry Scrolled);
	elm_win_autodel_set(win, 1);

	bg = elm_bg_add(win);
	elm_win_resize_object_add(win, bg);
	evas_object_size_hint_weight_set(bg, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
	evas_object_show(bg);

	bx = elm_box_add(win);
	elm_box_homogenous_set(bx, TRUE);
	evas_object_size_hint_weight_set(bx, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
	elm_win_resize_object_add(win, bx);
	evas_object_show(bx);

	sc = elm_scroller_add(win);
	elm_scroller_content_min_limit(sc, 0, 1);
	elm_scroller_policy_set(sc, ELM_SCROLLER_POLICY_OFF, ELM_SCROLLER_POLICY_OFF);
	elm_scroller_bounce_set(sc, 0, 0);
	evas_object_size_hint_weight_set(sc, EVAS_HINT_EXPAND, 0.0);
	evas_object_size_hint_align_set(sc, EVAS_HINT_FILL, EVAS_HINT_FILL);
	elm_box_pack_end(bx, sc);

	focused[0] = en = elm_entry_add(win);
	elm_entry_single_line_set(en, TRUE);
	elm_entry_entry_set(en, Click Over me!);
	evas_object_size_hint_weight_set(en, EVAS_HINT_EXPAND, 0.0);
	evas_object_size_hint_align_set(en, EVAS_HINT_FILL, 0.5);
	elm_scroller_content_set(sc, en);
	evas_object_smart_callback_add(en, cursor,changed, entry_click_cb, NULL);
	evas_object_show(en);

	evas_object_show(sc);

	sc = elm_scroller_add(win);
	elm_scroller_content_min_limit(sc, 0, 1);
	elm_scroller_policy_set(sc, ELM_SCROLLER_POLICY_OFF, ELM_SCROLLER_POLICY_OFF);
	elm_scroller_bounce_set(sc, 0, 0);
	evas_object_size_hint_weight_set(sc, EVAS_HINT_EXPAND, 0.0);
	evas_object_size_hint_align_set(sc, EVAS_HINT_FILL, EVAS_HINT_FILL);
	elm_box_pack_end(bx, sc);

	focused[1] = en = elm_entry_add(win);
	elm_entry_single_line_set(en, TRUE);
	elm_entry_entry_set(en, Another entry);
	evas_object_size_hint_weight_set(en, EVAS_HINT_EXPAND, 0.0);
	evas_object_size_hint_align_set(en, EVAS_HINT_FILL, 0.5);
	elm_object_disabled_set(en, TRUE);
	elm_scroller_content_set(sc, en);
	evas_object_show(en);

	evas_object_show(sc);

	sc = elm_scroller_add(win);
	elm_scroller_content_min_limit(sc, 0, 1);
	elm_scroller_policy_set(sc, ELM_SCROLLER_POLICY_OFF, 

Re: [E-devel] [PATCH] Elementary widgets focus switch fix

2009-10-12 Thread Vaudano Luca
Yes, I don't know why but now it works. Thanks

On Sun, Oct 11, 2009 at 7:38 AM, Carsten Haitzler ras...@rasterman.com wrote:
 On Tue, 15 Sep 2009 01:53:24 +0200 Marco Trevisan (Treviño) m...@3v1n0.net
 said:

 ok... hmmm... 1. i dont see any issue with focus and entires and illume. the
 kbd comes up when u click an entry - it stays up when u focus more than 1
 entry (ie click on another entry if one entry is already focused) and it goes
 down when u focus something that doesnt take input (eg a button). so it works.
 well for me it does here. u'll have to explain what doesnt work for you a bit
 more in detail. 2. the on_focus func is called when an object is focused AND
 unfocused. see _on_focus_hook() in elm_entry - put in printfs. that is
 literally called  in both situations and the:

   if (elm_widget_focus_get(obj))

 is there to figure out which.

 yes - elm_win_keyboard_mode_set() will request kbd mode to be off then if
 another entry is focused it will then ask it to be on. as such illume has a
 small delay in it for handling kbd off requests - if something asks for the
 kbd to be on again within this delay of an off request, then the kbd will just
 stay up or if this delay times out (its something like 0.2 seconds) then the
 kbd will actually pop down.

 Hello an issue I've always noticed in Elementary is that it doesn't
 handle correctly the focus change (and using it in Illume could cause
 issues with the virtual keyboard).

 The widget which suffers mostly this problem is elm_entry since it uses
 it's own function on focus/unfocus events and when there are two
 entries, focused_entry and unfocused_entry and you do something like:
   elm_object_focus(unfocused_entry);
 The focused_entry lose the keyboard focus, but doesn't change aspect
 (since its own function is not called again).

 So, basically to fix this issue (or workarounding it? :)) I thought that
 elementary could have just remembered the focused widget clearing the
 focus to that when a new widget asked for the focus.

 I've attached two versions of the patch, the first one doesn't care
 about the window in which the widget is, and simply clears the focus
 when any widget of the running process requests to be the new focused
 widget.

 The second version (better, I think) checks if the widget is in the same
 window of the widget that is asking for the focus, in that case switches
 the focus.

 Maybe could be an idea to reset the focus at all on
   elm_object_focus(NULL);
 By the way I've not implemented it, but it could be useful when we'd
 like to hide virtual keyboards (il Illume, for example) without using
 the workaround of focusing another widget (like a button).



 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)    ras...@rasterman.com


 --
 Come build with us! The BlackBerry(R) Developer Conference in SF, CA
 is the only developer event you need to attend this year. Jumpstart your
 developing skills, take BlackBerry mobile applications to market and stay
 ahead of the curve. Join us from November 9 - 12, 2009. Register now!
 http://p.sf.net/sfu/devconference
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [PATCH] Elementary widgets focus switch fix

2009-10-10 Thread The Rasterman
On Thu, 8 Oct 2009 20:20:58 +0200 Vaudano Luca vaud...@gmail.com said:

 This bug is quite annoying and well-know for the Illume environment.
 Could someone check this patch and put on svn?

i dont see the bug. this patch doesnt make sense. not to mention the patch also
doesnt track a focused object per window. it only tracks 1 as its a static
inside the single function calls for al windows. so as such thats wrong
already. and other than that.. seee my last mail to marco - i dont see why he
sees the bug. i literally put in printf's:

0x86e67c0 focused!
0x86e67c0 unfocused!
0x86ef5e0 focused!
0x86ef5e0 unfocused!
0x86f5988 focused!

etc. each pointer is another entry widget. the previous entry is unfocused
before the next one is focused again.

 Thanks
 Luca
 
 On Tue, Sep 15, 2009 at 1:53 AM, Marco Trevisan m...@3v1n0.net wrote:
  Hello an issue I've always noticed in Elementary is that it doesn't
  handle correctly the focus change (and using it in Illume could cause
  issues with the virtual keyboard).
 
  The widget which suffers mostly this problem is elm_entry since it uses
  it's own function on focus/unfocus events and when there are two
  entries, focused_entry and unfocused_entry and you do something like:
   elm_object_focus(unfocused_entry);
  The focused_entry lose the keyboard focus, but doesn't change aspect
  (since its own function is not called again).
 
  So, basically to fix this issue (or workarounding it? :)) I thought that
  elementary could have just remembered the focused widget clearing the
  focus to that when a new widget asked for the focus.
 
  I've attached two versions of the patch, the first one doesn't care
  about the window in which the widget is, and simply clears the focus
  when any widget of the running process requests to be the new focused
  widget.
 
  The second version (better, I think) checks if the widget is in the same
  window of the widget that is asking for the focus, in that case switches
  the focus.
 
  Maybe could be an idea to reset the focus at all on
   elm_object_focus(NULL);
  By the way I've not implemented it, but it could be useful when we'd
  like to hide virtual keyboards (il Illume, for example) without using
  the workaround of focusing another widget (like a button).
 
  --
  Come build with us! The BlackBerryreg; Developer Conference in SF, CA
  is the only developer event you need to attend this year. Jumpstart your
  developing skills, take BlackBerry mobile applications to market and stay
  ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
  http://p.sf.net/sfu/devconf
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 
 --
 Come build with us! The BlackBerry(R) Developer Conference in SF, CA
 is the only developer event you need to attend this year. Jumpstart your
 developing skills, take BlackBerry mobile applications to market and stay 
 ahead of the curve. Join us from November 9 - 12, 2009. Register now!
 http://p.sf.net/sfu/devconference
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [PATCH] Elementary widgets focus switch fix

2009-10-10 Thread The Rasterman
On Tue, 15 Sep 2009 01:53:24 +0200 Marco Trevisan (Treviño) m...@3v1n0.net
said:

ok... hmmm... 1. i dont see any issue with focus and entires and illume. the
kbd comes up when u click an entry - it stays up when u focus more than 1
entry (ie click on another entry if one entry is already focused) and it goes
down when u focus something that doesnt take input (eg a button). so it works.
well for me it does here. u'll have to explain what doesnt work for you a bit
more in detail. 2. the on_focus func is called when an object is focused AND
unfocused. see _on_focus_hook() in elm_entry - put in printfs. that is
literally called  in both situations and the:

   if (elm_widget_focus_get(obj))

is there to figure out which.

yes - elm_win_keyboard_mode_set() will request kbd mode to be off then if
another entry is focused it will then ask it to be on. as such illume has a
small delay in it for handling kbd off requests - if something asks for the
kbd to be on again within this delay of an off request, then the kbd will just
stay up or if this delay times out (its something like 0.2 seconds) then the
kbd will actually pop down.

 Hello an issue I've always noticed in Elementary is that it doesn't
 handle correctly the focus change (and using it in Illume could cause
 issues with the virtual keyboard).
 
 The widget which suffers mostly this problem is elm_entry since it uses
 it's own function on focus/unfocus events and when there are two
 entries, focused_entry and unfocused_entry and you do something like: 
   elm_object_focus(unfocused_entry);
 The focused_entry lose the keyboard focus, but doesn't change aspect
 (since its own function is not called again).
 
 So, basically to fix this issue (or workarounding it? :)) I thought that
 elementary could have just remembered the focused widget clearing the
 focus to that when a new widget asked for the focus.
 
 I've attached two versions of the patch, the first one doesn't care
 about the window in which the widget is, and simply clears the focus
 when any widget of the running process requests to be the new focused
 widget.
 
 The second version (better, I think) checks if the widget is in the same
 window of the widget that is asking for the focus, in that case switches
 the focus.
 
 Maybe could be an idea to reset the focus at all on 
   elm_object_focus(NULL);
 By the way I've not implemented it, but it could be useful when we'd
 like to hide virtual keyboards (il Illume, for example) without using
 the workaround of focusing another widget (like a button).
 


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [PATCH] Elementary widgets focus switch fix

2009-10-09 Thread Cedric BAIL
On Thu, Oct 8, 2009 at 8:20 PM, Vaudano Luca vaud...@gmail.com wrote:
 On Tue, Sep 15, 2009 at 1:53 AM, Marco Trevisan m...@3v1n0.net wrote:
 Hello an issue I've always noticed in Elementary is that it doesn't
 handle correctly the focus change (and using it in Illume could cause
 issues with the virtual keyboard).

 The widget which suffers mostly this problem is elm_entry since it uses
 it's own function on focus/unfocus events and when there are two
 entries, focused_entry and unfocused_entry and you do something like:
  elm_object_focus(unfocused_entry);
 The focused_entry lose the keyboard focus, but doesn't change aspect
 (since its own function is not called again).

 So, basically to fix this issue (or workarounding it? :)) I thought that
 elementary could have just remembered the focused widget clearing the
 focus to that when a new widget asked for the focus.

 I've attached two versions of the patch, the first one doesn't care
 about the window in which the widget is, and simply clears the focus
 when any widget of the running process requests to be the new focused
 widget.

 The second version (better, I think) checks if the widget is in the same
 window of the widget that is asking for the focus, in that case switches
 the focus.

 Maybe could be an idea to reset the focus at all on
  elm_object_focus(NULL);
 By the way I've not implemented it, but it could be useful when we'd
 like to hide virtual keyboards (il Illume, for example) without using
 the workaround of focusing another widget (like a button).

I don't know elementary internal well enougth, but why don't you use
evas object focus property. It will call you back when you loose focus
or get it, and already handle your NULL case. Does it have any
limitation for elementary use ?
-- 
Cedric BAIL

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [PATCH] Elementary widgets focus switch fix

2009-10-09 Thread Viktor Kojouharov
On Fri, 2009-10-09 at 10:29 +0200, Cedric BAIL wrote: 
 On Thu, Oct 8, 2009 at 8:20 PM, Vaudano Luca vaud...@gmail.com wrote:
  On Tue, Sep 15, 2009 at 1:53 AM, Marco Trevisan m...@3v1n0.net wrote:
  Hello an issue I've always noticed in Elementary is that it doesn't
  handle correctly the focus change (and using it in Illume could cause
  issues with the virtual keyboard).
 
  The widget which suffers mostly this problem is elm_entry since it uses
  it's own function on focus/unfocus events and when there are two
  entries, focused_entry and unfocused_entry and you do something like:
   elm_object_focus(unfocused_entry);
  The focused_entry lose the keyboard focus, but doesn't change aspect
  (since its own function is not called again).
 
  So, basically to fix this issue (or workarounding it? :)) I thought that
  elementary could have just remembered the focused widget clearing the
  focus to that when a new widget asked for the focus.
 
  I've attached two versions of the patch, the first one doesn't care
  about the window in which the widget is, and simply clears the focus
  when any widget of the running process requests to be the new focused
  widget.
 
  The second version (better, I think) checks if the widget is in the same
  window of the widget that is asking for the focus, in that case switches
  the focus.
 
  Maybe could be an idea to reset the focus at all on
   elm_object_focus(NULL);
  By the way I've not implemented it, but it could be useful when we'd
  like to hide virtual keyboards (il Illume, for example) without using
  the workaround of focusing another widget (like a button).
 
 I don't know elementary internal well enougth, but why don't you use
 evas object focus property. It will call you back when you loose focus
 or get it, and already handle your NULL case. Does it have any
 limitation for elementary use ?

Not sure about elementary, but E's entry widget doesn't work with the
evas focus functions. It seems to have its own method of dealing with
focus that totally disregards the above.


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [PATCH] Elementary widgets focus switch fix

2009-10-08 Thread Vaudano Luca
This bug is quite annoying and well-know for the Illume environment.
Could someone check this patch and put on svn?

Thanks
Luca

On Tue, Sep 15, 2009 at 1:53 AM, Marco Trevisan m...@3v1n0.net wrote:
 Hello an issue I've always noticed in Elementary is that it doesn't
 handle correctly the focus change (and using it in Illume could cause
 issues with the virtual keyboard).

 The widget which suffers mostly this problem is elm_entry since it uses
 it's own function on focus/unfocus events and when there are two
 entries, focused_entry and unfocused_entry and you do something like:
  elm_object_focus(unfocused_entry);
 The focused_entry lose the keyboard focus, but doesn't change aspect
 (since its own function is not called again).

 So, basically to fix this issue (or workarounding it? :)) I thought that
 elementary could have just remembered the focused widget clearing the
 focus to that when a new widget asked for the focus.

 I've attached two versions of the patch, the first one doesn't care
 about the window in which the widget is, and simply clears the focus
 when any widget of the running process requests to be the new focused
 widget.

 The second version (better, I think) checks if the widget is in the same
 window of the widget that is asking for the focus, in that case switches
 the focus.

 Maybe could be an idea to reset the focus at all on
  elm_object_focus(NULL);
 By the way I've not implemented it, but it could be useful when we'd
 like to hide virtual keyboards (il Illume, for example) without using
 the workaround of focusing another widget (like a button).

 --
 Come build with us! The BlackBerryreg; Developer Conference in SF, CA
 is the only developer event you need to attend this year. Jumpstart your
 developing skills, take BlackBerry mobile applications to market and stay
 ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
 http://p.sf.net/sfu/devconf
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] [PATCH] Elementary widgets focus switch fix

2009-09-14 Thread Treviño
Hello an issue I've always noticed in Elementary is that it doesn't
handle correctly the focus change (and using it in Illume could cause
issues with the virtual keyboard).

The widget which suffers mostly this problem is elm_entry since it uses
it's own function on focus/unfocus events and when there are two
entries, focused_entry and unfocused_entry and you do something like: 
  elm_object_focus(unfocused_entry);
The focused_entry lose the keyboard focus, but doesn't change aspect
(since its own function is not called again).

So, basically to fix this issue (or workarounding it? :)) I thought that
elementary could have just remembered the focused widget clearing the
focus to that when a new widget asked for the focus.

I've attached two versions of the patch, the first one doesn't care
about the window in which the widget is, and simply clears the focus
when any widget of the running process requests to be the new focused
widget.

The second version (better, I think) checks if the widget is in the same
window of the widget that is asking for the focus, in that case switches
the focus.

Maybe could be an idea to reset the focus at all on 
  elm_object_focus(NULL);
By the way I've not implemented it, but it could be useful when we'd
like to hide virtual keyboards (il Illume, for example) without using
the workaround of focusing another widget (like a button).
Index: src/lib/elm_widget.c
===
--- src/lib/elm_widget.c	(revisione 42476)
+++ src/lib/elm_widget.c	(copia locale)
@@ -87,6 +87,16 @@
elm_widget_focus_steal(sd-obj);
 }
 
+static void
+_focused_obj_update(Evas_Object *obj) {
+   static Evas_Object *focused_obj = NULL;
+
+   if (focused_obj  focused_obj != obj)
+  elm_widget_focused_object_clear(focused_obj);
+
+   focused_obj = obj;
+}
+
 /* externally accessible functions */
 EAPI Evas_Object *
 elm_widget_add(Evas *evas)
@@ -481,6 +491,7 @@
if (!sd-focused)
  {
 	sd-focused = 1;
+	_focused_obj_update(obj);
 	if (sd-on_focus_func) sd-on_focus_func(sd-on_focus_data, obj);
  }
if (sd-focus_func)
@@ -590,6 +601,7 @@
API_ENTRY return;
if (sd-focused) return;
if (sd-disabled) return;
+   _focused_obj_update(obj);
parent = obj;
for (;;)
  {
Index: src/lib/elm_widget.c
===
--- src/lib/elm_widget.c	(revisione 42476)
+++ src/lib/elm_widget.c	(copia locale)
@@ -87,6 +87,19 @@
elm_widget_focus_steal(sd-obj);
 }
 
+static void
+_focused_obj_update(Evas_Object *obj) {
+   static Evas_Object *focused_obj = NULL;
+
+   if (focused_obj  focused_obj != obj 
+   elm_widget_top_get(focused_obj) == elm_widget_top_get(obj))
+  {
+ elm_widget_focused_object_clear(focused_obj);
+  }
+
+   focused_obj = obj;
+}
+
 /* externally accessible functions */
 EAPI Evas_Object *
 elm_widget_add(Evas *evas)
@@ -481,6 +494,7 @@
if (!sd-focused)
  {
 	sd-focused = 1;
+	_focused_obj_update(obj);
 	if (sd-on_focus_func) sd-on_focus_func(sd-on_focus_data, obj);
  }
if (sd-focus_func)
@@ -590,6 +604,7 @@
API_ENTRY return;
if (sd-focused) return;
if (sd-disabled) return;
+   _focused_obj_update(obj);
parent = obj;
for (;;)
  {
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel