Re: [E-devel] cleanup of the autotools stuff
>>> I've cleaned a bit the autotools stuff: >>> >>> * use correct way to remove the check of g++ and g77 from libtool >>> * use correct way to deal with PACKAGE_DATA_DIR and PACKAGE_LIB_DIR >>> * use AC_HELP_STRING when missing >>> * formatting >>> >>> later, I plan to add win32 support (compilation without x11. I don't think >>> i'll add any win32 specific graphic stuff) >>> >>> if the formatting is good enough, i can commit. >> >> I've forgotten something: do you want I add the same libtool versioning >> than other efl (based on the version in configure.in) ? Anyway, it would be >> better to put it in configure.in, and not in src/lib/Makefile.am >> > Patch looks fine to me. > I think it makes sense to move the lib version stuff to configure.in. in cvs Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] patch for embryo functions
Hi, I was creating a theme with edje and missed some functions to
resize a dragable part with embryo inside the .edc
Looking at the code of edje I verified that these functions were
already implemented, so all that would be needed to do was to create a
binding for embryo that pointed to these functions.
I made a patch that create these bindings, and called these functions
set_drag_size and get_drag_size. It works fine for me.
[]'s
Rafael Antognolli
Index: data/include/edje.inc
===
RCS file: /var/cvs/e17/libs/edje/data/include/edje.inc,v
retrieving revision 1.24
diff -u -r1.24 edje.inc
--- data/include/edje.inc 11 Apr 2008 23:36:35 - 1.24
+++ data/include/edje.inc 13 May 2008 21:59:26 -
@@ -90,6 +90,8 @@
native get_drag_dir (part_id);
native get_drag (part_id, &Float:dx, &Float:dy);
native set_drag (part_id, Float:dx, Float:dy);
+native get_drag_size(part_id, &Float:dx, &Float:dy);
+native set_drag_size(part_id, Float:dx, Float:dy);
native get_drag_step(part_id, &Float:dx, &Float:dy);
native set_drag_step(part_id, Float:dx, Float:dy);
native get_drag_page(part_id, &Float:dx, &Float:dy);
Index: src/lib/edje_embryo.c
===
RCS file: /var/cvs/e17/libs/edje/src/lib/edje_embryo.c,v
retrieving revision 1.60
diff -u -r1.60 edje_embryo.c
--- src/lib/edje_embryo.c 11 Apr 2008 23:36:35 - 1.60
+++ src/lib/edje_embryo.c 13 May 2008 21:59:26 -
@@ -80,6 +80,8 @@
* Direction:get_drag_dir(part_id)
* get_drag(part_id, &Float:dx, &Float:&dy)
* set_drag(part_id, Float:dx, Float:dy)
+ * get_drag_size(part_id, &Float:dx, &Float:&dy)
+ * set_drag_size(part_id, Float:dx, Float:dy)
* set_text(part_id, str[])
* get_text(part_id, dst[], maxlen)
* get_min_size(w, h)
@@ -998,6 +1000,46 @@
return(0);
}
+/* get_drag_size(part_id, &Float:dx, &Float:dy) */
+static Embryo_Cell
+_edje_embryo_fn_get_drag_size(Embryo_Program *ep, Embryo_Cell *params)
+{
+ Edje *ed;
+ int part_id = 0;
+ Edje_Real_Part *rp;
+ double dx = 0.0, dy = 0.0;
+
+ CHKPARAM(3);
+ ed = embryo_program_data_get(ep);
+ part_id = params[1];
+ if (part_id < 0) return 0;
+ rp = ed->table_parts[part_id % ed->table_parts_size];
+ edje_object_part_drag_size_get(ed->obj, rp->part->name, &dx, &dy);
+ SETFLOAT(dx, params[2]);
+ SETFLOAT(dy, params[3]);
+
+ return 0;
+}
+
+/* set_drag_size(part_id, Float:dx, Float:dy) */
+static Embryo_Cell
+_edje_embryo_fn_set_drag_size(Embryo_Program *ep, Embryo_Cell *params)
+{
+ Edje *ed;
+ int part_id = 0;
+ Edje_Real_Part *rp;
+
+ CHKPARAM(3);
+ ed = embryo_program_data_get(ep);
+ part_id = params[1];
+ if (part_id < 0) return 0;
+ rp = ed->table_parts[part_id % ed->table_parts_size];
+ edje_object_part_drag_size_set(ed->obj, rp->part->name,
+ (double)EMBRYO_CELL_TO_FLOAT(params[2]),
+ (double)EMBRYO_CELL_TO_FLOAT(params[3]));
+ return(0);
+}
+
/* set_text(part_id, str[]) */
static Embryo_Cell
_edje_embryo_fn_set_text(Embryo_Program *ep, Embryo_Cell *params)
@@ -2216,6 +2258,8 @@
embryo_program_native_call_add(ep, "get_drag_dir",
_edje_embryo_fn_get_drag_dir);
embryo_program_native_call_add(ep, "get_drag", _edje_embryo_fn_get_drag);
embryo_program_native_call_add(ep, "set_drag", _edje_embryo_fn_set_drag);
+ embryo_program_native_call_add(ep, "get_drag_size",
_edje_embryo_fn_get_drag_size);
+ embryo_program_native_call_add(ep, "set_drag_size",
_edje_embryo_fn_set_drag_size);
embryo_program_native_call_add(ep, "set_text", _edje_embryo_fn_set_text);
embryo_program_native_call_add(ep, "get_text", _edje_embryo_fn_get_text);
embryo_program_native_call_add(ep, "get_min_size",
_edje_embryo_fn_get_min_size);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas.h included too early in evas_common_soft16.h
Hey, thanks for trying that port :) > I am currently following Vincent Torri's instructions to compile the > EFL under Win32/mingw, and I encountered an internal compiler error > from gcc while compiling Evas, specifically the common_16 engine. > After a few minutes diving into the preprocessed code, I found out > that commenting out the line 4 (#include "Evas.h") in the file > evas/src/lib/include/evas_common_soft16.h (added by raster 4 weeks > ago) seems to correct that. In fact, Evas.h is already included, but > later, in evas_common.h. > > Can someone correct it please? Yes, I'm doing the change right now. Anyway, the headers in evas must be reorganized. It's a real mess. regards Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Line + width support.
On Tue, May 13, 2008 at 5:20 PM, Diego Bitencourt Contezini <[EMAIL PROTECTED]> wrote: > Hello all. > Working with evas+Lines in python, is fast. But if you need a line with more > then one pixel of width, it gets very slow (in dispositives like N800), > because object Line dont have width support, so its needen to use Rectangles > to make it works. > > I made a modification to support width in Lines object. It is composed by 3 > patchs. > *First*, in evas/lib/*, it changes internal call to engine line drawer, > inserting more one argument to the same function. It is a callback, so, no > modification is needen in any engine module that dosnt support Lines with > more then 1 pixel (they will just draw with only 1 pixel). Has added new > functions to deal with width, without breaking any compatibility of other > functions. > *Second*, in evas/engine/software16 to add support to width. > *Third,* in python-evas binding, to add support to use the modifications > made in evas. > > If anyone get any bug or suggest any modification to patch, im a listener. Hi, I have no time to look at this now, but when we required lines with > 1px width we used polygons with great success. Actually, I guess it's difficult to see single lines being used separated, often we use connected lines, in this case it would be great to be able to choose the caps/join to be used... using polygons users can implement this. Of course creating the polygons are bit hard, so having this ready in Evas would help a lot :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Line + width support.
Hello all.
Working with evas+Lines in python, is fast. But if you need a line with more
then one pixel of width, it gets very slow (in dispositives like N800),
because object Line dont have width support, so its needen to use Rectangles
to make it works.
I made a modification to support width in Lines object. It is composed by 3
patchs.
*First*, in evas/lib/*, it changes internal call to engine line drawer,
inserting more one argument to the same function. It is a callback, so, no
modification is needen in any engine module that dosnt support Lines with
more then 1 pixel (they will just draw with only 1 pixel). Has added new
functions to deal with width, without breaking any compatibility of other
functions.
*Second*, in evas/engine/software16 to add support to width.
*Third,* in python-evas binding, to add support to use the modifications
made in evas.
If anyone get any bug or suggest any modification to patch, im a listener.
Thanks all
Diego Bitencourt Contezini
diff -Naur evas-0.9.9.042/src/modules/engines/software_16/evas_engine.c evas-linha/src/modules/engines/software_16/evas_engine.c
--- evas-0.9.9.042/src/modules/engines/software_16/evas_engine.c 2008-05-07 17:22:35.0 -0300
+++ evas-linha/src/modules/engines/software_16/evas_engine.c 2008-05-13 14:35:03.0 -0300
@@ -149,9 +149,9 @@
}
static void
-eng_line_draw(void *data, void *context, void *surface, int x1, int y1, int x2, int y2)
+eng_line_draw(void *data, void *context, void *surface, int x1, int y1, int x2, int y2, int width)
{
- soft16_line_draw(surface, context, x1, y1, x2, y2);
+ soft16_line_draw(surface, context, x1, y1, x2, y2, width);
}
static void *
diff -Naur evas-0.9.9.042/src/modules/engines/software_16/evas_soft16.h evas-linha/src/modules/engines/software_16/evas_soft16.h
--- evas-0.9.9.042/src/modules/engines/software_16/evas_soft16.h 2008-05-07 17:22:35.0 -0300
+++ evas-linha/src/modules/engines/software_16/evas_soft16.h 2008-05-13 14:35:03.0 -0300
@@ -139,7 +139,7 @@
* Line (evas_soft16_line.c)
*/
void
-soft16_line_draw(Soft16_Image *dst, RGBA_Draw_Context *dc, int x0, int y0, int x1, int y1);
+soft16_line_draw(Soft16_Image *dst, RGBA_Draw_Context *dc, int x0, int y0, int x1, int y1, int width);
/**
diff -Naur evas-0.9.9.042/src/modules/engines/software_16/evas_soft16_line.c evas-linha/src/modules/engines/software_16/evas_soft16_line.c
--- evas-0.9.9.042/src/modules/engines/software_16/evas_soft16_line.c 2008-05-07 17:22:35.0 -0300
+++ evas-linha/src/modules/engines/software_16/evas_soft16_line.c 2008-05-13 14:35:03.0 -0300
@@ -71,8 +71,8 @@
dst_itr = dst->pixels + (dst->stride * y) + x;
alpha = A_VAL(&dc->col.col) >> 3;
rgb565 = RGB_565_FROM_COMPONENTS(R_VAL(&dc->col.col),
-G_VAL(&dc->col.col),
-B_VAL(&dc->col.col));
+ G_VAL(&dc->col.col),
+ B_VAL(&dc->col.col));
if (alpha == 31)
_soft16_pt_fill_solid_solid(dst_itr, rgb565);
@@ -87,52 +87,62 @@
}
static void
-_soft16_line_horiz(Soft16_Image *dst, RGBA_Draw_Context *dc, int x0, int x1, int y)
+_soft16_line_horiz(Soft16_Image *dst, RGBA_Draw_Context *dc, int x0, int x1, int y, int width)
{
DATA16 rgb565, *dst_itr;
DATA8 alpha;
+ int dx;
int w;
-
- if (!_is_y_inside_clip(y, dc->clip))
- return;
-
if (x0 < dc->clip.x)
x0 = dc->clip.x;
if (x1 >= dc->clip.x + dc->clip.w)
x1 = dc->clip.x + dc->clip.w - 1;
- w = x1 - x0;
- if (w < 1)
+ dx = x1 - x0;
+ if (dx < 1)
return;
- dst_itr = dst->pixels + (dst->stride * y) + x0;
- alpha = A_VAL(&dc->col.col) >> 3;
- rgb565 = RGB_565_FROM_COMPONENTS(R_VAL(&dc->col.col),
-G_VAL(&dc->col.col),
-B_VAL(&dc->col.col));
+ dx++;
- if (alpha == 31)
- _soft16_scanline_fill_solid_solid(dst_itr, w, rgb565);
- else if (alpha > 0)
+ for(w = 0; w < width; w++)
{
- DATA32 rgb565_unpack;
+ int ay;
+ if(w%2) // not pair
+ ay = y+(w/2) + 1;
+ else // pair
+ ay = y-(w/2);
+ if (!_is_y_inside_clip(ay, dc->clip))
+ continue;
+
+ dst_itr = dst->pixels + (dst->stride * ay) + x0;
+ alpha = A_VAL(&dc->col.col) >> 3;
+ rgb565 = RGB_565_FROM_COMPONENTS(R_VAL(&dc->col.col),
+ G_VAL(&dc->col.col),
+ B_VAL(&dc->col.col));
+
+ if (alpha == 31)
+ _soft16_scanline_fill_solid_solid(dst_itr, dx, rgb565);
+ else if (alpha > 0)
+ {
+ DATA32 rgb565_unpack;
- rgb565_unpack = RGB_565_UNPACK(rgb565);
- alpha++;
- _soft16_scanline_fill_transp_solid(dst_itr, w, rgb565_unpack, alpha);
+ rgb565_unpack = RGB_565_UNPACK(rgb565);
+ alpha++;
+ _soft16_scanline_fill_transp_solid(dst_itr, dx, rgb565_unpack, alpha);
+ }
}
+ return;
}
static void
-_soft16_line_vert(Soft16_Image *dst, RGBA_Draw_Context *dc, int x, int y0, int y1)
+_soft16_line_vert(Soft16_Image *dst, RGBA_Draw_Context *dc, int x, int y0, int y1, int width)
{
DATA16 rgb565, *dst_itr;
DATA8 alpha;
- int h;
-
- if (!_is_x_inside_clip(x, dc->clip))
[E-devel] Evas.h included too early in evas_common_soft16.h
Hi everyone, I am currently following Vincent Torri's instructions to compile the EFL under Win32/mingw, and I encountered an internal compiler error from gcc while compiling Evas, specifically the common_16 engine. After a few minutes diving into the preprocessed code, I found out that commenting out the line 4 (#include "Evas.h") in the file evas/src/lib/include/evas_common_soft16.h (added by raster 4 weeks ago) seems to correct that. In fact, Evas.h is already included, but later, in evas_common.h. Can someone correct it please? Thanks a lot, and congrats for these amazing libs and great work. regards, Lionel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [eet] unit tests
Hey, I've quickly written a useless unit test for eet. Here is the archive: http://www.maths.univ-evry.fr/pages_perso/vtorri/files/eet-1.0.0.tar.bz2 you must have: * the 'check' library: http://check.sourceforge.net/ * lcov for the coverage report: http://ltp.sourceforge.net/coverage/lcov.php. At least the 1.6 version. For compiling the unit tests * ./configure --enable-tests && make && make check For also having the coverage report: * ./configure --enable-tests --enable-coverage && make && make coverage then go to the eet/coverage/ subdir and open index.html. I don't know if it's the correct location to put the coverage report. Maybe in src/tests is better. The tests are located in src/tests. Right now, they are included when doing a make dist, but i can easily remove them from the dist. Ideas, remarks, etc.. are welcome. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] PATH thinkfinger
Jhoanir Torres wrote: > Hi; > > please let me know if anybody have some code or think about integrate > thinkfinger project to e17. Im thinking to do something if it not exist. > Thinkfinger is deprecated, you should look at fprint: http://reactivated.net/fprint/wiki/Main_Page Sebastian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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-05-13 07:10:06 -0700
Build log for Enlightenment DR 0.17 on 2008-05-13 07:10: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 evolve http://download.enlightenment.org/tests/logs/evolve.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, 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, 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] PATH thinkfinger
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jhoanir Torres wrote: | please let me know if anybody have some code or think about integrate | thinkfinger project to e17. Im thinking to do something if it not exist. I'd love to see that realized! I offer myself for testing purposes ;) ciao, - -- | .-. |Alexander Griesser -- <[EMAIL PROTECTED]> | .''`. | | /v\ \ http://www.tuxx-home.at/ / : :' : | | /( )\ | GPG-KeyID: 0xA2949B5A | `. `' | | ^^ ^^ `-'`- | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKYZe66HVD6KUm1oRAtyuAJ9Mq3DHn7d+PGmnP3zWWcyEmHFCPQCfcjKT DZVZNLvV1dNaV5FO2HYVP/0= =vH1u -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] PATH thinkfinger
Hi; please let me know if anybody have some code or think about integrate thinkfinger project to e17. Im thinking to do something if it not exist. -- Jhoanir Torres [ S14ck ] "take it, use it... human knowledge belongs to the world " - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
