[E-devel] [Patch] [Elementary] [Entry] Correct disabled mode
Dear All, In elementary, the disabled entry works incorrectly. We still can cut/paste from/to it. I'd like to send a patch to fix it. Please review this patch. Thanks Regards, Thiep Ha elm_entry_disabled.diff Description: Binary data -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
* Cedric BAIL cedric.b...@free.fr [2012-10-31 11:38:52 +0900]: On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL cedric.b...@free.fr wrote: Hello, On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez christophe.du...@intel.com wrote: There are lots of concerns from EFL developers (me included) on how the development of WebKit-EFL is being done. The API of webkit2 even not being fully supported by EFL, as contrary to webkit1. There's only 1 developer that seemed to care and started to send patches to elm-web, so webkit2 can be fully supported. No surprise there was feedback asking for clarifications and why a simpler api couldn't be used. Now you come and say WebKit1 is being deprecated. -1000 here, until the day webkit2 gets fully supported in EFL and you start to interact more with EFL devs. The proposed date for dropping WK1 EFL from upstream is 8 month away. I think this gives a reasonable amount of time for people currently relying on WK1 EFL to port their code to WK2 EFL. If anything, this should motivate people to make sure all the components work with WK2 EFL. 8 months is clearly to short from now is clearly to short. 8 months after WK2 EFL API is stabilized and released (I mean by that, that any API/ABI break of it will be forbidden). Then you can consider dropping WK1 EFL. Announcing that you will drop WK1 EFL when WK2 EFL is not even stable, is not a proper move in my opinion. Upstream EFL does use WK1 EFL in the 1.7.x branch, that will be used by E17 release later this year. This means that all distribution that do want to package EFL with a stable release for E17 will be depending on WK1 EFL. You can stop development, only do bugfixes, but removing it is clearly not a smart move here. About interaction with EFL developers, I don't think we have any problem answering questions related to WebKit EFL (via this mailing list or the IRC channel) or fix bugs filed upstream against WebKit EFL. Yes, you have. I am aware of the move to WK2 EFL since less than 3 weeks. If some nice Samsung guy didn't try to help EFL upstream to move away of WK1 EFL we wouldn't be even have any proper information and code here. At this point, the WebKit EFL people need to get more involved with EFL. It's not a matter of answering question, it's about using the same tool and do that efficiently ! If we don't share infromation more effectively, this kind of thread is going to repeat. I strongly encourage every developer of WK EFL to join e-devel mailing list and ping people there when there is important subject to bring in (like new dependencies, feature request, ...). I am now subscribed to this mailing list and will try to keep reading it, but that's not enough. WK EFL team should get more engadged with EFL developer in general. As a related note: although Ecore provides curl/http, WebKit still uses the crap alien that is libsoup. Why not start the Webkit + EFL adding the missing bits to Ecore_Con and then using it natively in WebKit, instead of forcing glib-mainloop integration for nothing? I can't but only agree and wish for that to happen soon. +1 here. Then it would be just cairo on the gtk land, I guess. -- Cedric BAIL ___ webkit-efl mailing list webkit-...@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-efl -- Gustavo Lima Chaves Computer Engineer @ ProFUSION Embedded Systems -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On Wed, Oct 31, 2012 at 12:07 PM, Vincent Torri vincent.to...@gmail.comwrote: On Wed, Oct 31, 2012 at 1:03 PM, Gustavo Lima Chaves gl...@profusion.mobi wrote: * Cedric BAIL cedric.b...@free.fr [2012-10-31 11:38:52 +0900]: On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL cedric.b...@free.fr wrote: Hello, On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez christophe.du...@intel.com wrote: There are lots of concerns from EFL developers (me included) on how the development of WebKit-EFL is being done. The API of webkit2 even not being fully supported by EFL, as contrary to webkit1. There's only 1 developer that seemed to care and started to send patches to elm-web, so webkit2 can be fully supported. No surprise there was feedback asking for clarifications and why a simpler api couldn't be used. Now you come and say WebKit1 is being deprecated. -1000 here, until the day webkit2 gets fully supported in EFL and you start to interact more with EFL devs. The proposed date for dropping WK1 EFL from upstream is 8 month away. I think this gives a reasonable amount of time for people currently relying on WK1 EFL to port their code to WK2 EFL. If anything, this should motivate people to make sure all the components work with WK2 EFL. 8 months is clearly to short from now is clearly to short. 8 months after WK2 EFL API is stabilized and released (I mean by that, that any API/ABI break of it will be forbidden). Then you can consider dropping WK1 EFL. Announcing that you will drop WK1 EFL when WK2 EFL is not even stable, is not a proper move in my opinion. Upstream EFL does use WK1 EFL in the 1.7.x branch, that will be used by E17 release later this year. This means that all distribution that do want to package EFL with a stable release for E17 will be depending on WK1 EFL. You can stop development, only do bugfixes, but removing it is clearly not a smart move here. About interaction with EFL developers, I don't think we have any problem answering questions related to WebKit EFL (via this mailing list or the IRC channel) or fix bugs filed upstream against WebKit EFL. Yes, you have. I am aware of the move to WK2 EFL since less than 3 weeks. If some nice Samsung guy didn't try to help EFL upstream to move away of WK1 EFL we wouldn't be even have any proper information and code here. At this point, the WebKit EFL people need to get more involved with EFL. It's not a matter of answering question, it's about using the same tool and do that efficiently ! If we don't share infromation more effectively, this kind of thread is going to repeat. I strongly encourage every developer of WK EFL to join e-devel mailing list and ping people there when there is important subject to bring in (like new dependencies, feature request, ...). I am now subscribed to this mailing list and will try to keep reading it, but that's not enough. WK EFL team should get more engadged with EFL developer in general. As a related note: although Ecore provides curl/http, WebKit still uses the crap alien that is libsoup. Why not start the Webkit + EFL adding the missing bits to Ecore_Con and then using it natively in WebKit, instead of forcing glib-mainloop integration for nothing? I can't but only agree and wish for that to happen soon. +1 here. Then it would be just cairo on the gtk land, I guess. what about using enesim instead of cairo ? The rendering of esvg is faster than with librsvg, and is much more powerful, and it is not optimized, so plenty of room for improvements Vincent I cast two votes in favor of this. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] more evas gl compile warnings
these are from the 1.7 branch of evas, but they should still probably be fixed since this is supposed to be our stable branch which e17 is based on evas_gl_texture.c: In function '_tex_2d': evas_gl_texture.c:119:8: warning: the address of 'glGetTexLevelParameteriv' will always evaluate as 'true' [-Waddress] make[5]: Entering directory `branches/evas-1.7/src/modules/engines/gl_x11' CC module_la-evas_engine.lo CC module_la-evas_x_main.lo evas_engine.c: In function '_gl_ext_sym_init': evas_engine.c:542:115: warning: assignment from incompatible pointer type [enabled by default] evas_engine.c:542:273: warning: assignment from incompatible pointer type [enabled by default] evas_engine.c: In function 'eng_image_map_clean': evas_engine.c:2826:27: warning: unused parameter 'data' [-Wunused-parameter] evas_engine.c:2826:43: warning: unused parameter 'm' [-Wunused-parameter] evas_engine.c: In function '_print_gl_surface_info': evas_engine.c:3057:137: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] evas_engine.c:3057:284: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] evas_engine.c:3061:148: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] evas_engine.c:3061:319: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] evas_engine.c: In function 'evgl_glGetShaderPrecisionFormat': evas_engine.c:4402:40: warning: unused parameter 'shadertype' [-Wunused-parameter] evas_engine.c:4402:59: warning: unused parameter 'precisiontype' [-Wunused-parameter] -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] more evas gl compile warnings
Thank you for reporting it. Will fix them soon... or sung plz? -Regards, Hermet- -Original Message- From: Michael Blumenkrantzlt;michael.blumenkra...@gmail.comgt; To: Enlightenment developer listlt;enlightenment-devel@lists.sourceforge.netgt;; Cc: Sent: 2012-10-31 (수) 22:31:15 Subject: [E-devel] more evas gl compile warnings these are from the 1.7 branch of evas, but they should still probably be fixed since this is supposed to be our stable branch which e17 is based on evas_gl_texture.c: In function '_tex_2d': evas_gl_texture.c:119:8: warning: the address of 'glGetTexLevelParameteriv' will always evaluate as 'true' [-Waddress] make[5]: Entering directory `branches/evas-1.7/src/modules/engines/gl_x11' CC module_la-evas_engine.lo CC module_la-evas_x_main.lo evas_engine.c: In function '_gl_ext_sym_init': evas_engine.c:542:115: warning: assignment from incompatible pointer type [enabled by default] evas_engine.c:542:273: warning: assignment from incompatible pointer type [enabled by default] evas_engine.c: In function 'eng_image_map_clean': evas_engine.c:2826:27: warning: unused parameter 'data' [-Wunused-parameter] evas_engine.c:2826:43: warning: unused parameter 'm' [-Wunused-parameter] evas_engine.c: In function '_print_gl_surface_info': evas_engine.c:3057:137: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] evas_engine.c:3057:284: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] evas_engine.c:3061:148: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] evas_engine.c:3061:319: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] evas_engine.c: In function 'evgl_glGetShaderPrecisionFormat': evas_engine.c:4402:40: warning: unused parameter 'shadertype' [-Wunused-parameter] evas_engine.c:4402:59: warning: unused parameter 'precisiontype' [-Wunused-parameter] -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On Wed, Oct 31, 2012 at 12:23 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL cedric.b...@free.fr wrote: Hello, On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez christophe.du...@intel.com wrote: There are lots of concerns from EFL developers (me included) on how the development of WebKit-EFL is being done. The API of webkit2 even not being fully supported by EFL, as contrary to webkit1. There's only 1 developer that seemed to care and started to send patches to elm-web, so webkit2 can be fully supported. No surprise there was feedback asking for clarifications and why a simpler api couldn't be used. Now you come and say WebKit1 is being deprecated. -1000 here, until the day webkit2 gets fully supported in EFL and you start to interact more with EFL devs. The proposed date for dropping WK1 EFL from upstream is 8 month away. I think this gives a reasonable amount of time for people currently relying on WK1 EFL to port their code to WK2 EFL. If anything, this should motivate people to make sure all the components work with WK2 EFL. 8 months is clearly to short from now is clearly to short. 8 months after WK2 EFL API is stabilized and released (I mean by that, that any API/ABI break of it will be forbidden). Then you can consider dropping WK1 EFL. Announcing that you will drop WK1 EFL when WK2 EFL is not even stable, is not a proper move in my opinion. Upstream EFL does use WK1 EFL in the 1.7.x branch, that will be used by E17 release later this year. This means that all distribution that do want to package EFL with a stable release for E17 will be depending on WK1 EFL. You can stop development, only do bugfixes, but removing it is clearly not a smart move here. About interaction with EFL developers, I don't think we have any problem answering questions related to WebKit EFL (via this mailing list or the IRC channel) or fix bugs filed upstream against WebKit EFL. Yes, you have. I am aware of the move to WK2 EFL since less than 3 weeks. If some nice Samsung guy didn't try to help EFL upstream to move away of WK1 EFL we wouldn't be even have any proper information and code here. At this point, the WebKit EFL people need to get more involved with EFL. It's not a matter of answering question, it's about using the same tool and do that efficiently ! If we don't share infromation more effectively, this kind of thread is going to repeat. I strongly encourage every developer of WK EFL to join e-devel mailing list and ping people there when there is important subject to bring in (like new dependencies, feature request, ...). I am now subscribed to this mailing list and will try to keep reading it, but that's not enough. WK EFL team should get more engadged with EFL developer in general. As a related note: although Ecore provides curl/http, WebKit still uses the crap alien that is libsoup. Why not start the Webkit + EFL adding the missing bits to Ecore_Con and then using it natively in WebKit, instead of forcing glib-mainloop integration for nothing? +1. Lucas De Marchi -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On Wed, Oct 31, 2012 at 2:07 PM, Vincent Torri vincent.to...@gmail.com wrote: On Wed, Oct 31, 2012 at 1:03 PM, Gustavo Lima Chaves gl...@profusion.mobi wrote: * Cedric BAIL cedric.b...@free.fr [2012-10-31 11:38:52 +0900]: On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL cedric.b...@free.fr wrote: Hello, On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez christophe.du...@intel.com wrote: There are lots of concerns from EFL developers (me included) on how the development of WebKit-EFL is being done. The API of webkit2 even not being fully supported by EFL, as contrary to webkit1. There's only 1 developer that seemed to care and started to send patches to elm-web, so webkit2 can be fully supported. No surprise there was feedback asking for clarifications and why a simpler api couldn't be used. Now you come and say WebKit1 is being deprecated. -1000 here, until the day webkit2 gets fully supported in EFL and you start to interact more with EFL devs. The proposed date for dropping WK1 EFL from upstream is 8 month away. I think this gives a reasonable amount of time for people currently relying on WK1 EFL to port their code to WK2 EFL. If anything, this should motivate people to make sure all the components work with WK2 EFL. 8 months is clearly to short from now is clearly to short. 8 months after WK2 EFL API is stabilized and released (I mean by that, that any API/ABI break of it will be forbidden). Then you can consider dropping WK1 EFL. Announcing that you will drop WK1 EFL when WK2 EFL is not even stable, is not a proper move in my opinion. Upstream EFL does use WK1 EFL in the 1.7.x branch, that will be used by E17 release later this year. This means that all distribution that do want to package EFL with a stable release for E17 will be depending on WK1 EFL. You can stop development, only do bugfixes, but removing it is clearly not a smart move here. About interaction with EFL developers, I don't think we have any problem answering questions related to WebKit EFL (via this mailing list or the IRC channel) or fix bugs filed upstream against WebKit EFL. Yes, you have. I am aware of the move to WK2 EFL since less than 3 weeks. If some nice Samsung guy didn't try to help EFL upstream to move away of WK1 EFL we wouldn't be even have any proper information and code here. At this point, the WebKit EFL people need to get more involved with EFL. It's not a matter of answering question, it's about using the same tool and do that efficiently ! If we don't share infromation more effectively, this kind of thread is going to repeat. I strongly encourage every developer of WK EFL to join e-devel mailing list and ping people there when there is important subject to bring in (like new dependencies, feature request, ...). I am now subscribed to this mailing list and will try to keep reading it, but that's not enough. WK EFL team should get more engadged with EFL developer in general. As a related note: although Ecore provides curl/http, WebKit still uses the crap alien that is libsoup. Why not start the Webkit + EFL adding the missing bits to Ecore_Con and then using it natively in WebKit, instead of forcing glib-mainloop integration for nothing? I can't but only agree and wish for that to happen soon. +1 here. Then it would be just cairo on the gtk land, I guess. what about using enesim instead of cairo ? The rendering of esvg is faster than with librsvg, and is much more powerful, and it is not optimized, so plenty of room for improvements Dominik has a good point about the same subject: http://lists.webkit.org/pipermail/webkit-efl/2012-October/000417.html -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [e] e_sys_main.c
Hi,
with recent changes fromCedric Bail in e/src/bin/e_sys_main.c,
OpenBSD needs sys/wait.h. Also removed useless code.
thanks
--- e_sys_main.c Wed Oct 31 16:09:29 2012
+++ e_sys_main.c Wed Oct 31 16:07:00 2012
@@ -6,6 +6,7 @@
#include string.h
#include sys/types.h
#include sys/stat.h
+#include sys/wait.h
#include pwd.h
#include grp.h
#include fnmatch.h
@@ -50,7 +51,7 @@
const char *act;
#endif
gid_t gid, gl[65536], egid;
- int pid;
+ int pid = 0;
for (i = 1; i argc; i++)
{
@@ -72,20 +73,21 @@
test = 1;
action = argv[2];
}
- else if ((argc == 4) (!strcmp(argv[1], gdb)))
- {
- char *end = NULL;
+ else if (!strcmp(argv[1], gdb))
+ {
+if (argc != 4) exit(1);
+char *end = NULL;
- action = argv[1];
- pid = strtoul(argv[2], end, 10);
- if (end == NULL || *end != '\0')
- {
- printf(Invalid pid for '%s'.\n, argv[3]);
- exit(0);
- }
+action = argv[1];
+pid = strtoul(argv[2], end, 10);
+if (end == NULL || *end != '\0')
+ {
+ printf(Invalid pid for '%s'.\n, argv[3]);
+ exit(0);
+ }
- output = argv[3];
- }
+output = argv[3];
+ }
#ifdef HAVE_EEZE_MOUNT
else
{
@@ -109,8 +111,8 @@
{
exit(1);
}
- fprintf(stderr, action %s %i\n, action, argc);
if (!action) exit(1);
+ fprintf(stderr, action %s %i\n, action, argc);
uid = getuid();
gid = getgid();
@@ -152,13 +154,12 @@
exit(20);
}
- if (!(strcmp(argv[1], gdb)))
+ if (!strcmp(action, gdb))
{
Eina_Prefix *pfx = NULL;
char buffer[4096];
char *tmp;
char *enlightenment_gdb;
-char *batch;
int fd;
int r;
@@ -171,12 +172,11 @@
snprintf(buffer, 4096,
set logging file %s\nset logging on\nbacktrace full\n,
output);
-batch = strdup(buffer);
tmp = strdup(/tmp/e-gdb-XX);
fd = mkstemp(tmp);
if (fd 0) exit(-1);
-write(fd, batch, strlen(batch));
+write(fd, buffer, strlen(buffer));
close(fd);
snprintf(buffer, 4096,
@@ -192,7 +192,6 @@
unlink(tmp);
free(enlightenment_gdb);
-free(batch);
free(tmp);
exit(WEXITSTATUS(r));
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e] e_sys_main.c
in. for future diffs please separate out all formatting changes into separate patches. On Wed, Oct 31, 2012 at 3:14 PM, rustyBSD rusty...@gmx.fr wrote: Hi, with recent changes fromCedric Bail in e/src/bin/e_sys_main.c, OpenBSD needs sys/wait.h. Also removed useless code. thanks -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] ArchLinux updated binary packages?
Hi all, Recently moved to Arch and I'm looking for daily/weekly updated EFL packages. Seems lots of developers use Arch, but instead build/install manually, no packaging -- what a shame. Given that Arch provides ABS/AUR, I'm pretty sure we could have this and share... same effort, but more organized and easier to use by our users. Compared to Gentoo, seems that the change is that for AUR we'd need a script that would walk every package in order and do: for p in efl evas ...; do (cd $p makepkg pacman $p.tar.xz) || exit 1 done after that we can scp the .tar.xz to our server and other people can use it. Could we do this from e3/e4/e5? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ArchLinux updated binary packages?
On 31/10/12 17:46, Gustavo Sverzut Barbieri wrote: Hi all, Recently moved to Arch and I'm looking for daily/weekly updated EFL packages. Seems lots of developers use Arch, but instead build/install manually, no packaging -- what a shame. Given that Arch provides ABS/AUR, I'm pretty sure we could have this and share... same effort, but more organized and easier to use by our users. Compared to Gentoo, seems that the change is that for AUR we'd need a script that would walk every package in order and do: for p in efl evas ...; do (cd $p makepkg pacman $p.tar.xz) || exit 1 done after that we can scp the .tar.xz to our server and other people can use it. Could we do this from e3/e4/e5? There's Arch e17: https://dev.archlinux.org/~ronald/e17.html I build my own checkouts so I have modified PKGBUILDs and a small script that does exactly what you've described... I don't think there's a real reason to maintain our own builds as the packages are mostly up to date. Also, soon enough we'll have a release and we'd want to discourage people from building off svn anyway. Furthermore, soon enough we'll have just one tree which will make this even easier. -- Tom. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
2012/11/1 Gustavo Sverzut Barbieri barbi...@profusion.mobi On Wed, Oct 31, 2012 at 12:57 PM, Thiago Marcos P. Santos tmpsan...@gmail.com wrote: On Wed, Oct 31, 2012 at 2:07 PM, Vincent Torri vincent.to...@gmail.com wrote: On Wed, Oct 31, 2012 at 1:03 PM, Gustavo Lima Chaves gl...@profusion.mobi wrote: * Cedric BAIL cedric.b...@free.fr [2012-10-31 11:38:52 +0900]: On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL cedric.b...@free.fr wrote: Hello, On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez christophe.du...@intel.com wrote: There are lots of concerns from EFL developers (me included) on how the development of WebKit-EFL is being done. The API of webkit2 even not being fully supported by EFL, as contrary to webkit1. There's only 1 developer that seemed to care and started to send patches to elm-web, so webkit2 can be fully supported. No surprise there was feedback asking for clarifications and why a simpler api couldn't be used. Now you come and say WebKit1 is being deprecated. -1000 here, until the day webkit2 gets fully supported in EFL and you start to interact more with EFL devs. The proposed date for dropping WK1 EFL from upstream is 8 month away. I think this gives a reasonable amount of time for people currently relying on WK1 EFL to port their code to WK2 EFL. If anything, this should motivate people to make sure all the components work with WK2 EFL. 8 months is clearly to short from now is clearly to short. 8 months after WK2 EFL API is stabilized and released (I mean by that, that any API/ABI break of it will be forbidden). Then you can consider dropping WK1 EFL. Announcing that you will drop WK1 EFL when WK2 EFL is not even stable, is not a proper move in my opinion. Upstream EFL does use WK1 EFL in the 1.7.x branch, that will be used by E17 release later this year. This means that all distribution that do want to package EFL with a stable release for E17 will be depending on WK1 EFL. You can stop development, only do bugfixes, but removing it is clearly not a smart move here. About interaction with EFL developers, I don't think we have any problem answering questions related to WebKit EFL (via this mailing list or the IRC channel) or fix bugs filed upstream against WebKit EFL. Yes, you have. I am aware of the move to WK2 EFL since less than 3 weeks. If some nice Samsung guy didn't try to help EFL upstream to move away of WK1 EFL we wouldn't be even have any proper information and code here. At this point, the WebKit EFL people need to get more involved with EFL. It's not a matter of answering question, it's about using the same tool and do that efficiently ! If we don't share infromation more effectively, this kind of thread is going to repeat. I strongly encourage every developer of WK EFL to join e-devel mailing list and ping people there when there is important subject to bring in (like new dependencies, feature request, ...). I am now subscribed to this mailing list and will try to keep reading it, but that's not enough. WK EFL team should get more engadged with EFL developer in general. As a related note: although Ecore provides curl/http, WebKit still uses the crap alien that is libsoup. Why not start the Webkit + EFL adding the missing bits to Ecore_Con and then using it natively in WebKit, instead of forcing glib-mainloop integration for nothing? I can't but only agree and wish for that to happen soon. +1 here. Then it would be just cairo on the gtk land, I guess. what about using enesim instead of cairo ? The rendering of esvg is faster than with librsvg, and is much more powerful, and it is not optimized, so plenty of room for improvements Dominik has a good point about the same subject: http://lists.webkit.org/pipermail/webkit-efl/2012-October/000417.html The problem is that libsoup depends on shitloads of other libraries just to provide HTTP. If curl is not enough, pretty sure can turn into a task to write a proper implementation that fulfill WebKit needs and that is integrated into EFL. +1 in the viewpoint that libcurl is way to go. But it may not be easy work. When we decide to use libsoup as default network backend, libcurl backend has many missing features such as cookie, cache, and so on. IIRC, they are still missing features. Anyway, I will raise this item when we discuss future plan of WebKit/tizen. As for the graphics, I don't mind Cairo or Skia. If someone (Jorge) provides a GraphicsContext using his library would be nice as well. If we have good alternatives, could you let me know? Our graphics team may check the performance for next plan. BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On Wed, Oct 31, 2012 at 5:22 PM, ryuan Choi ryuan.c...@gmail.com wrote: 2012/11/1 Gustavo Sverzut Barbieri barbi...@profusion.mobi On Wed, Oct 31, 2012 at 12:57 PM, Thiago Marcos P. Santos tmpsan...@gmail.com wrote: On Wed, Oct 31, 2012 at 2:07 PM, Vincent Torri vincent.to...@gmail.com wrote: On Wed, Oct 31, 2012 at 1:03 PM, Gustavo Lima Chaves gl...@profusion.mobi wrote: * Cedric BAIL cedric.b...@free.fr [2012-10-31 11:38:52 +0900]: On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL cedric.b...@free.fr wrote: Hello, On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez christophe.du...@intel.com wrote: There are lots of concerns from EFL developers (me included) on how the development of WebKit-EFL is being done. The API of webkit2 even not being fully supported by EFL, as contrary to webkit1. There's only 1 developer that seemed to care and started to send patches to elm-web, so webkit2 can be fully supported. No surprise there was feedback asking for clarifications and why a simpler api couldn't be used. Now you come and say WebKit1 is being deprecated. -1000 here, until the day webkit2 gets fully supported in EFL and you start to interact more with EFL devs. The proposed date for dropping WK1 EFL from upstream is 8 month away. I think this gives a reasonable amount of time for people currently relying on WK1 EFL to port their code to WK2 EFL. If anything, this should motivate people to make sure all the components work with WK2 EFL. 8 months is clearly to short from now is clearly to short. 8 months after WK2 EFL API is stabilized and released (I mean by that, that any API/ABI break of it will be forbidden). Then you can consider dropping WK1 EFL. Announcing that you will drop WK1 EFL when WK2 EFL is not even stable, is not a proper move in my opinion. Upstream EFL does use WK1 EFL in the 1.7.x branch, that will be used by E17 release later this year. This means that all distribution that do want to package EFL with a stable release for E17 will be depending on WK1 EFL. You can stop development, only do bugfixes, but removing it is clearly not a smart move here. About interaction with EFL developers, I don't think we have any problem answering questions related to WebKit EFL (via this mailing list or the IRC channel) or fix bugs filed upstream against WebKit EFL. Yes, you have. I am aware of the move to WK2 EFL since less than 3 weeks. If some nice Samsung guy didn't try to help EFL upstream to move away of WK1 EFL we wouldn't be even have any proper information and code here. At this point, the WebKit EFL people need to get more involved with EFL. It's not a matter of answering question, it's about using the same tool and do that efficiently ! If we don't share infromation more effectively, this kind of thread is going to repeat. I strongly encourage every developer of WK EFL to join e-devel mailing list and ping people there when there is important subject to bring in (like new dependencies, feature request, ...). I am now subscribed to this mailing list and will try to keep reading it, but that's not enough. WK EFL team should get more engadged with EFL developer in general. As a related note: although Ecore provides curl/http, WebKit still uses the crap alien that is libsoup. Why not start the Webkit + EFL adding the missing bits to Ecore_Con and then using it natively in WebKit, instead of forcing glib-mainloop integration for nothing? I can't but only agree and wish for that to happen soon. +1 here. Then it would be just cairo on the gtk land, I guess. what about using enesim instead of cairo ? The rendering of esvg is faster than with librsvg, and is much more powerful, and it is not optimized, so plenty of room for improvements Dominik has a good point about the same subject: http://lists.webkit.org/pipermail/webkit-efl/2012-October/000417.html The problem is that libsoup depends on shitloads of other libraries just to provide HTTP. If curl is not enough, pretty sure can turn into a task to write a proper implementation that fulfill WebKit needs and that is integrated into EFL. +1 in the viewpoint that libcurl is way to go. But it may not be easy work. When we decide to use libsoup as default network backend, libcurl backend has many missing features such as cookie, cache, and so on. IIRC, they are still missing features. http://curl.haxx.se/docs/http-cookies.html I think that if you think that libcurl has missing features, maybe you should ask if they exist first in the curl mailing list or its IRC chan. Vincent -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics
Re: [E-devel] [e] e_sys_main.c
Le 31/10/2012 16:41, Michael Blumenkrantz a écrit : in. for future diffs please separate out all formatting changes into separate patches. ok -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ArchLinux updated binary packages?
On Wed, Oct 31, 2012 at 2:00 PM, Tom Hacohen t...@stosb.com wrote: On 31/10/12 17:46, Gustavo Sverzut Barbieri wrote: Hi all, Recently moved to Arch and I'm looking for daily/weekly updated EFL packages. Seems lots of developers use Arch, but instead build/install manually, no packaging -- what a shame. Given that Arch provides ABS/AUR, I'm pretty sure we could have this and share... same effort, but more organized and easier to use by our users. Compared to Gentoo, seems that the change is that for AUR we'd need a script that would walk every package in order and do: for p in efl evas ...; do (cd $p makepkg pacman $p.tar.xz) || exit 1 done after that we can scp the .tar.xz to our server and other people can use it. Could we do this from e3/e4/e5? There's Arch e17: https://dev.archlinux.org/~ronald/e17.html I build my own checkouts so I have modified PKGBUILDs and a small script that does exactly what you've described... I don't think there's a real reason to maintain our own builds as the packages are mostly up to date. Also, soon enough we'll have a release and we'd want to discourage people from building off svn anyway. Furthermore, soon enough we'll have just one tree which will make this even easier. HI BITCH would you stop being a bitch and add these to svn under packaging/arch? I was doing something in these lines... got interrupted, fortunately, because it may be useless work :-P -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ArchLinux updated binary packages?
On Wed, 31 Oct 2012 17:04:38 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Oct 31, 2012 at 2:00 PM, Tom Hacohen t...@stosb.com wrote: On 31/10/12 17:46, Gustavo Sverzut Barbieri wrote: Hi all, Recently moved to Arch and I'm looking for daily/weekly updated EFL packages. Seems lots of developers use Arch, but instead build/install manually, no packaging -- what a shame. Given that Arch provides ABS/AUR, I'm pretty sure we could have this and share... same effort, but more organized and easier to use by our users. Compared to Gentoo, seems that the change is that for AUR we'd need a script that would walk every package in order and do: for p in efl evas ...; do (cd $p makepkg pacman $p.tar.xz) || exit 1 done after that we can scp the .tar.xz to our server and other people can use it. Could we do this from e3/e4/e5? There's Arch e17: https://dev.archlinux.org/~ronald/e17.html I build my own checkouts so I have modified PKGBUILDs and a small script that does exactly what you've described... I don't think there's a real reason to maintain our own builds as the packages are mostly up to date. Also, soon enough we'll have a release and we'd want to discourage people from building off svn anyway. Furthermore, soon enough we'll have just one tree which will make this even easier. HI BITCH would you stop being a bitch and add these to svn under packaging/arch? I was doing something in these lines... got interrupted, fortunately, because it may be useless work :-P HAHAHAHAHAHAHAHAHAHA -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On 10/31/2012 03:50 PM, Vincent Torri wrote: http://curl.haxx.se/docs/http-cookies.html I think that if you think that libcurl has missing features, maybe you should ask if they exist first in the curl mailing list or its IRC chan. The cURL backend in WebKit is quite poor. It not only less performant than the libsoup one, but it also lack certain things, like persistent cookie storage support. The only port that uses cURL right now, if I recall correctly, is the windows-cairo port (the official Windows port by Apple uses a proprietary framework ported from OS X). We've used to support it as well, but decided not to anymore due to various complications not only with the cURL support code in WebKit, but with cURL itself, which as powerful as it is, it's not a library that's easy to work with, specially if you need something beyond the basics. Granted, since cURL itself already supports persistent cookie storage, adding support for it in WebKit wouldn't be too difficult, I guess. I haven't been following WebKit in a while and it might even be implemented already. However, there are quite a lot of other things that should be implemented that are already there in the LibSoup support code, and they're quite tricky to be implemented with cURL. I don't like to depend on GLib just for the network part as much as the next guy, but I believe that, right now, libsoup is still our best alternative in WebKit-EFL. Cheers, Leandro -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ArchLinux updated binary packages?
On 31/10/12 21:04, Gustavo Sverzut Barbieri wrote: HI BITCH would you stop being a bitch and add these to svn under packaging/arch? I was doing something in these lines... got interrupted, fortunately, because it may be useless work :-P Pfft, you damn open source nuts, wanting to share everything... It's there in svn (78718). People who just want to get e from svn should use ronald's script. -- Tom. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: hermet IN trunk/evas/src/lib: . canvas include
On Mon, Oct 29, 2012 at 11:28 PM, ChunEon Park her...@naver.com wrote: evas_object_image_source_event_set(proxy, EINA_TRUE); this one? I can say Evas Events can be passed to the source definitely now. (if not, then it's bug. should be fixed.) But some smart events (i.e. in elementary widgets) may not be happened by this mechanism because of the focus or whatever event hold or grab problem. What object type of the source is? Elm image. Could u give me test case for it? OK, the initial issue was that my proxies were smaller (obj size) then source / map. So it was receiving events only on part of the map. It was fixed setting the same size for proxies and source. But when I was looking for this issue, I found the following line on _image_source_visible_set evas_object_image.c:633 //FIXME: Feed mouse events here. So I decided to send this email. OK, that was solved, but when I'm trying to grab an object it receives a wrong value on Evas_Event_Mouse_Move, received on the move callback of the source object. I'm not sure if it's an issue with proxy - source events conversion, or it's an issue on map conversion, or even a misuse on ephysics, since I wasn't able to reproduce it on a smaller example. The ephysics test displaying such error has about 450 proxy objects. I've upstreamed the code, so if you run $ephysics_test -to Flag - Cloth you will see, moving the mouse over it will print canvas.x, canvas.y, output.x, output.y They look fine while you're just moving, but if you try to grab one of them, values will be something like -687194607, -2147483505 ... this test code is on src/bin/test_flag.c slicing code (where it creates and manipulates proxies) is on _ephysics_body_soft_body_slices_init and _ephysics_body_soft_body_slices_apply I would be really glad if you have some time to take a look on this. Thanks I need to check it to fix. -Regards, Hermet- -Original Message- From: Bruno Dillylt;bdi...@profusion.mobigt; To: Enlightenment developer listlt;enlightenment-devel@lists.sourceforge.netgt;; Cc: Sent: 2012-10-30 (화) 01:58:43 Subject: Re: [E-devel] E SVN: hermet IN trunk/evas/src/lib: . canvas include On Tue, Oct 23, 2012 at 2:42 PM, Bruno Dilly lt;bdillygt;@profusion.mobigt; wrote: gt; On Tue, Oct 23, 2012 at 12:35 PM, ChunEon Park lt;hermetgt;@naver.comgt; wrote: gt;gt; gt;gt; Sorry. totally I mistook for your reply. gt;gt; gt;gt; Here is the actually example for this API. gt;gt; gt;gt; gt;gt; gt;gt; ex) gt;gt; gt;gt; Evas_Object *btn; gt;gt; gt;gt; Evas_Object *img; gt;gt; gt;gt; gt;gt; gt;gt; ... gt;gt; gt;gt; gt;gt; gt;gt; evas_object_show(btn); gt;gt; gt;gt; evas_object_show(img); gt;gt; gt;gt; gt;gt; gt;gt; evas_object_image_source_set(img, btn); gt;gt; gt;gt; evas_object_image_source_visible_set(img, EINA_FALSE); gt; gt; Right, right. gt; It should be set on proxy. gt; I misunderstood your commit. gt; gt;gt; gt;gt; gt;gt; gt;gt; //here is a more API added. gt;gt; gt;gt; evas_object_image_source_event_set(img, EINA_TRUE); //this img will pass it's events to btn. gt; gt; Great addition, btw. gt; I believe it will be useful as well. Hi again, Hermet, I've tried to use it on ephysics, but it's missing mouse events handling. Are you planning to make it work ? Do you have an expected date to commit it ? Regards gt; gt; =) gt; gt;gt; gt;gt; gt;gt; gt;gt; Only the final state will be available for source visiblity, gt;gt; gt;gt; If the multiple proxies are racing to set their shared source visibility. gt;gt; gt;gt; gt;gt; gt;gt; And doc and example needs to be updated. gt;gt; gt;gt; gt;gt; gt;gt; Thank you. gt;gt; gt;gt; gt;gt; gt;gt; -Regards, Hermet- gt;gt; gt;gt; gt;gt; -Original Message- gt;gt; From: Rafael Antognollilt;antogno...@gmail.comgt; gt;gt; To: Enlightenment developer listlt;enlightenment-devel@lists.sourceforge.netgt;; gt;gt; Cc: gt;gt; Sent: 2012-10-23 (화) 20:04:15 gt;gt; Subject: Re: [E-devel] E SVN: hermet IN trunk/evas/src/lib: . canvas include gt;gt; gt;gt; Hello Hermet, gt;gt; gt;gt; The feature seems nice, good work! gt;gt; gt;gt; But I am still not sure how to control the source object from gt;gt; different proxies. Will there be any conflict if different proxies set gt;gt; the source to different visible states? Is that expected or, if it's gt;gt; wrong to do it, maybe this should be added to the docs? gt;gt; gt;gt; On Mon, Oct 22, 2012 at 11:42 PM, ChunEon Park lt;hermetgt;@naver.comgt; wrote: gt;gt; gt; ahh mistake. gt;gt; gt; gt;gt; gt; gt;gt; gt; do FALSE. gt;gt; gt; gt;gt; gt; evas_object_image_source_visible_set(source, EINA_FALSE); gt;gt; gt; gt;gt; gt; gt;gt; gt; gt;gt; gt; gt;gt; gt; -Regards, Hermet- gt;gt; gt; gt;gt; gt; -Original Message- gt;gt; gt; From: ChunEon
Re: [E-devel] E SVN: hermet IN trunk/evas/src/lib: . canvas include
Ok i will see this. Thank you for reporting. -Regards, Hermet- -Original Message- From: Bruno Dillylt;bdi...@profusion.mobigt; To: Enlightenment developer listlt;enlightenment-devel@lists.sourceforge.netgt;; Cc: Sent: 2012-11-01 (목) 06:29:06 Subject: Re: [E-devel] E SVN: hermet IN trunk/evas/src/lib: . canvas include On Mon, Oct 29, 2012 at 11:28 PM, ChunEon Park lt;hermetgt;@naver.comgt; wrote: gt; evas_object_image_source_event_set(proxy, EINA_TRUE); gt; this one? gt; gt; gt; I can say Evas Events can be passed to the source definitely now. gt; gt; (if not, then it's bug. should be fixed.) gt; gt; gt; But some smart events (i.e. in elementary widgets) may not be happened by this mechanism because of the focus or whatever event hold or grab problem. gt; gt; gt; gt; What object type of the source is? Elm image. gt; gt; gt; gt; Could u give me test case for it? OK, the initial issue was that my proxies were smaller (obj size) then source / map. So it was receiving events only on part of the map. It was fixed setting the same size for proxies and source. But when I was looking for this issue, I found the following line on _image_source_visible_set evas_object_image.c:633 //FIXME: Feed mouse events here. So I decided to send this email. OK, that was solved, but when I'm trying to grab an object it receives a wrong value on Evas_Event_Mouse_Move, received on the move callback of the source object. I'm not sure if it's an issue with proxy -gt; source events conversion, or it's an issue on map conversion, or even a misuse on ephysics, since I wasn't able to reproduce it on a smaller example. The ephysics test displaying such error has about 450 proxy objects. I've upstreamed the code, so if you run $ephysics_test -to Flag - Cloth you will see, moving the mouse over it will print canvas.x, canvas.y, output.x, output.y They look fine while you're just moving, but if you try to grab one of them, values will be something like -687194607, -2147483505 ... this test code is on src/bin/test_flag.c slicing code (where it creates and manipulates proxies) is on _ephysics_body_soft_body_slices_init and _ephysics_body_soft_body_slices_apply I would be really glad if you have some time to take a look on this. Thanks gt; gt; gt; gt; I need to check it to fix. gt; gt; gt; gt; gt; gt; -Regards, Hermet- gt; gt; -Original Message- gt; From: Bruno Dillylt;bdi...@profusion.mobigt; gt; To: Enlightenment developer listlt;enlightenment-devel@lists.sourceforge.netgt;; gt; Cc: gt; Sent: 2012-10-30 (화) 01:58:43 gt; Subject: Re: [E-devel] E SVN: hermet IN trunk/evas/src/lib: . canvas include gt; gt; On Tue, Oct 23, 2012 at 2:42 PM, Bruno Dilly lt;bdillygt;@profusion.mobigt; wrote: gt; gt; On Tue, Oct 23, 2012 at 12:35 PM, ChunEon Park lt;hermetgt;@naver.comgt; wrote: gt; gt;gt; gt; gt;gt; Sorry. totally I mistook for your reply. gt; gt;gt; gt; gt;gt; Here is the actually example for this API. gt; gt;gt; gt; gt;gt; gt; gt;gt; gt; gt;gt; ex) gt; gt;gt; gt; gt;gt; Evas_Object *btn; gt; gt;gt; gt; gt;gt; Evas_Object *img; gt; gt;gt; gt; gt;gt; gt; gt;gt; gt; gt;gt; ... gt; gt;gt; gt; gt;gt; gt; gt;gt; gt; gt;gt; evas_object_show(btn); gt; gt;gt; gt; gt;gt; evas_object_show(img); gt; gt;gt; gt; gt;gt; gt; gt;gt; gt; gt;gt; evas_object_image_source_set(img, btn); gt; gt;gt; gt; gt;gt; evas_object_image_source_visible_set(img, EINA_FALSE); gt; gt; gt; gt; Right, right. gt; gt; It should be set on proxy. gt; gt; I misunderstood your commit. gt; gt; gt; gt;gt; gt; gt;gt; gt; gt;gt; gt; gt;gt; //here is a more API added. gt; gt;gt; gt; gt;gt; evas_object_image_source_event_set(img, EINA_TRUE); //this img will pass it's events to btn. gt; gt; gt; gt; Great addition, btw. gt; gt; I believe it will be useful as well. gt; gt; Hi again, Hermet, gt; gt; I've tried to use it on ephysics, but it's missing mouse events handling. gt; Are you planning to make it work ? Do you have an expected date to commit it ? gt; gt; Regards gt; gt; gt; gt; gt; =) gt; gt; gt; gt;gt; gt; gt;gt; gt; gt;gt; gt; gt;gt; Only the final state will be available for source visiblity, gt; gt;gt; gt; gt;gt; If the multiple proxies are racing to set their shared source visibility. gt; gt;gt; gt; gt;gt; gt; gt;gt; gt; gt;gt; And doc and example needs to be updated. gt; gt;gt; gt; gt;gt; gt; gt;gt; gt; gt;gt; Thank you. gt; gt;gt; gt; gt;gt; gt; gt;gt; gt; gt;gt; -Regards, Hermet- gt; gt;gt; gt; gt;gt; gt; gt;gt; -Original Message- gt; gt;gt; From: Rafael Antognollilt;antogno...@gmail.comgt; gt; gt;gt; To: Enlightenment developer listlt;enlightenment-devel@lists.sourceforge.netgt;; gt; gt;gt; Cc: gt; gt;gt; Sent: 2012-10-23 (화) 20:04:15 gt; gt;gt; Subject: Re: [E-devel] E SVN: hermet IN trunk/evas/src/lib: . canvas include gt; gt;gt; gt; gt;gt; Hello Hermet, gt; gt;gt; gt; gt;gt; The feature seems nice, good work!
