2010-10-19 11:25:22 -07:00
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
# include "elementary_config.h"
|
|
|
|
#endif
|
2012-03-29 12:27:13 -07:00
|
|
|
#include <Elementary.h>
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
#ifndef ELM_LIB_QUICKLAUNCH
|
|
|
|
|
|
|
|
static void
|
2010-10-19 11:25:22 -07:00
|
|
|
_focus_in(void *data __UNUSED__, Evas *e __UNUSED__, void *event_info)
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
{
|
|
|
|
const char *type = evas_object_type_get(event_info);
|
2010-10-22 14:41:27 -07:00
|
|
|
if ((type) && (!strcmp(type, "elm_widget")))
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
type = elm_object_widget_type_get(event_info);
|
|
|
|
printf("Evas_Object focus in: %p %s\n", event_info, type);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2010-10-19 11:25:22 -07:00
|
|
|
_focus_out(void *data __UNUSED__, Evas *e __UNUSED__, void *event_info)
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
{
|
|
|
|
const char *type = evas_object_type_get(event_info);
|
2010-10-22 14:41:27 -07:00
|
|
|
if ((type) && (!strcmp(type, "elm_widget")))
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
type = elm_object_widget_type_get(event_info);
|
|
|
|
printf("Evas_Object focus out: %p %s\n", event_info, type);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2010-10-19 11:25:22 -07:00
|
|
|
_focus_obj(void *data, Evas_Object *o __UNUSED__, void *event_info __UNUSED__)
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
{
|
|
|
|
Evas_Object *newfocus = data;
|
|
|
|
const char *type = evas_object_type_get(newfocus);
|
2010-10-22 14:41:27 -07:00
|
|
|
if ((type) && (!strcmp(type, "elm_widget")))
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
type = elm_object_widget_type_get(newfocus);
|
2011-08-03 08:01:39 -07:00
|
|
|
printf("elm_object_focus_set(%p, EINA_TRUE) %s\n", newfocus, type);
|
|
|
|
elm_object_focus_set(newfocus, EINA_TRUE);
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2010-10-19 11:25:22 -07:00
|
|
|
_focus_layout_part(void *data, Evas_Object *o __UNUSED__, void *event_info __UNUSED__)
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
{
|
|
|
|
Evas_Object *ed = elm_layout_edje_get(data);
|
|
|
|
|
|
|
|
Evas_Object *newfocus = (Evas_Object *)edje_object_part_object_get(ed, "sky");
|
|
|
|
const char *type = evas_object_type_get(newfocus);
|
2012-02-15 20:55:08 -08:00
|
|
|
printf("evas_object_focus_set(%p, EINA_TRUE) %s\n", newfocus, type);
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
evas_object_focus_set(newfocus, EINA_TRUE);;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
2010-10-19 11:25:22 -07:00
|
|
|
test_focus2(void *data __UNUSED__, Evas_Object *obj __UNUSED__, void *event_info __UNUSED__)
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
{
|
2012-04-01 23:20:28 -07:00
|
|
|
Evas_Object *win, *bx, *ly, *bt, *en, *bt1;
|
2011-08-25 03:01:59 -07:00
|
|
|
char buf[PATH_MAX];
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
|
2012-04-01 23:20:28 -07:00
|
|
|
win = elm_win_util_standard_add("focus2", "Focus 2");
|
2011-07-25 07:22:19 -07:00
|
|
|
elm_win_autodel_set(win, EINA_TRUE);
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
elm_win_focus_highlight_enabled_set(win, EINA_TRUE);
|
|
|
|
|
|
|
|
evas_event_callback_add
|
|
|
|
(evas_object_evas_get(win), EVAS_CALLBACK_CANVAS_OBJECT_FOCUS_IN,
|
|
|
|
_focus_in, NULL);
|
|
|
|
evas_event_callback_add
|
|
|
|
(evas_object_evas_get(win), EVAS_CALLBACK_CANVAS_OBJECT_FOCUS_OUT,
|
|
|
|
_focus_out, NULL);
|
|
|
|
|
|
|
|
bx = elm_box_add(win);
|
|
|
|
elm_win_resize_object_add(win, bx);
|
|
|
|
evas_object_size_hint_weight_set(bx, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
|
|
|
|
evas_object_show(bx);
|
|
|
|
|
|
|
|
#define PARENT bx /* this is broken, but should work */
|
|
|
|
//#define PARENT win
|
|
|
|
|
2011-06-17 02:44:31 -07:00
|
|
|
en = elm_entry_add(PARENT);
|
|
|
|
elm_entry_scrollable_set(en, EINA_TRUE);
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
evas_object_size_hint_weight_set(en, EVAS_HINT_EXPAND, 0.0);
|
|
|
|
evas_object_size_hint_align_set(en, EVAS_HINT_FILL, 0.5);
|
2011-06-17 02:44:31 -07:00
|
|
|
elm_entry_scrollbar_policy_set(en, ELM_SCROLLER_POLICY_OFF, ELM_SCROLLER_POLICY_OFF);
|
2012-03-08 06:08:04 -08:00
|
|
|
elm_object_text_set(en, "Entry that should get focus");
|
2012-02-15 20:55:08 -08:00
|
|
|
elm_entry_single_line_set(en, EINA_TRUE);
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
evas_object_show(en);
|
|
|
|
elm_box_pack_end(bx, en);
|
|
|
|
|
|
|
|
bt = elm_button_add(PARENT);
|
2012-03-08 06:08:04 -08:00
|
|
|
elm_object_text_set(bt, "Give focus to entry");
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
evas_object_smart_callback_add(bt, "clicked", _focus_obj, en);
|
|
|
|
elm_box_pack_end(bx, bt);
|
|
|
|
evas_object_show(bt);
|
|
|
|
|
|
|
|
ly = elm_layout_add(PARENT);
|
2011-08-25 03:01:59 -07:00
|
|
|
snprintf(buf, sizeof(buf), "%s/objects/test.edj", elm_app_data_dir_get());
|
|
|
|
elm_layout_file_set(ly, buf, "layout");
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
evas_object_size_hint_weight_set(ly, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
|
|
|
|
evas_object_size_hint_align_set(en, EVAS_HINT_FILL, EVAS_HINT_FILL);
|
|
|
|
elm_box_pack_end(bx, ly);
|
|
|
|
evas_object_show(ly);
|
|
|
|
|
|
|
|
bt1 = bt = elm_button_add(ly);
|
2011-06-29 00:11:54 -07:00
|
|
|
elm_object_text_set(bt, "Button 1");
|
2011-11-17 13:02:31 -08:00
|
|
|
elm_object_part_content_set(ly, "element1", bt);
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
|
2011-06-17 02:44:31 -07:00
|
|
|
en = elm_entry_add(ly);
|
|
|
|
elm_entry_scrollable_set(en, EINA_TRUE);
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
evas_object_size_hint_weight_set(en, EVAS_HINT_EXPAND, 0.0);
|
|
|
|
evas_object_size_hint_align_set(en, EVAS_HINT_FILL, 0.5);
|
2011-06-17 02:44:31 -07:00
|
|
|
elm_entry_scrollbar_policy_set(en, ELM_SCROLLER_POLICY_OFF, ELM_SCROLLER_POLICY_OFF);
|
2011-12-30 02:02:19 -08:00
|
|
|
elm_object_text_set(en, "Scrolled Entry that should get focus");
|
2012-02-15 20:55:08 -08:00
|
|
|
elm_entry_single_line_set(en, EINA_TRUE);
|
2011-11-17 13:02:31 -08:00
|
|
|
elm_object_part_content_set(ly, "element2", en);
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
|
|
|
|
bt = elm_button_add(ly);
|
2011-06-29 00:11:54 -07:00
|
|
|
elm_object_text_set(bt, "Button 2");
|
2011-11-17 13:02:31 -08:00
|
|
|
elm_object_part_content_set(ly, "element3", bt);
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
|
|
|
|
bt = elm_button_add(PARENT);
|
2011-06-29 00:11:54 -07:00
|
|
|
elm_object_text_set(bt, "Give focus to layout");
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
evas_object_smart_callback_add(bt, "clicked", _focus_obj, ly);
|
|
|
|
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_box_pack_end(bx, bt);
|
|
|
|
evas_object_show(bt);
|
|
|
|
|
|
|
|
bt = elm_button_add(PARENT);
|
2011-06-29 00:11:54 -07:00
|
|
|
elm_object_text_set(bt, "Give focus to layout part");
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
evas_object_smart_callback_add(bt, "clicked", _focus_layout_part, ly);
|
|
|
|
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_box_pack_end(bx, bt);
|
|
|
|
evas_object_show(bt);
|
|
|
|
|
|
|
|
bt = elm_button_add(PARENT);
|
2011-06-29 00:11:54 -07:00
|
|
|
elm_object_text_set(bt, "Give focus to layout 'Button 1'");
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
evas_object_smart_callback_add(bt, "clicked", _focus_obj, bt1);
|
|
|
|
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_box_pack_end(bx, bt);
|
|
|
|
evas_object_show(bt);
|
|
|
|
|
|
|
|
bt = elm_button_add(PARENT);
|
2011-06-29 00:11:54 -07:00
|
|
|
elm_object_text_set(bt, "Give focus to layout 'Entry'");
|
test focus brokenness.
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
2010-09-24 17:06:32 -07:00
|
|
|
evas_object_smart_callback_add(bt, "clicked", _focus_obj, en);
|
|
|
|
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_box_pack_end(bx, bt);
|
|
|
|
evas_object_show(bt);
|
|
|
|
|
|
|
|
evas_object_resize(win, 400, 400);
|
|
|
|
evas_object_show(win);
|
|
|
|
}
|
|
|
|
#endif
|