[E-devel] Proposed evas gfx api changes and additions - part I.
As the subject states, let me make a (relatively) short summary of some
proposed changes and additions to the evas gfx api -- and I'll deal with only
gradients and a possible vgfx-objs api, leaving transforms (mostly) and filters
for later.
First, changes to the current gradient api. This would replace the current
api with the following one:
(1) For creating gradients:
**
Evas_Object *evas_object_gradient_[type]_add(e);
where the types are: linear and radial (and possibly later also angular,
rectangular, triangular, sinusoidal, ...)
(2) For setting gradient geometries (of a given type):
*
void evas_object_gradient_[type]_fill_set(obj, [geometry desc]);
Where the [geom desc] is:
(a) for linear grads,
void evas_object_gradient_linear_fill_set(obj, Evas_Coord x0, Evas_Coord y0,
Evas_Coord x1, Evas_Coord y1);
(b) for radial grads,
void evas_object_gradient_radial_fill_set(obj, Evas_Coord cx0, Evas_Coord cy0,
float rx, float ry);
And we'd leave any other types for later as desired.
(3) For setting the gradient geometry's spread (or repeat, or extend) mode:
void evas_object_gradient_fill_spread_set(obj, int tile_mode);
(4) For modifying the gradient geometry via a transform:
***
void evas_object_gradient_fill_transform_set(obj, Evas_Transform *t);
where an 'Evas_Transform' is defined as:
struct Evas_Transform
{
float mxx, mxy, mxz;
float myx, myy, myz;
float mzx, mzy, mzz;
};
ie. a 3x3 tmatrix which can be used to define a projective transformation
or an affine one by ignoring the mzx,mzy,mzz components. Only affine ones
supported for grad geometries (though the obj itself may support proj
ones).
(5) For clearing/defining the gradient obj's spectrum:
***
void evas_object_gradient_clear(obj);
ie. remove any stops or data or whatnot from the gradient.
void evas_object_gradient_color_np_stop_insert(obj, r, g, b, a, float pos);
ie. insert a NON_PREMUL color at the given pos (clamped to be in [0,1])
And *possibly* also similar premul such, as exist currently:
void evas_object_gradient_color_stop_insert(obj, r, g, b, a, float pos);
void evas_object_gradient_alpha_stop_insert(obj, a, float pos);
void evas_object_gradient_color_data_set(obj, *data, len, has_alpha);
void evas_object_gradient_alpha_data_set(obj, *data, len);
That's it for basic gradient support (one could add more types, and one
could add some funcs to query/modify stops if desired).
The reasons for proposing these changes?
To allow for direct support of gradients with various possible engine backends
(eg. xrender, cairo, OpenVG, ... others).
To have an api which is 'fitted' to what most all vgfx specs/lib-apis support
with gradients.
To more easily enable and represent various uses of gradients (including vgfx
related ones like texturing of geometric figures with them).
This then leads to a proposed api for vgfx-objects in evas -- and recall,
by
vgfx-objects, we mean objs that can be filled and/or stroked (eg. lines,
rects,
polys, paths, ... maybe text) with a color or a texture (aka a paint or a
pattern).
Which I'll leave for a 'part II' of this thread...
Click to become a designer and quit your boring job.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l7L9Yyvs84mUKIe3vCf8GDVRRcB4RUunBX6sKcN8nFwKJPi/
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] reorganisation of configure output
Hey, i've always found the output of ecore's configure a bit messy. Here is a patch that tries to organise that a bit. There are 3 parts: Core, Graphic systems and Ecore Evas. Here is an output on Windows: Core: Ecore_Job: yes Ecore_Txt: yes Ecore_File...: yes Inotify: no Poll...: yes CURL...: yes Ecore_Desktop: no Ecore_Con: no Ecore_Ipc: no Ecore_Config.: no Ecore_IMF: yes Ecore_IMF_Evas...: yes Graphic systems: Ecore_X..: no Ecore_Win32..: yes Ecore_SDL: no Ecore_FB.: no Ecore_DFB: no Ecore_WinCE..: no Ecore Evas: Ecore_Evas...: yes Software Memory Buffer.: yes Software X11...: no XRender X11: no OpenGL X11.: no Software DirectDraw: yes Direct3D...: yes OpenGL Glew: yes Software SDL...: no DirectFB...: no Software Framebuffer...: no Software 16bit X11.: no Software 16bit DirectDraw..: yes Software 16bit WinCE...: no The options are hidden if the module is not available. Note that I can replace Ecore_X Ecore_Win32 Ecore_SDL Ecore_FB Ecore_DFB Ecore_WinCE by X Window Windows (gdi) SDL Framebuffer DirectFB Windows CE (gdi) if you think it's better (I can do the same for the Core part). If nobody objects, I'll commit the patch in some days. VincentIndex: configure.in === RCS file: /cvs/e/e17/libs/ecore/configure.in,v retrieving revision 1.265 diff -u -r1.265 configure.in --- configure.in17 Jul 2008 06:06:34 - 1.265 +++ configure.in17 Jul 2008 08:47:28 - @@ -845,43 +845,92 @@ echo echo Optional Modules: echo +echo Core: +echo echo Ecore_Job: $have_ecore_job -echo Ecore_Con: $have_ecore_con (OpenSSL: $have_openssl) (CURL: $have_curl) -echo Ecore_Ipc: $have_ecore_ipc (OpenSSL: $have_openssl) -echo Ecore_Config.: $have_ecore_config echo Ecore_Txt: $have_ecore_txt +echo Ecore_File...: $have_ecore_file +if test x$have_ecore_file = xyes ; then + echo Inotify: $have_inotify + echo Poll...: $have_poll + echo CURL...: $have_curl +fi +echo Ecore_Desktop: $have_ecore_desktop +echo Ecore_Con: $have_ecore_con +if test x$have_ecore_con = xyes ; then + echo OpenSSL: $have_openssl + echo CURL...: $have_curl +fi +echo Ecore_Ipc: $have_ecore_ipc +if test x$have_ecore_con = xyes ; then + echo OpenSSL: $have_openssl +fi +echo Ecore_Config.: $have_ecore_config +echo Ecore_IMF: $have_ecore_imf +echo Ecore_IMF_Evas...: $have_ecore_imf_evas + +echo +echo Graphic systems: +echo -echo Ecore_Evas...: $have_ecore_evas if test x$have_ecore_x_xcb = xyes ; then - echo Ecore_X (XCB backend): $have_ecore_x_xcb (Xprint: $have_ecore_x_xcb_xprint) (Xinerama: $have_ecore_x_xcb_xinerama) (Xrandr: $have_ecore_x_xcb_randr) (Xscreensaver: $have_ecore_x_xcb_screensaver) (Xshape: $have_ecore_x_xcb_shape) (Xsync: $have_ecore_x_xcb_sync) (Xrender: $have_ecore_x_xcb_render) (Xfixes: $have_ecore_x_xcb_xfixes) (Xcomposite: $have_ecore_x_xcb_composite) (Xdamage: $have_ecore_x_xcb_damage) (Xdpms: $have_ecore_x_xcb_dpms) (Xtest $have_ecore_x_xcb_xtest) + echo Ecore_X (XCB backend): $have_ecore_x_xcb + echo Xprint.: $have_ecore_x_xcb_xprint + echo Xinerama...: $have_ecore_x_xcb_xinerama + echo Xrandr.: $have_ecore_x_xcb_randr + echo Xscreensaver...: $have_ecore_x_xcb_screensaver + echo Xshape.: $have_ecore_x_xcb_shape + echo Xsync..: $have_ecore_x_xcb_sync + echo Xrender: $have_ecore_x_xcb_render + echo Xcomposite.: $have_ecore_x_xcb_composite + echo Xfixes.: $have_ecore_x_xcb_xfixes + echo Xdamage: $have_ecore_x_xcb_damage + echo Xdpms..: $have_ecore_x_xcb_dpms + echo Xtest..: $have_ecore_x_xcb_xtest else - echo Ecore_X (Xlib backend)...: $have_ecore_x (Xcursor: $use_Xcursor) (Xprint: $use_xprint) (Xinerama: $use_xinerama) (Xrandr: $use_xrandr)
[E-devel] Proposed evas gfx api changes and additions - part I!.
Ok, now for a proposed api for evas vgfx objects -- a very simple one, but general enough to allow for the overwhelming majority of vgfx uses (and certainly ones for most 'real-time' use in evas). Again, by evas vgfx objects we mean evas objects that can be filled and/or stroked (eg. lines, rects, polys, paths, ... maybe text) with a color or a texture (aka: a paint or pattern). (1) For filling of supported objs: *** void evas_object_fill_color_set(obj, r,g,b,a); void evas_object_fill_texture_set(obj, Evas_Object *texture_obj); Where 'texture_obj' is restricted to be an image or a gradient obj (no others for now). Also, no fill-texturing of an image or grad obj. I think I briefly explained the interpretation of this before - ie. image or grad objs are really equivalent to a simple rectangle being flled with image or grad texture, where the 'texture' part is given by fill geometries and such.. So, when these objects are set as texture_objs of vector objs, all general object properties are ignored and only the 'fill' properties are used - except that the fill geometries' coord system is now taken rel to the textured obj's origin. (2) For stroking of supported objs: void evas_object_stroke_color_set(obj, r,g,b,a); void evas_object_stroke_texture_set(obj, Evas_Object *texture_obj); These are similar to above for the fill. void evas_object_stroke_weight_set(obj, Evas_Coord weight); (3) For determining whether to fill and/or stroke supported objects: *** void evas_object_draw_mode_set(obj, int draw_mode); Where 'draw_mode' is one of: EVAS_DRAW_STROKE, EVAS_DRAW_FILL, or EVAS_DRAW_STROKE_FILL. More api funcs can be added to obtain fuller vgfx support, but this is actually a good chunk of it (just need a bit on cap styles, join styles, and dashed-stroking, but not much else really that would be reasonable here). It doesn't cover the other proposed desire to change the polygon object 'points' api, nor does it cover a possible path object api (which I would suggest be given in the same manner as that proposed for polys, ie. *set* a path description which consists of some means of defining the path). Nor does it cover possibly setting (affine) transforms on the vertex- geometries that might define such vgfx objects.. leave that for later. (4) Extensions to the current rectangle obj api: *** void evas_object_rectangle_corner_radius_set(obj, float r); void evas_object_rectangle_corner_style_set(obj, int corner_style); Where 'corner_style' can be one of EVAS_CORNER_ROUND or EVAS_CORNER_BEVEL. void evas_object_rectangle_corners_set(obj, Evas_Bool tl, Evas_Bool tr, Evas_Bool bl, Evas_Bool br); The corners to apply the style to, or leave squared off (default). Rectangles can be filled and/or stroked, but the stroking will be defined to increase inward - though one could also add an api for deciding whether to have it centered on the rect, or increase inward or outward. Click to consolidate your debt in minutes, stop late or over-limit fees, pay less. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m2bkjb956ElxjIhRRrqe1OG1E6WbsoH6rpBrTpg9m4hiCTW/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
On Fri, Jul 11, 2008 at 11:11 AM, Peter Wehrfritz [EMAIL PROTECTED] wrote: Cedric BAIL schrieb: Putting eina now into cvs doesn't help anyone at the moment. There are two ways we can go: 1. First we start with a little lib, where we put step by step code into it, we agree with that it belongs into the common lib. That's what I tried with edt. 2. We first discuss how the common lib needs to be en bloc and in detail and then change eina to match the result of the discussion. And move it then into cvs. It looks like most people here prefer the second way. I will say we have a third option. Put a common lib in cvs now. Then slowly move stuff around to the new system. With current work from caro with Evas_Data.h we should be able to provide a set of macro that will help do the move quickly. This move should not impact performance at all (and looking at eina current code, I don't see how it could change something regarding that). With focus on evas this is right, but you would be going to make facts without discussing them before. I think we didn't understand together. When I say slowly move stuff around, it include changing and improving Eina to fit our needs also. Eina is not a finished library, but an ongoing development. It's just a good starting point imho to get stuff done faster. For example in eina the evas_hash implementation is called eina_hash. I think it'd be better to reserve this name for the ecore_hash implementation, because it is much more general. For the evas_hash implementation another name like eina_strhash would imho then be better. I agree with your rename it make sense. But I still think that doing this review with the code in CVS would be faster. Instead of just discussing we will have code progressing at the same time and every one following development on the CVS will be able to participate in this review and get stuff done faster. And I'm still not convinced if there is a general need to have a fixed-point implementation in the base data types lib, just to mention my concerns. Maybe someone else, with more authority then me :), will join this discussion. In my opinion, it's easier to remove code than to write :-) I don't see any direct user for this feature right now, but with the planned evolution of evas, their could be some. So I d I'm sure turran took care in doing eina, but you'll get more agreement if things are discussed before. The idea of moving eina inside the efl librarry CVS repository is to take care of it as a group and use this as a fast starter. It's a lot of work to move data type out of Evas, preserving speed, feature and stability. So that what we win by using eina as a starting point. Then as a group we can change and update this stuff according to our need. I am sure Turran will agree on this. -- Cedric BAIL - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [GSOC] Eyelight, a presentation tools
hello, Some information are available on my wiki: http://watchwolf.fr/wiki/doku.php?id=efl_presentation_tools Currently Eyelight can be use to do a presentation but the project is not done, the next big start is to improve the viewer with some effects :) -- Regards. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-07-17 07:11:06 -0700
Build log for Enlightenment DR 0.17 on 2008-07-17 07:11:06 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, skel, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/eet cedric
Hey, in eet_data.c, in _eet_free_hash() : long int ptr = (long int)(data); hash ^= ptr 32; and the others long int is 32 bits long on 32 bits computers. Is it possible that a problem can arise, here ? Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/eet cedric
Vincent Torri schrieb: Hey, in eet_data.c, in _eet_free_hash() : long int ptr = (long int)(data); hash ^= ptr 32; and the others long int is 32 bits long on 32 bits computers. Is it possible that a problem can arise, here ? Right, that produces a warning. I fixed that (hopefully right) and some other compile warnings in eet_data.c. There are still some warnings in eet_lib.c and eet_iamge.c eet_lib.c: In function 'eet_internal_read2': eet_lib.c:856: warning: comparison between signed and unsigned eet_lib.c: In function 'eet_internal_read1': eet_lib.c:949: warning: comparison between signed and unsigned eet_lib.c: In function 'eet_internal_read': eet_lib.c:1083: warning: comparison between signed and unsigned eet_lib.c: In function 'eet_open': eet_lib.c:1182: warning: comparison between signed and unsigned eet_image.c: In function 'eet_data_image_jpeg_rgb_decode': eet_image.c:234: warning: comparison between signed and unsigned eet_image.c:238: warning: comparison between signed and unsigned eet_image.c:241: warning: comparison between signed and unsigned eet_image.c:241: warning: comparison between signed and unsigned eet_image.c:245: warning: comparison between signed and unsigned eet_image.c:249: warning: comparison between signed and unsigned eet_image.c:270: warning: comparison between signed and unsigned eet_image.c:274: warning: comparison between signed and unsigned eet_image.c:277: warning: comparison between signed and unsigned eet_image.c:277: warning: comparison between signed and unsigned eet_image.c:281: warning: comparison between signed and unsigned eet_image.c:285: warning: comparison between signed and unsigned eet_image.c: In function 'eet_data_image_jpeg_alpha_decode': eet_image.c:376: warning: comparison between signed and unsigned eet_image.c:380: warning: comparison between signed and unsigned eet_image.c:383: warning: comparison between signed and unsigned eet_image.c:383: warning: comparison between signed and unsigned eet_image.c:387: warning: comparison between signed and unsigned eet_image.c:391: warning: comparison between signed and unsigned - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Esmart container clipping
Thanks for the help guys, here's my second version, that deals with
show/hide and applies clip_elements_set() to all elements.
On Wed, Jul 16, 2008 at 11:53 PM, Peter Wehrfritz [EMAIL PROTECTED]
wrote:
Sevcsik András schrieb:
I attached a patch for esmart that adds
esmart_container_clip_elements_set()
and esmart_container_clip_elements_get(). It's my first patch, so if
you've
got any suggestion about anything, don't hesitate to tell :)
Somethings need to be changed. As Hisham has said, you have of course to
unclip or to clip the children that are already in the container, if you
change the clipping state. Second, you have deal with the hide and show
callbacks. If the container is hidden its elements shouldn't be visible
either. There to ways to do this. 1. You hide the elements, too. 2. you clip
them on the hidden clipper.
I think the second way is better because the user can still hide and show
the element if he wants to, without esmart_container changing this state.
Peter
--
Minden jót,
Sevcsik András
Index: src/lib/esmart_container/Esmart_Container.h
===
RCS file: /var/cvs/e/e17/libs/esmart/src/lib/esmart_container/Esmart_Container.h,v
retrieving revision 1.11
diff -u -r1.11 Esmart_Container.h
--- src/lib/esmart_container/Esmart_Container.h 12 Jul 2008 06:40:36 - 1.11
+++ src/lib/esmart_container/Esmart_Container.h 17 Jul 2008 20:48:11 -
@@ -147,6 +147,18 @@
EAPI int esmart_container_layout_plugin_set(Evas_Object *container, const char *name);
+/*! \brief Set that container should clip elements
+ * @param container Object
+ * @param val Boolean value: 1 to clip elements (default), 0 to not
+ */
+EAPI void esmart_container_clip_elements_set(Evas_Object *container,
+ unsigned char val);
+
+/*! \brief Checks that container clips elements or not
+ * @param container Object
+ * @return Boolean value: 1 if clip elements, 0 if not
+ */
+EAPI unsigned char esmart_container_clip_elements_get(Evas_Object *container);
#ifdef __cplusplus
}
Index: src/lib/esmart_container/esmart_container.c
===
RCS file: /var/cvs/e/e17/libs/esmart/src/lib/esmart_container/esmart_container.c,v
retrieving revision 1.16
diff -u -r1.16 esmart_container.c
--- src/lib/esmart_container/esmart_container.c 12 Jul 2008 06:40:36 - 1.16
+++ src/lib/esmart_container/esmart_container.c 17 Jul 2008 20:48:11 -
@@ -419,6 +419,47 @@
return length;
}
+EAPI void
+esmart_container_clip_elements_set(Evas_Object *container, unsigned char val)
+{
+ Container *cont;
+ Evas_List *l;
+
+ cont = _container_fetch(container);
+ if (val)
+ evas_object_show(cont-clipper);
+ else
+ evas_object_hide(cont-clipper);
+ cont-clip_elements = val;
+
+ if (val)
+ { /* Clip all elements */
+ for (l = cont-elements; l; l = l-next)
+ {
+ Container_Element *el = l-data;
+
+ evas_object_clip_set(el-obj, cont-clipper);
+ }
+ }
+ else
+ { /* Unclip all elements */
+ for (l = cont-elements; l; l = l-next)
+ {
+ Container_Element *el = l-data;
+
+ evas_object_clip_unset(el-obj);
+ }
+ }
+}
+
+EAPI unsigned char
+esmart_container_clip_elements_get(Evas_Object *container)
+{
+ Container *cont;
+
+ cont = _container_fetch(container);
+ return cont-clip_elements;
+}
/ internal functions ***/
@@ -435,7 +476,7 @@
el-obj = obj;
evas_object_data_set(obj, Container_Element, el);
evas_object_show(obj);
-
+
evas_object_geometry_get(obj, NULL, NULL, w, h);
el-orig_w = w;
el-orig_h = h;
@@ -444,9 +485,12 @@
evas_object_repeat_events_set(el-grabber, 1);
evas_object_color_set(el-grabber, 0, 0, 0, 0);
evas_object_show(el-grabber);
-
+
el-container = cont;
- evas_object_clip_set(el-obj, cont-clipper);
+
+ if (cont-clip_elements)
+ evas_object_clip_set(el-obj, cont-clipper);
+
evas_object_clip_set(el-grabber, cont-clipper);
/*
evas_object_layer_set(el-obj, evas_object_layer_get(cont-obj));
@@ -456,6 +500,7 @@
evas_object_stack_above(el-obj, cont-obj);
*/
evas_object_smart_member_add(el-obj, cont-obj);
+
evas_object_smart_member_add(el-grabber, cont-obj);
evas_object_event_callback_add(el-grabber, EVAS_CALLBACK_MOUSE_DOWN, _cb_element_down, el);
Index: src/lib/esmart_container/esmart_container_private.h
===
RCS file: /var/cvs/e/e17/libs/esmart/src/lib/esmart_container/esmart_container_private.h,v
retrieving revision 1.7
diff -u -r1.7 esmart_container_private.h
--- src/lib/esmart_container/esmart_container_private.h 12 Jul 2008 06:40:36 - 1.7
+++ src/lib/esmart_container/esmart_container_private.h 17 Jul 2008 20:48:11 -
@@ -48,6 +48,9 @@
void *data_order_change;
unsigned char changed : 1;
+
+
