Re: [E-devel] [Patch][elm_map] Fix zoom rotated coordinates bug
After consideration, I think that elm_map_utils_size_get() and
elm_map_utils_region_get() is not needed for users. because only
functions related to geographic coordinates are only concern of users.
And converting func. from canvas to geo is needed for finding exact
geo-coordinates in canvas area.
So, I have modified patches.
Anyway, no one may interested in elm_maps...
Please review this patchplz...
2012/1/2 Bluezery ohpo...@gmail.com:
Hi,
In my point of view, elm_map did not consider zooming rotation by
using Evas_Map initially.
There are no problems if you use only elm_map_zoom_set(). But if you
use pinch gesture or wheel to do subtle zooming rotating, the
calculations of coordinates are not correct currently.
I have fixed these problem and also made some utility APIs for user
convenience.
I made following 3 APIs.
1. elm_map_utils_size_get()
Currently users can only get integer zoom level by using elm_map_zoom_get().
So if user want to calculate full map size, user should calculate
pow(2.0, zoom level) * tile size. Furthermore, user assumes tile size
as 256. (tile size can be changed!!)
Also it's not correct sometimes because Evas_map is used for subtle
zooming between zoom levels.
Above APIs return correct full map size.
2. elm_map_utils_region_get()
It can used for getting left top coordinates, center coordinates and
width, height of currently shown map area.
3. elm_map_utils_convert_canvas_into_geo()
Currently it is hard to converting x, y coordinates to geographical
longitude, latitude because of subtle zooming rotating.
If use wants to get it, user uses combination of above functions and
more. It is harsh job.
This function is used for getting longitude, latitude from x, y
coordinates of current viewport.
Test application can be brief by using above functions .
Please review this patch.
--
BRs,
Kim.
--
BRs,
Kim.
Index: src/lib/elm_map.c
===
--- src/lib/elm_map.c (리비전 66983)
+++ src/lib/elm_map.c (작업 사본)
@@ -2948,6 +2948,50 @@ rotate_end_cb(void *data, void *event_in
return EVAS_EVENT_FLAG_NONE;
}
+static void
+_region_get(Widget_Data *wd, Evas_Coord *x, Evas_Coord *y, Evas_Coord *cx, Evas_Coord *cy, Evas_Coord *w, Evas_Coord *h)
+{
+ EINA_SAFETY_ON_NULL_RETURN(wd);
+ Evas_Coord sx, sy, tx, ty, tcx, tcy, sw, sh, tw, th, rw, rh;
+
+ elm_smart_scroller_child_pos_get(wd-scr, sx, sy);
+ elm_smart_scroller_child_viewport_size_get(wd-scr, sw, sh);
+ rw = wd-size.w * wd-pinch.level;
+ rh = wd-size.h * wd-pinch.level;
+
+ if (wd-size.w sw)
+ {
+tw = rw;
+tcx = sx + tw/2;
+tx = sx + (sw - tw)/2;
+ }
+ else
+ {
+tw = sw;
+tcx = (sx + tw/2) * wd-pinch.level;
+tx = tcx - tw/2;
+
+ }
+ if (wd-size.h sh)
+ {
+th = rh;
+ty = sy + (sh - th)/2;
+tcy = sy + th/2;
+ }
+ else
+ {
+th = sw;
+tcy = (sy + th/2) * wd-pinch.level;
+ty = tcy - th/2;
+ }
+
+ if (x) *x = tx;
+ if (y) *y = ty;
+ if (cx) *cx= tcx;
+ if (cy) *cy = tcy;
+ if (w) *w = tw;
+ if (h) *h = th;
+}
#endif
EAPI Evas_Object *
@@ -3357,17 +3401,16 @@ elm_map_geo_region_get(const Evas_Object
#ifdef HAVE_ELEMENTARY_ECORE_CON
ELM_CHECK_WIDTYPE(obj, widtype);
Widget_Data *wd = elm_widget_data_get(obj);
- Evas_Coord sx, sy, sw, sh;
-
- if (!wd) return;
- elm_smart_scroller_child_pos_get(wd-scr, sx, sy);
- elm_smart_scroller_child_viewport_size_get(wd-scr, sw, sh);
- if (wd-size.w sw) sw = wd-size.w;
- if (wd-size.h sh) sh = wd-size.h;
- sx += sw / 2;
- sy += sh / 2;
+ Evas_Coord cx, cy;
+ int rw;
+ double tlon, tlat;
+ EINA_SAFETY_ON_NULL_RETURN(wd);
- elm_map_utils_convert_coord_into_geo(obj, sx, sy, wd-size.w, lon, lat);
+ _region_get(wd, NULL, NULL, cx, cy, NULL, NULL);
+ rw = wd-size.w * wd-pinch.level;
+ elm_map_utils_convert_coord_into_geo(obj, cx, cy, rw, tlon, tlat);
+ if (lon) *lon = tlon;
+ if (lat) *lat = tlat;
#else
(void) obj;
(void) lon;
@@ -3569,10 +3612,50 @@ elm_map_utils_convert_name_into_coord(co
}
EAPI void
-elm_map_utils_rotate_coord(const Evas_Object *obj __UNUSED__, const Evas_Coord x, const Evas_Coord y, const Evas_Coord cx, const Evas_Coord cy, const double degree, Evas_Coord *xx, Evas_Coord *yy)
+elm_map_convert_canvas_into_geo(const Evas_Object *obj, const Evas_Coord x, const Evas_Coord y, double *lon, double *lat)
{
#ifdef HAVE_ELEMENTARY_ECORE_CON
- if ((!xx) || (!yy)) return;
+ ELM_CHECK_WIDTYPE(obj, widtype);
+ Widget_Data *wd = elm_widget_data_get(obj);
+ EINA_SAFETY_ON_NULL_RETURN(lon);
+ EINA_SAFETY_ON_NULL_RETURN(lat);
+ EINA_SAFETY_ON_NULL_RETURN(wd);
+
+ Evas_Coord xx, yy, w, h, mw, tx, ty, cx, cy;
+ double d;
+
+ _region_get(wd, xx, yy, cx, cy, w, h);
+ mw = wd-size.w * wd-pinch.level;
+ if (w mw)
+ {
+xx += x;
+yy += y;
+ }
+
[E-devel] [PATCH] fix build error of ecore_imf_xim when using --disable-xim option
Hello, EFL developers.
When building ecore with --disable-xim option, build error occurs.
This patch will solve this build error problem.
Would you please review and apply in svn?
Index: src/modules/immodules/xim/ecore_imf_xim.c
===
--- src/modules/immodules/xim/ecore_imf_xim.c (revision 66991)
+++ src/modules/immodules/xim/ecore_imf_xim.c (working copy)
@@ -108,6 +108,7 @@ static void xim_destroy_callback(XIM xim,
XPointer call_data);
#endif
+#ifdef ENABLE_XIM
static unsigned int
utf8_offset_to_index(const char *str, int offset)
{
@@ -120,6 +121,7 @@ utf8_offset_to_index(const char *str, int offset)
return index;
}
+#endif
static void
_ecore_imf_context_xim_add(Ecore_IMF_Context *ctx)
@@ -233,6 +235,7 @@ _ecore_imf_context_xim_preedit_string_with_attribu
{
EINA_LOG_DBG(in);
+#ifdef ENABLE_XIM
Ecore_IMF_Context_Data *imf_context_data = ecore_imf_context_data_get(ctx);
_ecore_imf_context_xim_preedit_string_get(ctx, str, cursor_pos);
@@ -260,6 +263,14 @@ _ecore_imf_context_xim_preedit_string_with_attribu
if (start = 0)
add_feedback_attr (attrs, *str, last_feedback, start, i);
+#else
+ if(str)
+ *str = NULL;
+ if(attrs)
+ *attrs = NULL;
+ if(cursor_pos)
+ *cursor_pos = 0;
+#endif
}
static void
@@ -398,6 +409,7 @@ _ecore_imf_context_xim_use_preedit_set(Ecore_IMF_C
#endif
}
+#ifdef ENABLE_XIM
static void
add_feedback_attr (Eina_List **attrs,
const char *str,
@@ -427,6 +439,7 @@ add_feedback_attr (Eina_List **attrs,
if (feedback XIMHighlight)
attr-preedit_type = ECORE_IMF_PREEDIT_TYPE_SUB3;
}
+#endif
static void
_ecore_imf_context_xim_cursor_location_set (Ecore_IMF_Context *ctx,
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [patch] elm_map - bugfix small errors
Dear all
After run map menu in elementary_test, i found some minor errors
1. some passing data ptr is wrong at obj_rotate_zoom
2. clipped part isn't set by rect
thanks
Index: elementary/src/lib/elm_map.c
===
--- elementary/src/lib/elm_map.c(리비전 66989)
+++ elementary/src/lib/elm_map.c(작업 사본)
@@ -2353,12 +2353,12 @@
evas_object_move(group-bubble, xx, yy);
evas_object_resize(group-bubble, ww, hh);
- obj_rotate_zoom(group-wd, group-bubble);
+ obj_rotate_zoom(group-wd-obj, group-bubble);
evas_object_show(group-bubble);
evas_object_move(group-rect, xx, yy);
evas_object_resize(group-rect, ww, hh);
- obj_rotate_zoom(group-wd, group-rect);
+ obj_rotate_zoom(group-wd-obj, group-rect);
evas_object_show(group-rect);
}
Index: elementary/data/themes/widgets/map.edc
===
--- elementary/data/themes/widgets/map.edc (리비전 66989)
+++ elementary/data/themes/widgets/map.edc (작업 사본)
@@ -672,6 +672,7 @@
}
parts {
part { name: clipper;
+ type: RECT;
mouse_events: 1;
description { state: default 0.0;
color: 255 255 255 0;
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. Despite it wasn't documented when a person tried to unswallow she realized it was visible, or maybe she looked at the code. Consequently, she didn't forced to show the object with evas_object_show(), what will be mandatory now. So Hermet is correct, it can break applications and won't be something simple to see like an API breakage. People will spend a good time to realize what changed. Sure, we can help with that warning as we can (changelog, msg to mail list, docs, etc). I'm not against the change, but definitely this kind of change need to be more visible for users. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Bruno Dilly Senior Developer ProFUSION embedded systems http://profusion.mobi -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. Despite it wasn't documented when a person tried to unswallow she realized it was visible, or maybe she looked at the code. Consequently, she didn't forced to show the object with evas_object_show(), what will be mandatory now. So Hermet is correct, it can break applications and won't be something simple to see like an API breakage. People will spend a good time to realize what changed. Sure, we can help with that warning as we can (changelog, msg to mail list, docs, etc). This is a bug in the application, that rely on luck more than anything if it worked at any point in time. As I said, if any application rely on it now, just let me touch the edj and it will be broken completly. So no, this is not a big change. And I really doubt that any application outside as this kind of bug that goes unnoticed. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote:
On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote:
On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote:
On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote:
I think both are no problems if it has a documentation.
But your patch may break applications already released.
It will be better to apply your patch when major version is changed.
As I say, current behaviour is undefined. If you go out of an
animation (defined in the edj itself) in any state (hidden, moved,
resized, whatever), it will stay in that state. But this is completly
random and not defined (as in, depend on an external file). Now I do
like the raster proposal with an orphaned flag as it is the only sane
way to detect any leak. Relying on an undefined visual artefact would
not help at all.
It isn't documented. But it's defined, IMHO, since you can predict it.
As you said, in an animation it will keep the state, if it was
visible, it will stay visible.
So applications can be considering a unswallowed object will be
visible, since it was visible, and now it will be hidden.
No, as it is defined in the theme, it doesn't depend on the
application. If you change the theme, the animation, anything in the
.edj, it will change the behaviour in the application itself. It's
full of race condition. There is no sane way to expect any kind of
behaviour in the app. It is definitivly an undefined behaviour, as
their is no way you could know the state of the object without
requesting it after the unswallow.
OK, my concept of application is code and theme.
Anyway, a simple case is to add an rectangle to a swallow in a layout.
I've attached a quick example. As you can see, no luck required. After
3 seconds the rectangle is unswallowed and displayed at 0,0.
I agree that most of time people will be hiding or deleting the
object, but as far as I saw we can't predict how user will use our
documented API, what about not documented behaviour...
Despite it wasn't documented when a person tried to unswallow she
realized it was visible, or maybe she looked at the code.
Consequently, she didn't forced to show the object with
evas_object_show(), what will be mandatory now. So Hermet is correct,
it can break applications and won't be something simple to see like an
API breakage. People will spend a good time to realize what changed.
Sure, we can help with that warning as we can (changelog, msg to mail
list, docs, etc).
This is a bug in the application, that rely on luck more than anything
if it worked at any point in time. As I said, if any application rely
on it now, just let me touch the edj and it will be broken completly.
So no, this is not a big change. And I really doubt that any
application outside as this kind of bug that goes unnoticed.
--
Cedric BAIL
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Bruno Dilly
Senior Developer
ProFUSION embedded systems
http://profusion.mobi
#include Ecore.h
#include Evas.h
#include Ecore_Evas.h
#include Edje.h
Eina_Bool
_unswallow_cb(void *data)
{
Evas_Object *layout, *rect;
layout = data;
rect = edje_object_part_swallow_get(layout, swallow);
edje_object_part_unswallow(layout, rect);
evas_object_move(rect, 0, 0);
return ECORE_CALLBACK_CANCEL;
}
int
main (int argc, char *argv[])
{
Ecore_Evas *ee = NULL;
Evas *evas;
Evas_Object *layout, *rect;
ecore_evas_init();
edje_init();
ee = ecore_evas_new(NULL, 0, 0, 200, 200, NULL);
ecore_evas_show(ee);
evas = ecore_evas_get(ee);
layout = edje_object_add(evas);
edje_object_file_set(layout, test.edj, main);
evas_object_resize(layout, 200, 200);
evas_object_show(layout);
rect = evas_object_rectangle_add(evas);
evas_object_color_set(rect, 255, 0, 0, 255);
evas_object_resize(rect, 100, 100);
edje_object_part_swallow(layout, swallow, rect);
ecore_timer_add(3, _unswallow_cb, layout);
ecore_main_loop_begin();
return 0;
}
test.edc
Description: Binary data
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. OK, my concept of application is code and theme. Anyway, a simple case is to add an rectangle to a swallow in a layout. I've attached a quick example. As you can see, no luck required. After 3 seconds the rectangle is unswallowed and displayed at 0,0. Ok, I see the difference. From my point of view, the application should never trust an edj file. So if I can break your consistent behaviour by just touching the edc file, then their is a bug in the application from my point of view. In your example. I just need to set visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break your app. So you are just lucky that no one touched your edc file. From my point of view, an edj is a black box that can do anything. There is no such thing like when I unswallow all my theme will always resize the object and make them properly visible. That's why I see this as an undefined behaviour. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. OK, my concept of application is code and theme. Anyway, a simple case is to add an rectangle to a swallow in a layout. I've attached a quick example. As you can see, no luck required. After 3 seconds the rectangle is unswallowed and displayed at 0,0. Ok, I see the difference. From my point of view, the application should never trust an edj file. So if I can break your consistent behaviour by just touching the edc file, then their is a bug in the application from my point of view. In your example. I just need to set visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break your app. So you are just lucky that no one touched your edc file. Ok, but don't you trust the edj file will have a swallow with name X ? It's easy to break an application changing the edj if you want to do so. From my point of view, an edj is a black box that can do anything. There is no such thing like when I unswallow all my theme will always resize the object and make them properly visible. That's why I see this as an undefined behaviour. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Bruno Dilly Senior Developer ProFUSION embedded systems http://profusion.mobi -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
2012/1/9 Bruno Dilly bdi...@profusion.mobi: Ok, but don't you trust the edj file will have a swallow with name X ? It's easy to break an application changing the edj if you want to do so. The application has to define a certain policy for the theme, designers can't just go crazy and do whatever crap comes out from their minds without adhering to those specified rules, so it's perfectly possible for a program to expect an unswallowed object to be in a somewhat known state. That said, I don't care whether the change goes in or not, I still believe the undefined behavior is not a reason not to document the change. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Mon, Jan 9, 2012 at 5:07 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. OK, my concept of application is code and theme. Anyway, a simple case is to add an rectangle to a swallow in a layout. I've attached a quick example. As you can see, no luck required. After 3 seconds the rectangle is unswallowed and displayed at 0,0. Ok, I see the difference. From my point of view, the application should never trust an edj file. So if I can break your consistent behaviour by just touching the edc file, then their is a bug in the application from my point of view. In your example. I just need to set visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break your app. So you are just lucky that no one touched your edc file. Ok, but don't you trust the edj file will have a swallow with name X ? It's easy to break an application changing the edj if you want to do so. You know that edje_object_part_swallow return an EINA_BOOL, do you ? -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] easy_e17.sh + git
Hi, could you please drop me a patch file so that i can merge this into the original script? Would be nice to have a single script instead of a lot of forkes. ;) Kind regards, Brian 'morlenxus' Miculcy On 01/06/2012 07:18 PM, Jérémy Zurcher wrote: Hello, I've seen a few words about e moving once to git, I just wanted to let you know that I've got a git ready easy_e17.sh script that I use on a daily basis. It also takes care of ewebkit. You can find it there : http://cgit.asynk.ch/cgi-bin/cgit/bin/tree/easy_e17.sh It point's to a hourly update git clone of mine. regards Jérémy -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Mon, Jan 9, 2012 at 2:13 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 5:07 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. OK, my concept of application is code and theme. Anyway, a simple case is to add an rectangle to a swallow in a layout. I've attached a quick example. As you can see, no luck required. After 3 seconds the rectangle is unswallowed and displayed at 0,0. Ok, I see the difference. From my point of view, the application should never trust an edj file. So if I can break your consistent behaviour by just touching the edc file, then their is a bug in the application from my point of view. In your example. I just need to set visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break your app. So you are just lucky that no one touched your edc file. Ok, but don't you trust the edj file will have a swallow with name X ? It's easy to break an application changing the edj if you want to do so. You know that edje_object_part_swallow return an EINA_BOOL, do you ? I do, you can print something in your terminal and quit the application. What doesn't mean it is not working as intended. Anyway, there are signals that should be emitted to code and you don't emit that on your theme. So it will break your application and you can't detect. Going further, you can make every part invisible, and you application will be completely useless. So, yeah, I believe you need to trust your edj someway, and they need to be considered part of the application. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Bruno Dilly Senior Developer ProFUSION embedded systems http://profusion.mobi -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] About places, e17 release and the e file manager
First of all Hi to everyone!! I have been lot of time far from the e world, mainly because I have changed 2 different jobs (and the house were I live) in the last year. But I'm more 'stable' now, so it's time to make some sane E related works :) In the last week I spent my nights reading the past messages from the devel list and the first feel I got was: wow, we are going to release e17...after a few seconds the second thought: arghh. We need to fix all that broken stuff around !!! About fixing the Places module: places is broken, arghh! don't ask me why, I don't know, it was working well the last time I installed it (like 1 year ago). I must fix it! and a good'old rewrite seems necessary. I'm going to rewrite it as part of the fm module, so I can share all the code about the volumes management with e, seems to me the more natural way to go. but now comes the problems... About the way efm mount: The way e17 handle the unmount of device is quite odd to me (you know, e unmount the volume as soon as you close the last efm-win that use that volume) and this behavior is quite in conflict with the places module, as is it's main purpose is to provide the unmount/eject icon. Are we sure we want e17 behave in this way? I don't think so, an exaple: * I want to watch a film on my usb stick: I put the key in, double click on the icon that appear on the desktop, double click on the film I like to start mplayer. Then I close the fm win to watch my video.what happen? does e unmount the key while I'm watching? if no, when the key will be unmounted? I really think e should behave as all the other OSs does, mount on first use and unmount/eject on request. About e17 device backends: We now have 3 different engine to manage volumes in e and none seems 100% functional: * the HAL backand seems broken as the places module. * the EEZE backend needs libmount (hard to get) and seems also not 100% functional. * the UDEV backand is unselectable in the configure step, at least if you have hal installed. really the configure switch seems broken to me, I have hal, udev and eeze installed, I should be able to choose witch one to use...it doesn't work, e always force me to use the hal one. Also the options seems wrong, we have: --enable-device-hal and --enable-device-udev but not the one for eeze :/ then we have: --enable-mount-hal --enable-mount-udisks --enable-mount-eeze I understand the eeze one but the others? disable mount in hal? in udisk? ...why? About eeze: I like it (at least the api seems good, never used directly) but I have some issue in mind: in the api I saw some functions and datatypes that has the 'udev' word in...shouldn't eeze abstract the user from the underground? And what about volumes mounted in other different ways? I WANT my iphone to show up in E as it is in nautilus, I think it is mounted using fuse(or gvfs?)...what about that?? I don't want this email to become too huge so I leave for a future mail other details and the discussion about the efm itself...that need lts of discussion and code for a proper e17 release. bye DaveMDS -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
Bruno, while your example is valid, it's not how it will usually be. Most of the time people will use animations, which are bound to keyboard/mouse events. In my code for example, I can scroll a list using the arrow keys, but if you press the arrow twice, then two signals are sent, thus canceling the first animation.so the state of the swalowed object is undefined as it all depends on the elapsed milliseconds between the first and second press of the arrow key. I consider this a race condition. I also doubt that anyone is using edje, then suddenly unswallows the object and decides to keep it there and start to handle it manually in C.If he wanted to handle it in C directly, it wouldn't have been a swallowed part in the first place. i don't disagree though that this might chance the behavior of some really rare apps. As for trusting the .edj, you'd trust it to have specific groups/parts and handle/send specific signals, but you can't trust it to have an object as a specific position. The whole purpose of the edj is to allow the UI dev to decide where to position everything, what sizes to give them and what states. On Mon, Jan 9, 2012 at 11:19 AM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 2:13 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 5:07 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. OK, my concept of application is code and theme. Anyway, a simple case is to add an rectangle to a swallow in a layout. I've attached a quick example. As you can see, no luck required. After 3 seconds the rectangle is unswallowed and displayed at 0,0. Ok, I see the difference. From my point of view, the application should never trust an edj file. So if I can break your consistent behaviour by just touching the edc file, then their is a bug in the application from my point of view. In your example. I just need to set visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break your app. So you are just lucky that no one touched your edc file. Ok, but don't you trust the edj file will have a swallow with name X ? It's easy to break an application changing the edj if you want to do so. You know that edje_object_part_swallow return an EINA_BOOL, do you ? I do, you can print something in your terminal and quit the application. What doesn't mean it is not working as intended. Anyway, there are signals that should be emitted to code and you don't emit that on your theme. So it will break your application and you can't detect. Going further, you can make every part invisible, and you application will be completely useless. So, yeah, I believe you need to trust your edj someway, and they need to be considered part of the application. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try
Re: [E-devel] About places, e17 release and the e file manager
On Mon, 9 Jan 2012 22:43:12 +0100 Davide Andreoli d...@gurumeditation.it wrote: First of all Hi to everyone!! I have been lot of time far from the e world, mainly because I have changed 2 different jobs (and the house were I live) in the last year. But I'm more 'stable' now, so it's time to make some sane E related works :) In the last week I spent my nights reading the past messages from the devel list and the first feel I got was: wow, we are going to release e17...after a few seconds the second thought: arghh. We need to fix all that broken stuff around !!! e17 release is still a VERY long way out. elementary appears to be the current focus, and there's decades of development required for it to be usable which must be compressed into a couple months. given the comparatively tiny number of people who commit regularly to e17, it's unlikely that there will be even an alpha until late Q2-Q3. if that. About fixing the Places module: places is broken, arghh! don't ask me why, I don't know, it was working well the last time I installed it (like 1 year ago). I must fix it! and a good'old rewrite seems necessary. most likely a result of my rough attempt to add udisks support to it a long time ago. whoops. iirc though, I implemented it properly and just never tested it. you'll likely find that there are only a few small things breaking which prevent it from working. I'm going to rewrite it as part of the fm module, so I can share all the code about the volumes management with e, seems to me the more natural way to go. but now comes the problems... About the way efm mount: The way e17 handle the unmount of device is quite odd to me (you know, e unmount the volume as soon as you close the last efm-win that use that volume) and this behavior is quite in conflict with the places module, as is it's main purpose is to provide the unmount/eject icon. Are we sure we want e17 behave in this way? I don't think so, an exaple: * I want to watch a film on my usb stick: I put the key in, double click on the icon that appear on the desktop, double click on the film I like to start mplayer. Then I close the fm win to watch my video.what happen? does e unmount the key while I'm watching? if no, when the key will be unmounted? I really think e should behave as all the other OSs does, mount on first use and unmount/eject on request. I have no comment on this as I have never, and will never, allow a window manager to manage my devices. About e17 device backends: We now have 3 different engine to manage volumes in e and none seems 100% functional: * the HAL backand seems broken as the places module. this one works, but nobody has HAL anymore * the EEZE backend needs libmount (hard to get) and seems also not 100% functional. I stopped working on this because it's impossible to get good testers. once libmount-based mount implementations get more widespread (and it's a redhat technology, so this is a guarantee), I will improve it to work better. currently, however, it does work for me. * the UDEV backand is unselectable in the configure step, at least if you have hal installed. UDEV is is only an option when 1) you have eeze, 2) you do not build HAL. The reason for #2 is simple: udev is synchronous and HAL is not. that said, I have been using this backend since I wrote it without issues in either configure or runtime. also udev is not a mount backend, nor does it have any mounting capabilities. really the configure switch seems broken to me, I have hal, udev and eeze installed, I should be able to choose witch one to use...it eeze is udev. doesn't work, e always force me to use the hal one. Also the options seems wrong, we have: --enable-device-hal and --enable-device-udev but not the one for eeze :/ then we have: --enable-mount-hal --enable-mount-udisks --enable-mount-eeze I understand the eeze one but the others? disable mount in hal? in udisk? ...why? udisks is something entirely different; it aims to provide the same functionality as HAL did for drives (dbus management and detection). I provided configure switches so it would be easy to disable unwanted backends. About eeze: I like it (at least the api seems good, never used directly) but I have some issue in mind: in the api I saw some functions and datatypes that has the 'udev' word in...shouldn't eeze abstract the user from the underground? no, the eeze_udev namespace is linux-only. this is made obvious by the _udev namespace, and the intent is to provide faster alternatives for the infantile linux-specific (at the time of writing eeze 1.0) technologies udisks and upower. if support for other operating systems is added (READ: NOT BY ME), this can easily be abstracted to an eeze_device namespace as I have already planned. And what about volumes mounted in other different ways? I WANT my iphone to show up in E as it is in nautilus, I think it is mounted using fuse(or gvfs?)...what about that?? gvfs
Re: [E-devel] easy_e17.sh + git
On Tuesday, January 10, 2012 12:14:34 AM UTC+8, Brian 'morlenxus' Miculcy wrote: Hi, could you please drop me a patch file so that i can merge this into the original script? Would be nice to have a single script instead of a lot of forkes. ;) Kind regards, Brian 'morlenxus' Miculcy Hi, Not sure if you were addressing to me or Jeremy. The version I have is quite different in the way it builds e and efl. There is one FIXME in the script which I haven't figured out yet. The whole set of changes can be found here: https://github.com/ppurka/easy_e17 If you want any of the changes (see the README file for the list of changes) sent to you as a patch file then let me know. I am pretty sure you won't like all the changes ;) -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch] elm_gen{list, grid} - adding item_class management functions
On Fri, Jan 6, 2012 at 11:34 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Fri, Jan 6, 2012 at 6:48 AM, Hyoyoung Chang hyoyo...@gmail.com wrote:
Dear all
This patch introduces four new apis about elm_gen{list, grid} item
class managements.
itc_add function makes a new item_class for the given widget.
And itc_del function remove the item_class from the widget.
Most of elm_gen{list, grid} users declare itc(item_class) as a global
variable.
Because itc should be lived at elm_gen{list,grid} item's life cycle.
It's inconvenient for users. Even some users pass itc.
itc_add makes a new itc. if exact one exists in the given widget, it
return the previous made itc.
itc_del remove a itc if its reference count reaches at zero.
Thanks.
EAPI Elm_Genlist_Item_Class *
elm_genlist_itc_add(Evas_Object *obj, const char *item_style,
Elm_Genlist_Item_Text_Get_Cb text_cb,
Elm_Genlist_Item_Content_Get_Cb content_cb,
Elm_Genlist_Item_State_Get_Cb state_cb,
Elm_Genlist_Item_Del_Cb del_cb);
EAPI void
elm_genlist_itc_del(Evas_Object *obj, Elm_Genlist_Item_Class *itc);
EAPI Elm_Gengrid_Item_Class *
elm_gengrid_itc_add(Evas_Object *obj, const char *item_style,
Elm_Gengrid_Item_Text_Get_Cb text_cb,
Elm_Gengrid_Item_Content_Get_Cb content_cb,
Elm_Gengrid_Item_State_Get_Cb state_cb,
Elm_Gengrid_Item_Del_Cb del_cb);
EAPI void
elm_gengrid_itc_del(Evas_Object *obj, Elm_Gengrid_Item_Class *itc);
I dislike it, one can easily do this kind of stuff using item_del_cb().
And really, majority of developers should NEVER use this, the global
static-const is the correct way to go, making sure memory is live,
unchanged, no mallocs, etc.
Thanks for your reply. This patch has an assumption that application
can alloc itc memory dynamically.
If itc-dynamic-allocation is not recommended, do you have to use
global variable for itc?
For a huge app that uses many c sources, we can't force them to use
global static :(
Daniel Juyung Seo (SeoZ)
Who may use this is bindings, like Python, JavaScript and that's it.
They have better ways to manage it.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Patch][Notify] Remove Unnecessary Code
Dear All, Hello~ I have attached a patch for removing unnecessary code in the elm_notify. There is no swallow area for the parent In the notify.edc also. Even if the removed line is necessary, then it will cause an improper result. So it should be removed definitely and absolutely! Please review this and give any feedbacks. Thank you. Sincerely, Shinwoo Kim. Index: src/lib/elm_notify.c === --- src/lib/elm_notify.c (revision 67011) +++ src/lib/elm_notify.c (working copy) @@ -568,7 +568,6 @@ elm_notify_parent_set(Evas_Object *obj, Evas_Objec _parent_del, obj); evas_object_event_callback_add(parent, EVAS_CALLBACK_HIDE, _parent_hide, obj); -edje_object_part_swallow(wd-notify, elm.swallow.parent, parent); _sizing_eval(obj); } _calc(obj); -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
