[E-devel] [PATCH] efm_nav keyboard shortcuts
Hello, All.
This patch adding keyboard shortcuts to efm_nav module.
When efm_nav placed on efm2 window toolbar, next shortcuts are activated:
Alt+Left -- backward in chdir's history,
Alt+Right -- forward in chdir's history,
Alt+Up-- go to parent dir,
Control+r -- refresh view of current dir.
e_mod_main.c | 39 +--
1 file changed, 37 insertions(+), 2 deletions(-)
Index: E-MODULES-EXTRA/efm_nav/src/e_mod_main.c
===
--- E-MODULES-EXTRA/efm_nav/src/e_mod_main.c(revision 40471)
+++ E-MODULES-EXTRA/efm_nav/src/e_mod_main.c(working copy)
@@ -23,6 +23,8 @@
static const char *_gc_id_new(E_Gadcon_Client_Class
*client_class);
static void _cb_mouse_down(void *data, Evas *e,
Evas_Object *obj, void *event_info);
+static void _cb_key_down (void *data, Evas *e,
+ Evas_Object *obj, void
*event_info);
static void _cb_back_click(void *data, Evas_Object *obj,
const char *emission,
const char *source);
@@ -58,6 +60,7 @@
_gc_init(E_Gadcon *gc, const char *name, const char *id, const char *style)
{
Instance *inst = NULL;
+ Evas_Object *o_fm;
char buf[4096];
inst = E_NEW(Instance, 1);
@@ -135,6 +138,10 @@
evas_object_event_callback_add(inst-o_base, EVAS_CALLBACK_MOUSE_DOWN,
_cb_mouse_down, inst);
+ o_fm = e_toolbar_fm2_get(inst-tbar);
+ if (o_fm)
+ evas_object_event_callback_add(o_fm, EVAS_CALLBACK_KEY_DOWN,
+_cb_key_down, inst);
edje_object_signal_emit(inst-o_back, e,state,disabled, e);
edje_object_message_signal_process(inst-o_back);
@@ -149,10 +156,14 @@
_gc_shutdown(E_Gadcon_Client *gcc)
{
Instance *inst = NULL;
+ Evas_Object *o_fm;
inst = gcc-data;
if (!inst) return;
instances = eina_list_remove(instances, inst);
+ o_fm = e_toolbar_fm2_get(inst-tbar);
+ if (o_fm)
+ evas_object_event_callback_del(o_fm, EVAS_CALLBACK_KEY_DOWN,
_cb_key_down);
if (inst-history) ecore_list_destroy(inst-history);
if (inst-o_favorites) evas_object_del(inst-o_favorites);
if (inst-o_back) evas_object_del(inst-o_back);
@@ -175,11 +186,11 @@
{
case E_GADCON_ORIENT_TOP:
case E_GADCON_ORIENT_BOTTOM:
- e_gadcon_client_aspect_set(gcc, 16 * 3, 16);
+ e_gadcon_client_aspect_set(gcc, 16 * 4, 16);
break;
case E_GADCON_ORIENT_LEFT:
case E_GADCON_ORIENT_RIGHT:
- e_gadcon_client_aspect_set(gcc, 16, 16 * 3);
+ e_gadcon_client_aspect_set(gcc, 16, 16 * 4);
break;
default:
break;
@@ -250,6 +261,30 @@
}
/* local functions */
+static void
+_cb_key_down(void *data, Evas *e, Evas_Object *obj, void *event_info)
+{
+ Instance *inst;
+ Evas_Event_Key_Down *ev;
+
+ inst = data;
+ ev = event_info;
+ if (evas_key_modifier_is_set(ev-modifiers, Alt))
+ {
+if (!strcmp(ev-key, Left))
+ _cb_back_click(inst, obj, e,action,click, e);
+else if (!strcmp(ev-key, Right))
+ _cb_forward_click(inst, obj, e,action,click, e);
+else if (!strcmp(ev-key, Up))
+ _cb_up_click(inst, obj, e,action,click, e);
+ }
+ else if (evas_key_modifier_is_set(ev-modifiers, Control))
+ {
+if (!strcmp(ev-key, r))
+ _cb_refresh_click(inst, obj, e,action,click, e);
+ }
+}
+
static void
_cb_mouse_down(void *data, Evas *e, Evas_Object *obj, void *event_info)
{
Sincerely yours, Sergey.
--
Jabber/XMPP: sergey.semer...@gmail.com
Cellular: +7-909-206-5992
Index: E-MODULES-EXTRA/efm_nav/src/e_mod_main.c
===
--- E-MODULES-EXTRA/efm_nav/src/e_mod_main.c (revision 40471)
+++ E-MODULES-EXTRA/efm_nav/src/e_mod_main.c (working copy)
@@ -23,6 +23,8 @@
static const char *_gc_id_new(E_Gadcon_Client_Class *client_class);
static void _cb_mouse_down(void *data, Evas *e,
Evas_Object *obj, void *event_info);
+static void _cb_key_down (void *data, Evas *e,
+ Evas_Object *obj, void *event_info);
static void _cb_back_click(void *data, Evas_Object *obj,
const char *emission,
const char *source);
@@ -58,6 +60,7 @@
_gc_init(E_Gadcon *gc, const char *name, const char *id, const char *style)
{
Instance *inst = NULL;
+ Evas_Object *o_fm;
char buf[4096];
inst = E_NEW(Instance, 1);
@@ -135,6 +138,10 @@
evas_object_event_callback_add(inst-o_base, EVAS_CALLBACK_MOUSE_DOWN,
_cb_mouse_down, inst);
+ o_fm = e_toolbar_fm2_get(inst-tbar);
+ if (o_fm)
+ evas_object_event_callback_add(o_fm,
Re: [E-devel] [RFC] background panning when changing desks
On Fri, 2009-05-01 at 10:33 +1000, Carsten Haitzler wrote:
On Fri, 01 May 2009 02:02:01 +0200 Viktor Kojouharov vkojouha...@gmail.com
said:
I've updated the patch with a few fixes and also with sending a message
with all the info that can be used to reproduce the animation (see line
249). The question is, how easy would be for a designer to use this info
and create the parallax effect in edje? I don't know embryo that much,
but I haven't seen a way to run a program and specify a transition for
it as well.
as per my previous mail - look at e_fwin.c - in fact COPY the code that is in
_e_fwin_pan_scroll_update(). ALL you need to do is figure out pan.x/y,
pan.max_x/max_y and pan.w/h for the desktop while scrolling.
pan.w/h would be the size of the zone (zone-w,h). pan.x/y would be top-left
x,y of the desktop relative to all the virtual desktops. i.e. pan.x = desk-x
*
zone-w, pan.y = desk-y * zone-h (and of course you need to interpolate this
as you slide/switch desks) and pan.max_x = (e_config-zone_desks_x_count - 1)
*
zone-w (and same for y).
i'm sure you can figure out the rest :) and you have a working example bg (the
fileman one) to test with (and build off). you'll get the idea.
And here's patch number three. I'm sending the same info that the fwin
is sending (current pos, total drag size and total size). It works great
so far. The only difference is that the bg_object itself slides from the
scrollframe, whereas the fwin bg theme needs to handle all the moving.
I could also look for a data item in the bg edje, which would tell me
whether I should not scroll the bg object itself, and let the edje
handle all changes, for ever more freedom in theming. Though I think
that by default, the bg object should scroll with desk change, since it
doesn't require any themeing (the user can just use a larger image, and
it will scroll without any edc programming).
cast: http://www.youtube.com/watch?v=AqUcbp0VvPc
p.s.: raster, since you have a bunch of screencasts on your site, what
program do you use to record the screen?
Index: src/bin/e_zone.c
===
--- src/bin/e_zone.c (revision 40414)
+++ src/bin/e_zone.c (working copy)
@@ -235,6 +235,8 @@ e_zone_move(E_Zone *zone, int x, int y)
zone-x = x;
zone-y = y;
evas_object_move(zone-bg_object, x, y);
+ if (zone-bg_scrollframe)
+ evas_object_move(zone-bg_scrollframe, x, y);
evas_object_move(zone-bg_event_object, x, y);
evas_object_move(zone-bg_clip_object, x, y);
@@ -287,6 +289,8 @@ e_zone_resize(E_Zone *zone, int w, int h)
zone-w = w;
zone-h = h;
evas_object_resize(zone-bg_object, w, h);
+ if (zone-bg_scrollframe)
+ evas_object_resize(zone-bg_scrollframe, w, h);
evas_object_resize(zone-bg_event_object, w, h);
evas_object_resize(zone-bg_clip_object, w, h);
@@ -345,9 +349,13 @@ e_zone_move_resize(E_Zone *zone, int x, int y, int
zone-h = h;
evas_object_move(zone-bg_object, x, y);
+ if (zone-bg_scrollframe)
+ evas_object_move(zone-bg_scrollframe, x, y);
evas_object_move(zone-bg_event_object, x, y);
evas_object_move(zone-bg_clip_object, x, y);
evas_object_resize(zone-bg_object, w, h);
+ if (zone-bg_scrollframe)
+ evas_object_resize(zone-bg_scrollframe, w, h);
evas_object_resize(zone-bg_event_object, w, h);
evas_object_resize(zone-bg_clip_object, w, h);
@@ -939,6 +947,8 @@ _e_zone_free(E_Zone *zone)
{
E_Container *con;
Eina_List *l;
+ Ecore_Animator *anim;
+ void *data;
int x, y;
/* Delete the edge windows if they exist */
@@ -988,9 +998,14 @@ _e_zone_free(E_Zone *zone)
con = zone-container;
if (zone-name) eina_stringshare_del(zone-name);
con-zones = eina_list_remove(con-zones, zone);
+ anim = evas_object_data_get(zone-bg_object, switch_animator);
+ if (anim) ecore_animator_del(anim);
+ data = evas_object_data_get(zone-bg_object, switch_animator_params);
+ if (data) E_FREE(data);
evas_object_del(zone-bg_event_object);
evas_object_del(zone-bg_clip_object);
evas_object_del(zone-bg_object);
+ evas_object_del(zone-bg_scrollframe);
if (zone-prev_bg_object) evas_object_del(zone-prev_bg_object);
if (zone-transition_object) evas_object_del(zone-transition_object);
Index: src/bin/e_zone.h
===
--- src/bin/e_zone.h (revision 40414)
+++ src/bin/e_zone.h (working copy)
@@ -48,6 +48,7 @@ struct _E_Zone
Evas_Object *bg_event_object;
Evas_Object *bg_clip_object;
Evas_Object *prev_bg_object;
+ Evas_Object *bg_scrollframe;
Evas_Object *transition_object;
int desk_x_count, desk_y_count;
Index: src/bin/e_config.c
===
--- src/bin/e_config.c (revision 40414)
+++ src/bin/e_config.c (working copy)
@@ -622,6 +622,9 @@
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Fri, May 01, 2009 at 10:13:09AM +1000, Carsten Haitzler wrote : On Thu, 30 Apr 2009 18:02:45 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Thu, Apr 30, 2009 at 10:11 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: Hello, While playing with Eina_Inlist, I noticed that given a pointer to an Eina_Inlist, one can't easily get a pointer to the structure containing it. The only option now is to put the Eina_Inlist first in the structure, and then cast this structure to an Eina_Inlist, which is far from optimal. I'd therefore like to propose that we add in eina_inlist.h a macro along the lines of #define FIND_A_SENSBILE_NAME_FOR_THIS(ptr, type) ((type *) ((Eina_Inlist *) #ptr - offsetof(type, __in_list))) Then, we could get a pointer to the containing structure, no matter where the Eina_Inlist is (note that I used __in_list as the member as we already have a macro '#define EINA_INLIST Eina_Inlist __in_list', but a member argument could be added just as well) Thoughts ? As we discussed on IRC, I like this. It would help avoid casts and try to make code bit easier to get right. much uglier as now you need to drag an offset Well, if the Eina_Inlist is the first member in the struct the compiler will probably optimize the substraction, as the offset would be 0. If it's not the first member, you need it anyway. # around all the time, and now you still need to cast anyway (use a raw pointer offset and cast to ah Inlist pointer). you don't get rid of it. Same here. The point is not only to avoid casts. It allows people to place the inlist wherever they want within a structure, and have easy access to it. Providing it in eina just doesn't cost anything, and allows people to do it painlessly. -- Albin Tonnerre signature.asc Description: Digital signature -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Thu, Apr 30, 2009 at 9:13 PM, Carsten Haitzler ras...@rasterman.com wrote: On Thu, 30 Apr 2009 18:02:45 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Thu, Apr 30, 2009 at 10:11 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: Hello, While playing with Eina_Inlist, I noticed that given a pointer to an Eina_Inlist, one can't easily get a pointer to the structure containing it. The only option now is to put the Eina_Inlist first in the structure, and then cast this structure to an Eina_Inlist, which is far from optimal. I'd therefore like to propose that we add in eina_inlist.h a macro along the lines of #define FIND_A_SENSBILE_NAME_FOR_THIS(ptr, type) ((type *) ((Eina_Inlist *) #ptr - offsetof(type, __in_list))) Then, we could get a pointer to the containing structure, no matter where the Eina_Inlist is (note that I used __in_list as the member as we already have a macro '#define EINA_INLIST Eina_Inlist __in_list', but a member argument could be added just as well) Thoughts ? As we discussed on IRC, I like this. It would help avoid casts and try to make code bit easier to get right. much uglier as now you need to drag an offset # around all the time, and now you still need to cast anyway (use a raw pointer offset and cast to ah Inlist pointer). you don't get rid of it. inheritance in c in the end requires casting. thats how c does it. dont be afraid of casting or think its ugly. it's how c becomes powerful and flexible. As the macro says, it still does the cast, BUT this cast will add some safety since if you change types somewhere and forget in some place, compiler will warn you. The only problem I see and I already talked to Albin about it is on weird compilers without offsetof() macros. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Fri, 1 May 2009, Gustavo Sverzut Barbieri wrote: On Thu, Apr 30, 2009 at 9:13 PM, Carsten Haitzler ras...@rasterman.com wrote: On Thu, 30 Apr 2009 18:02:45 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Thu, Apr 30, 2009 at 10:11 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: Hello, While playing with Eina_Inlist, I noticed that given a pointer to an Eina_Inlist, one can't easily get a pointer to the structure containing it. The only option now is to put the Eina_Inlist first in the structure, and then cast this structure to an Eina_Inlist, which is far from optimal. I'd therefore like to propose that we add in eina_inlist.h a macro along the lines of #define FIND_A_SENSBILE_NAME_FOR_THIS(ptr, type) ((type *) ((Eina_Inlist *) #ptr - offsetof(type, __in_list))) Then, we could get a pointer to the containing structure, no matter where the Eina_Inlist is (note that I used __in_list as the member as we already have a macro '#define EINA_INLIST Eina_Inlist __in_list', but a member argument could be added just as well) Thoughts ? As we discussed on IRC, I like this. It would help avoid casts and try to make code bit easier to get right. much uglier as now you need to drag an offset # around all the time, and now you still need to cast anyway (use a raw pointer offset and cast to ah Inlist pointer). you don't get rid of it. inheritance in c in the end requires casting. thats how c does it. dont be afraid of casting or think its ugly. it's how c becomes powerful and flexible. As the macro says, it still does the cast, BUT this cast will add some safety since if you change types somewhere and forget in some place, compiler will warn you. The only problem I see and I already talked to Albin about it is on weird compilers without offsetof() macros. offsetof seems to exist in the lib c of Microsoft Vincent -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Mouse events with elementary and python?
On Thu, Apr 30, 2009 at 10:17 PM, digger vermont dv_ml...@verizon.net wrote:
Hello All,
I'm working with the python bindings for elementary and can't figure out
how to use the mouse events. I can get them to work with a slider, but
with the frame and anchor block I tried it is not.
fr = elementary.Frame(win)
fr.label_set('Frame')
fr.size_hint_weight_set(1.0, 1.0)
fr.size_hint_align_set(-1.0, -1.0)
fr.on_mouse_move_add(print_event)
tb.pack(fr, 0, 0, 1, 1)
fr.show()
What am I missing?
probably fr has no parts that get events (see edje and
mouse_events:0). What are you trying to do? It's not safe to rely on
theme and add mouse_move yourself, you're supposed to either send
events from edje OR create your own transparent rectangle that get
mouse events (and put it in repeat mode).
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Fri, May 1, 2009 at 8:18 AM, Vincent Torri vto...@univ-evry.fr wrote: On Fri, 1 May 2009, Gustavo Sverzut Barbieri wrote: On Thu, Apr 30, 2009 at 9:13 PM, Carsten Haitzler ras...@rasterman.com wrote: On Thu, 30 Apr 2009 18:02:45 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Thu, Apr 30, 2009 at 10:11 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: Hello, While playing with Eina_Inlist, I noticed that given a pointer to an Eina_Inlist, one can't easily get a pointer to the structure containing it. The only option now is to put the Eina_Inlist first in the structure, and then cast this structure to an Eina_Inlist, which is far from optimal. I'd therefore like to propose that we add in eina_inlist.h a macro along the lines of #define FIND_A_SENSBILE_NAME_FOR_THIS(ptr, type) ((type *) ((Eina_Inlist *) #ptr - offsetof(type, __in_list))) Then, we could get a pointer to the containing structure, no matter where the Eina_Inlist is (note that I used __in_list as the member as we already have a macro '#define EINA_INLIST Eina_Inlist __in_list', but a member argument could be added just as well) Thoughts ? As we discussed on IRC, I like this. It would help avoid casts and try to make code bit easier to get right. much uglier as now you need to drag an offset # around all the time, and now you still need to cast anyway (use a raw pointer offset and cast to ah Inlist pointer). you don't get rid of it. inheritance in c in the end requires casting. thats how c does it. dont be afraid of casting or think its ugly. it's how c becomes powerful and flexible. As the macro says, it still does the cast, BUT this cast will add some safety since if you change types somewhere and forget in some place, compiler will warn you. The only problem I see and I already talked to Albin about it is on weird compilers without offsetof() macros. offsetof seems to exist in the lib c of Microsoft it's not a libc, rather compiler as it's executed at compile time. It works on struct and its members information, no dependency on real memory, pointers, ... -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Fri, May 01, 2009 at 01:18:38PM +0200, Vincent Torri wrote : On Fri, 1 May 2009, Gustavo Sverzut Barbieri wrote: On Thu, Apr 30, 2009 at 9:13 PM, Carsten Haitzler ras...@rasterman.com wrote: The only problem I see and I already talked to Albin about it is on weird compilers without offsetof() macros. offsetof seems to exist in the lib c of Microsoft And FWIW, ISO C (both 89 and 99) says it should be defined in stddef.h, so if it doesn't exist you probably have more serious problems than this. -- Albin Tonnerre signature.asc Description: Digital signature -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Finding focused window
On Fri, May 1, 2009 at 2:55 AM, Sergey Semernin sergey.semer...@gmail.com wrote: Hello, All. In message from 1 мая 2009 Gustavo Sverzut Barbieri wrote: Help please, how correctly find pointer to focused window? e_border_focused_get gives me pointer to E_Border* and how find window object from it? What do you want to do? But e_border is what you generally consider a toplevel window :-) It contains the window decorations (if any), actions like move, resize, center, show, hide... I try to get access to focused window's internal widgets, nor border and decorations. For example: check the smart type ID, then find needed widget and check it's state. that's bit bad, avoid going that route. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efm_Nav keyboard shortcuts
On Fri, May 1, 2009 at 2:52 AM, Sergey Semernin sergey.semer...@gmail.com wrote: Hello, All. In message from 1 мая 2009 Gustavo Sverzut Barbieri wrote: Situation: efm_nav has a directory change history list. To make keyboard shortcust for up, prev, next I should use EVAS_CALLBACK_KEY_DOWN if widget catch keyboard events. But, efm_nav have'nt focus and not receive this events. need to look at it, but maybe you can connect to parent object (e_fm)? Or even add system to e_fm to register keyboard handlers, so if it does not handle, it will call the list until some function returns TRUE. Then maybe make evas_object_smart_callback_call's in the _e_fm2_cb_key_down and then catch it in efm_nav? can be. :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Fri, May 1, 2009 at 8:34 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Fri, May 01, 2009 at 01:18:38PM +0200, Vincent Torri wrote : On Fri, 1 May 2009, Gustavo Sverzut Barbieri wrote: On Thu, Apr 30, 2009 at 9:13 PM, Carsten Haitzler ras...@rasterman.com wrote: The only problem I see and I already talked to Albin about it is on weird compilers without offsetof() macros. offsetof seems to exist in the lib c of Microsoft And FWIW, ISO C (both 89 and 99) says it should be defined in stddef.h, so if it doesn't exist you probably have more serious problems than this. excellent, so no problems! -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] efm_nav keyboard shortcuts
On Fri, May 1, 2009 at 4:02 AM, Sergey Semernin
sergey.semer...@gmail.com wrote:
Hello, All.
This patch adding keyboard shortcuts to efm_nav module.
When efm_nav placed on efm2 window toolbar, next shortcuts are activated:
Just a small comment, other than that looks good to be included:
@@ -175,11 +186,11 @@
{
case E_GADCON_ORIENT_TOP:
case E_GADCON_ORIENT_BOTTOM:
- e_gadcon_client_aspect_set(gcc, 16 * 3, 16);
+ e_gadcon_client_aspect_set(gcc, 16 * 4, 16);
break;
case E_GADCON_ORIENT_LEFT:
case E_GADCON_ORIENT_RIGHT:
- e_gadcon_client_aspect_set(gcc, 16, 16 * 3);
+ e_gadcon_client_aspect_set(gcc, 16, 16 * 4);
break;
default:
break;
why is that?
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] background panning when changing desks
I've updated the patch with a few fixes and also with sending a message with all the info that can be used to reproduce the animation (see line 249). The question is, how easy would be for a designer to use this info and create the parallax effect in edje? I don't know embryo that much, but I haven't seen a way to run a program and specify a transition for it as well. I cant quite get this patch to work here. I get the options in the Virtual Desktops dialog, but no cool panning. Also, it seems to break the desktop wallpaper? Reverting now for more testing. -Toma. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
Gustavo Sverzut Barbieri schrieb: On Fri, May 1, 2009 at 8:18 AM, Vincent Torri vto...@univ-evry.fr wrote: On Fri, 1 May 2009, Gustavo Sverzut Barbieri wrote: On Thu, Apr 30, 2009 at 9:13 PM, Carsten Haitzler ras...@rasterman.com wrote: On Thu, 30 Apr 2009 18:02:45 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Thu, Apr 30, 2009 at 10:11 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: Hello, While playing with Eina_Inlist, I noticed that given a pointer to an Eina_Inlist, one can't easily get a pointer to the structure containing it. The only option now is to put the Eina_Inlist first in the structure, and then cast this structure to an Eina_Inlist, which is far from optimal. I'd therefore like to propose that we add in eina_inlist.h a macro along the lines of #define FIND_A_SENSBILE_NAME_FOR_THIS(ptr, type) ((type *) ((Eina_Inlist *) #ptr - offsetof(type, __in_list))) Then, we could get a pointer to the containing structure, no matter where the Eina_Inlist is (note that I used __in_list as the member as we already have a macro '#define EINA_INLIST Eina_Inlist __in_list', but a member argument could be added just as well) Thoughts ? As we discussed on IRC, I like this. It would help avoid casts and try to make code bit easier to get right. much uglier as now you need to drag an offset # around all the time, and now you still need to cast anyway (use a raw pointer offset and cast to ah Inlist pointer). you don't get rid of it. inheritance in c in the end requires casting. thats how c does it. dont be afraid of casting or think its ugly. it's how c becomes powerful and flexible. As the macro says, it still does the cast, BUT this cast will add some safety since if you change types somewhere and forget in some place, compiler will warn you. The only problem I see and I already talked to Albin about it is on weird compilers without offsetof() macros. offsetof seems to exist in the lib c of Microsoft it's not a libc, rather compiler as it's executed at compile time. It works on struct and its members information, no dependency on real memory, pointers, ... It's a macro in stddef.h, so it's part of the libc. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] efm_nav keyboard shortcuts
Hello, All.
In message from 1 мая 2009 Gustavo Sverzut Barbieri wrote:
Just a small comment, other than that looks good to be included:
@@ -175,11 +186,11 @@
{
case E_GADCON_ORIENT_TOP:
case E_GADCON_ORIENT_BOTTOM:
- e_gadcon_client_aspect_set(gcc, 16 * 3, 16);
+ e_gadcon_client_aspect_set(gcc, 16 * 4, 16);
break;
case E_GADCON_ORIENT_LEFT:
case E_GADCON_ORIENT_RIGHT:
- e_gadcon_client_aspect_set(gcc, 16, 16 * 3);
+ e_gadcon_client_aspect_set(gcc, 16, 16 * 4);
break;
default:
break;
why is that?
Efm_nav button glyphs were covered each other, when I changed it, buttons are
displaying well, side by side.
Sincerely yours, Sergey.
--
Jabber/XMPP: sergey.semer...@gmail.com
Cellular: +7-909-206-5992
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] background panning when changing desks
On Fri, 2009-05-01 at 21:05 +0800, Toma wrote:
I've updated the patch with a few fixes and also with sending a message
with all the info that can be used to reproduce the animation (see line
249). The question is, how easy would be for a designer to use this info
and create the parallax effect in edje? I don't know embryo that much,
but I haven't seen a way to run a program and specify a transition for
it as well.
I cant quite get this patch to work here. I get the options in the
Virtual Desktops dialog, but no cool panning. Also, it seems to break
the desktop wallpaper? Reverting now for more testing.
-Toma.
You could try with this patch. It fixes some minor things, and adds the
'directional_freedom' data item, which can restrict the actual bg object
scrolling in the x/y direction:
E.g: data.item: directional_freedom 1 0;
will restrict actual scrolling in the x direction, leaving all logic for
the edje file.
Index: src/bin/e_zone.c
===
--- src/bin/e_zone.c (revision 40414)
+++ src/bin/e_zone.c (working copy)
@@ -235,6 +235,8 @@ e_zone_move(E_Zone *zone, int x, int y)
zone-x = x;
zone-y = y;
evas_object_move(zone-bg_object, x, y);
+ if (zone-bg_scrollframe)
+ evas_object_move(zone-bg_scrollframe, x, y);
evas_object_move(zone-bg_event_object, x, y);
evas_object_move(zone-bg_clip_object, x, y);
@@ -287,6 +289,8 @@ e_zone_resize(E_Zone *zone, int w, int h)
zone-w = w;
zone-h = h;
evas_object_resize(zone-bg_object, w, h);
+ if (zone-bg_scrollframe)
+ evas_object_resize(zone-bg_scrollframe, w, h);
evas_object_resize(zone-bg_event_object, w, h);
evas_object_resize(zone-bg_clip_object, w, h);
@@ -345,9 +349,13 @@ e_zone_move_resize(E_Zone *zone, int x, int y, int
zone-h = h;
evas_object_move(zone-bg_object, x, y);
+ if (zone-bg_scrollframe)
+ evas_object_move(zone-bg_scrollframe, x, y);
evas_object_move(zone-bg_event_object, x, y);
evas_object_move(zone-bg_clip_object, x, y);
evas_object_resize(zone-bg_object, w, h);
+ if (zone-bg_scrollframe)
+ evas_object_resize(zone-bg_scrollframe, w, h);
evas_object_resize(zone-bg_event_object, w, h);
evas_object_resize(zone-bg_clip_object, w, h);
@@ -939,6 +947,8 @@ _e_zone_free(E_Zone *zone)
{
E_Container *con;
Eina_List *l;
+ Ecore_Animator *anim;
+ void *data;
int x, y;
/* Delete the edge windows if they exist */
@@ -988,9 +998,14 @@ _e_zone_free(E_Zone *zone)
con = zone-container;
if (zone-name) eina_stringshare_del(zone-name);
con-zones = eina_list_remove(con-zones, zone);
+ anim = evas_object_data_get(zone-bg_object, switch_animator);
+ if (anim) ecore_animator_del(anim);
+ data = evas_object_data_get(zone-bg_object, switch_animator_params);
+ if (data) E_FREE(data);
evas_object_del(zone-bg_event_object);
evas_object_del(zone-bg_clip_object);
evas_object_del(zone-bg_object);
+ evas_object_del(zone-bg_scrollframe);
if (zone-prev_bg_object) evas_object_del(zone-prev_bg_object);
if (zone-transition_object) evas_object_del(zone-transition_object);
Index: src/bin/e_zone.h
===
--- src/bin/e_zone.h (revision 40414)
+++ src/bin/e_zone.h (working copy)
@@ -48,6 +48,7 @@ struct _E_Zone
Evas_Object *bg_event_object;
Evas_Object *bg_clip_object;
Evas_Object *prev_bg_object;
+ Evas_Object *bg_scrollframe;
Evas_Object *transition_object;
int desk_x_count, desk_y_count;
Index: src/bin/e_config.c
===
--- src/bin/e_config.c (revision 40414)
+++ src/bin/e_config.c (working copy)
@@ -622,6 +622,9 @@ e_config_init(void)
E_CONFIG_VAL(D, T, desk_flip_animate_mode, INT);
E_CONFIG_VAL(D, T, desk_flip_animate_interpolation, INT);
E_CONFIG_VAL(D, T, desk_flip_animate_time, DOUBLE);
+ E_CONFIG_VAL(D, T, desk_flip_pan_bg, UCHAR);
+ E_CONFIG_VAL(D, T, desk_flip_pan_x_axis_factor, DOUBLE);
+ E_CONFIG_VAL(D, T, desk_flip_pan_y_axis_factor, DOUBLE);
E_CONFIG_VAL(D, T, wallpaper_import_last_dev, STR);
E_CONFIG_VAL(D, T, wallpaper_import_last_path, STR);
@@ -915,6 +918,12 @@ e_config_load(void)
e_config-screensaver_ask_presentation_timeout = 30.0;
IFCFGEND;
+IFCFG(0x0133);
+COPYVAL(desk_flip_pan_bg);
+COPYVAL(desk_flip_pan_x_axis_factor);
+COPYVAL(desk_flip_pan_y_axis_factor);
+IFCFGEND;
+
e_config-config_version = E_CONFIG_FILE_VERSION;
_e_config_free(tcfg);
}
@@ -1017,6 +1026,9 @@ e_config_load(void)
E_CONFIG_LIMIT(e_config-desk_flip_wrap, 0, 1);
E_CONFIG_LIMIT(e_config-fullscreen_flip, 0, 1);
E_CONFIG_LIMIT(e_config-icon_theme_overrides, 0, 1);
+ E_CONFIG_LIMIT(e_config-desk_flip_pan_bg, 0, 1);
+
Re: [E-devel] [PATCH] efm_nav keyboard shortcuts
Hello, All. In message from 1 мая 2009 sda wrote: sorry, but is it possible to make keys as variables through the Input - Key Bindings window? right now we have Esc binded as go back for EFM and suppose that it'd be enough for hardcoded keybindings. thanks. It is possible, I had variant with e_actions setup, but Gustavo says that it is not the purpose of e_action. When I'm using e_action's I also setup focus/unfocus events to watch what instance of efm_nav activated now. Sincerely yours, Sergey. -- Jabber/XMPP: sergey.semer...@gmail.com Cellular: +7-909-206-5992 -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] edje: emit signal to 'GROUP' part
I'm relatively new to edje, been picking most things up rather quickly. There's one thing I would like to accomplish, but haven't managed yet: How can I emit a signal to a 'type: GROUP' part, to be received by a program in that group? The other way around is easy, a signal from source groupname:partname is received just fine. But edje_cc doesn't allow me to use the groupname:partname convention in a target, or as a program name. And I assume that this isn't just a limitation of edje_cc. My experience is that edje data collections will grow quickly, and it will become more and more difficult to keep track of the whole thing, as it grows. Putting different screens and even certain parts of windows into separate subgroups really helps to keep things tidy. But these groups need to communicate with eachother. A possible workaround is emitting a signal to the application code, and letting the application emit the signal to the (sub)group. I'm doing that now, so I can at least get the desired functionality. But that's not very nice, especially when those signals are not meant for the application to act upon, just for graphical effects in the userinterface. Changing the userinterface would mean changing the application, to accomodate all new signal connections between the various parts. Note that I don't just mean changing a theme, my goal is to have a userinterface which controls not just the way things look, but also the way things work, which steps the user has to take, and in which order. Another possible way around this is not to use seperate groups for the different windows / window regions, so every component can signal every other component in the same large group (and perhaps just put different building blocks into different files, to keep a bit of overview) So my question, again, is it possible to interact with a subgroup? Emit a signal to it, or perhaps run a subgroup program directly? If not, what would be the prefered way to structure large edc's? Rgds, Pieter -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] fm2 auto-mount on insert for removable devices
2009/4/30 Luca De Marini luca.darkmas...@gmail.com 2009/4/30 Viktor Kojouharov vkojouha...@gmail.com On Thu, 2009-04-30 at 18:01 -0300, Gustavo Sverzut Barbieri wrote: On Thu, Apr 30, 2009 at 3:45 AM, Sergey Semernin sergey.semer...@gmail.com wrote: Hello, All. In the release plan 'fm2 auto-mount on insert for removable devices, possible import places to e/src/modules (with a better name?) See #229' issue present. Are you plan to move places functionality to efm2? Or 'places' module will be enabled by default and stay 'as is'? DaveMDS can say more about it as he started to merge places into efm, but places should disappear or be just the fancy gadget and be integrated into e17 (src/modules). What needs to be done is pull place's e_hal notifications to be notified when volumes are plugged in and check for automount flag, in this case mount and open efwin. This should be done in src/modules/fileman as much as possible. Personally, I'm a bit against places disappearing altogether. It looks nice on the desktop, and it will look even nicer in a sidebar-like gadcon in the fwin. Same here for me Viktor :) Yes, I'm workin on this, still need some time to make a clean hal event management. Dave Luca D.M. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje: emit signal to 'GROUP' part
pieterg wrote: I'm relatively new to edje, been picking most things up rather quickly. There's one thing I would like to accomplish, but haven't managed yet: How can I emit a signal to a 'type: GROUP' part, to be received by a program in that group? The other way around is easy, a signal from source groupname:partname is received just fine. But edje_cc doesn't allow me to use the groupname:partname convention in a target, or as a program name. And I assume that this isn't just a limitation of edje_cc. I can't recall a damn thing about this anymore, Brian Mattern (aka. rephorm) did the work for this. Maybe others can help you here, but it's likely not too difficult to implement what you want edje to do here.. if indeed it's not possible to do so already. My experience is that edje data collections will grow quickly, and it will become more and more difficult to keep track of the whole thing, as it grows. Putting different screens and even certain parts of windows into separate subgroups really helps to keep things tidy. But these groups need to communicate with eachother. That they should. It would also be nice if you could define more complex structures, like 'widgets', declaratively and have them be 'swallowed'. Or be able to fully extend edc to have groups as specific kinds of declarative types, or any number of other interesting things. Some work related to this was done by Hisham on the etk based evolve (a lib and simple gui builder based on an edc kind of declarative format for defining etk widget types, which allowed you to reference edje theme groups). Perhaps ewl, or the new elementary widget set, might have something like that in mind as well - don't know. A possible workaround is emitting a signal to the application code, and letting the application emit the signal to the (sub)group. I'm doing that now, so I can at least get the desired functionality. But that's not very nice, especially when those signals are not meant for the application to act upon, just for graphical effects in the userinterface. Changing the userinterface would mean changing the application, to accomodate all new signal connections between the various parts. Note that I don't just mean changing a theme, my goal is to have a userinterface which controls not just the way things look, but also the way things work, which steps the user has to take, and in which order. Well, that's kind of the 'holy grail' of gui programming isn't it.. How to be able to easily define the look and behavior. In this case via some declarative format plus minimal logic or scripting. Or at least, to do as much of this as possible. Hence there are things like css, html, xul, mxml, xaml,.. and assorted scripting languages, and a variety of gui builders/designers around those. Big important stuff in the gui world at large it seems. I recall seeing something about a Mozilla based desktop-shell called Pyro for which you could actually use html,xul,css, ... (plus some javascript) to define the actual desktop - very interesting. Edje/edc itself is somewhat limited right now - the group part was an attempt to allow for some amount of re-usability and for some amount of tree-structuring that was similar to the external 'swallow' model, but I can't recall how much of it was finished. There may also have been some extension to embryo to have something like an on_load function... can't recall for certain though. More is definitely needed.. whether as part of edje itself, or via some other lib, or whatnot. And of course gui builders/designers are likely the only real way that most people would ever be able to do large amounts of complex stuff. Another possible way around this is not to use seperate groups for the different windows / window regions, so every component can signal every other component in the same large group (and perhaps just put different building blocks into different files, to keep a bit of overview) So my question, again, is it possible to interact with a subgroup? Emit a signal to it, or perhaps run a subgroup program directly? If not, what would be the prefered way to structure large edc's? Rgds, Pieter Earn a degree in Criminal Justice and work as a Police officer. Click here for more info. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTEe1V7Gxz3fMuXs4f0BZi87LdhfLT8axjJrtQqqQyHx1mFudSNVvy/ -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___
