Re: [E-devel] 1.13 release schedule proposal
Hello. On 27/10/14 14:42, Stefan Schmidt wrote: Comments, opinions? If nothing speaks against this I would consider it agreed upon next week. I heard no disagreements so far so I consider this as our final release schedule for 1.13 now. regards Stefan Schmidt -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] 1.13 release schedule proposal
On 04/11/14 09:04, Stefan Schmidt wrote: Hello. On 27/10/14 14:42, Stefan Schmidt wrote: Comments, opinions? If nothing speaks against this I would consider it agreed upon next week. I heard no disagreements so far so I consider this as our final release schedule for 1.13 now. I'd say yes. -- Tom. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
In Fedora, installing libappindicator and libappindicator-gtk3 makes the Network Manager Applet work without Xembed but the systray is all messed up. The first app loaded works properly but when you load additional apps, you get distorted and overlapping icons which do not go away entirely when the app is closed. Restarting E fixes the current problems but everything goes South again the next time you make any change to the systray. At any rate, it works a lot better with Xembed. AppIndicator probably needs more work before Xembed is eliminated. Mike -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
On 04/11/14 11:00, Michael Hughes wrote: In Fedora, installing libappindicator and libappindicator-gtk3 makes the Network Manager Applet work without Xembed but the systray is all messed up. The first app loaded works properly but when you load additional apps, you get distorted and overlapping icons which do not go away entirely when the app is closed. Restarting E fixes the current problems but everything goes South again the next time you make any change to the systray. At any rate, it works a lot better with Xembed. AppIndicator probably needs more work before Xembed is eliminated. Please report bugs. The thing about appindicator is that it's very easy to debug and solve (compared to xembed). -- Tom. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: elua: load .dylib on OSX
q66 pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=9fa0e6ea19a36f8fdf8e8fb6abb5c05cbf2bfc60 commit 9fa0e6ea19a36f8fdf8e8fb6abb5c05cbf2bfc60 Author: Jean Guyomarc'h jean.guyoma...@gmail.com Date: Tue Nov 4 11:55:14 2014 + elua: load .dylib on OSX Summary: On OSX, libraries are generated as .dylib instead of .so. This led elua to try loading missing libraries, and therefore crashing. @fix Reviewers: cedric, q66 Reviewed By: q66 Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D1642 --- src/bin/elua/core/util.lua | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/bin/elua/core/util.lua b/src/bin/elua/core/util.lua index 78db3ab..44a5042 100644 --- a/src/bin/elua/core/util.lua +++ b/src/bin/elua/core/util.lua @@ -77,6 +77,8 @@ M.lib_load = function(libname) else if ffi.os == Windows then lib = ffi.load(ev .. \\ .. libname .. .dll) +elseif ffi.os == OSX then +lib = ffi.load(ev .. /lib .. libname .. .dylib) else lib = ffi.load(ev .. /lib .. libname .. .so) end --
[EGIT] [core/efl] master 01/01: Ecore File: Corrected documentation of ecore_file_monitor_add API
devilhorns pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=0abcd5133e4ccb18d1b01f18537b6012268b28f3 commit 0abcd5133e4ccb18d1b01f18537b6012268b28f3 Author: kabeer khan kabeer.k...@samsung.com Date: Tue Nov 4 08:53:17 2014 -0500 Ecore File: Corrected documentation of ecore_file_monitor_add API Summary: Added condition that if given path does not exist it returns NULL @fix Signed-off-by: kabeer khan kabeer.k...@samsung.com Reviewers: englebass, devilhorns Reviewed By: devilhorns Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D1640 --- src/lib/ecore_file/ecore_file_monitor.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/lib/ecore_file/ecore_file_monitor.c b/src/lib/ecore_file/ecore_file_monitor.c index df038cd..7b4f625 100644 --- a/src/lib/ecore_file/ecore_file_monitor.c +++ b/src/lib/ecore_file/ecore_file_monitor.c @@ -34,11 +34,12 @@ ecore_file_monitor_shutdown(void) * * This function monitors @p path. If @p path is @c NULL, or is an * empty string, or none of the notify methods (Inotify, Windows - * notification or polling) is available, the function returns @c NULL. - * Otherwise, it returns a newly allocated Ecore_File_Monitor object - * and the monitoring begins. When one of the Ecore_File_Event - * event is notified, @p func is called and @p data is passed to @p func. - * Call ecore_file_monitor_del() to stop the monitoring. + * notification or polling) is available, or if @p path does not exist + * the function returns @c NULL. Otherwise, it returns a newly + * allocated Ecore_File_Monitor object and the monitoring begins. + * When one of the Ecore_File_Event event is notified, @p func is called + * and @p data is passed to @p func.Call ecore_file_monitor_del() to + * stop the monitoring. */ EAPI Ecore_File_Monitor * ecore_file_monitor_add(const char *path, --
Re: [E-devel] [EGIT] [core/efl] master 01/01: elua: load .dylib on OSX
That's why autofoo has a variable for lib extension. Use it... -- Tom. On 04/11/14 11:58, Jean Guyomarc'h wrote: q66 pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=9fa0e6ea19a36f8fdf8e8fb6abb5c05cbf2bfc60 commit 9fa0e6ea19a36f8fdf8e8fb6abb5c05cbf2bfc60 Author: Jean Guyomarc'h jean.guyoma...@gmail.com Date: Tue Nov 4 11:55:14 2014 + elua: load .dylib on OSX Summary: On OSX, libraries are generated as .dylib instead of .so. This led elua to try loading missing libraries, and therefore crashing. @fix Reviewers: cedric, q66 Reviewed By: q66 Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D1642 --- src/bin/elua/core/util.lua | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/bin/elua/core/util.lua b/src/bin/elua/core/util.lua index 78db3ab..44a5042 100644 --- a/src/bin/elua/core/util.lua +++ b/src/bin/elua/core/util.lua @@ -77,6 +77,8 @@ M.lib_load = function(libname) else if ffi.os == Windows then lib = ffi.load(ev .. \\ .. libname .. .dll) +elseif ffi.os == OSX then +lib = ffi.load(ev .. /lib .. libname .. .dylib) else lib = ffi.load(ev .. /lib .. libname .. .so) end -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: elua: load .dylib on OSX
2014-11-04 14:17 GMT+00:00 Tom Hacohen tom.haco...@samsung.com: That's why autofoo has a variable for lib extension. Use it... I was thinking about doing that, but decided it was counter-intuitive. It'd actually be more code to use that variable as well as make editing things more painful (as I'd have to generate util.lua, which would have a need for util.lua.in, which editors wouldn't recognize as lua... I'm not even talking about that it's not only an extension thing, Windows uses foo.dll pattern while other OSes typically use libfoo.ext). We don't currently support any OSes that don't follow this pattern - and if we ever do, it'll be very easy to detect and port, as that code path is triggered when you build the EFL - as such, I'd opt for keeping the current code as it is, and only use the variable if ever necessary (which I don't think will happen). -- Tom. On 04/11/14 11:58, Jean Guyomarc'h wrote: q66 pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=9fa0e6ea19a36f8fdf8e8fb6abb5c05cbf2bfc60 commit 9fa0e6ea19a36f8fdf8e8fb6abb5c05cbf2bfc60 Author: Jean Guyomarc'h jean.guyoma...@gmail.com Date: Tue Nov 4 11:55:14 2014 + elua: load .dylib on OSX Summary: On OSX, libraries are generated as .dylib instead of .so. This led elua to try loading missing libraries, and therefore crashing. @fix Reviewers: cedric, q66 Reviewed By: q66 Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D1642 --- src/bin/elua/core/util.lua | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/bin/elua/core/util.lua b/src/bin/elua/core/util.lua index 78db3ab..44a5042 100644 --- a/src/bin/elua/core/util.lua +++ b/src/bin/elua/core/util.lua @@ -77,6 +77,8 @@ M.lib_load = function(libname) else if ffi.os == Windows then lib = ffi.load(ev .. \\ .. libname .. .dll) +elseif ffi.os == OSX then +lib = ffi.load(ev .. /lib .. libname .. .dylib) else lib = ffi.load(ev .. /lib .. libname .. .so) end -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel D5 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: elua: only gendep on lualian when building in-tree
q66 pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=856db64d92e3bc3ec97a5c36f84e81947b54143d
commit 856db64d92e3bc3ec97a5c36f84e81947b54143d
Author: Daniel Kolesa d.kol...@samsung.com
Date: Tue Nov 4 16:38:41 2014 +
elua: only gendep on lualian when building in-tree
---
src/Makefile_Elua_Helper.am | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/Makefile_Elua_Helper.am b/src/Makefile_Elua_Helper.am
index d6f383c..c92f2df 100644
--- a/src/Makefile_Elua_Helper.am
+++ b/src/Makefile_Elua_Helper.am
@@ -4,7 +4,7 @@ _ELUA_GEN_DEP = @elua_bin@
else
ELUA_GEN = ELUA_EOLIAN_LIBRARY_PATH=$(top_builddir)/src/lib/eolian/.libs \
EFL_RUN_IN_TREE=1 $(top_builddir)/src/bin/elua/elua${EXEEXT} :lualian
-_ELUA_GEN_DEP = bin/elua/elua${EXEEXT}
+_ELUA_GEN_DEP = bin/elua/elua${EXEEXT} bin/elua/modules/lualian.lua
endif
AM_V_ELUA = $(am__v_ELUA_@AM_V@)
@@ -13,7 +13,7 @@ am__v_ELUA_0 = @echo ELUA $@;
SUFFIXES += .lua
-%.eo.lua: %.eo ${_ELUA_GEN_DEP} bin/elua/modules/lualian.lua
+%.eo.lua: %.eo ${_ELUA_GEN_DEP}
$(AM_V_ELUA)$(ELUA_GEN) $(EOLIAN_FLAGS) -o $@ $
CLEANFILES += $(BUILT_SOURCES)
--
Re: [E-devel] [EGIT] [core/efl] master 01/01: elua: load .dylib on OSX
Hi, On Tue, Nov 04, 2014, Daniel Kolesa wrote: 2014-11-04 14:17 GMT+00:00 Tom Hacohen tom.haco...@samsung.com: That's why autofoo has a variable for lib extension. Use it... I was thinking about doing that, but decided it was counter-intuitive. It'd actually be more code to use that variable as well as make editing things more painful (as I'd have to generate util.lua, which would have a need for util.lua.in, which editors wouldn't recognize as lua... I'm not even talking about that it's not only an extension thing, Windows uses foo.dll pattern while other OSes typically use libfoo.ext). We don't currently support any OSes that don't follow this pattern - and if we ever do, it'll be very easy to detect and port, as that code path is triggered when you build the EFL - as such, I'd opt for keeping the current code as it is, and only use the variable if ever necessary (which I don't think will happen). Everything built through libtool, no matter if for Windows or not, will use the libfoo-X.bar pattern. In my builds for Windows, everything uses that except SDL and, of course, Qt. Regards, Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
what about having an option like?: --enable-xembed (makes traditional systray to work in a ugly way) and so having it disabled by default, but optional for who needs it i personally think that if we restrict some usabilities, ppl will move to, let's say kde or gnome just because it makes its needs working 2014-11-04 12:52 GMT+01:00 Tom Hacohen tom.haco...@samsung.com: On 04/11/14 11:00, Michael Hughes wrote: In Fedora, installing libappindicator and libappindicator-gtk3 makes the Network Manager Applet work without Xembed but the systray is all messed up. The first app loaded works properly but when you load additional apps, you get distorted and overlapping icons which do not go away entirely when the app is closed. Restarting E fixes the current problems but everything goes South again the next time you make any change to the systray. At any rate, it works a lot better with Xembed. AppIndicator probably needs more work before Xembed is eliminated. Please report bugs. The thing about appindicator is that it's very easy to debug and solve (compared to xembed). -- Tom. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
Date: Tue, 4 Nov 2014 20:18:48 +0100 From: thanatermesis.e...@gmail.com To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] RFC - Dropping Xembed support from E20 what about having an option like?: --enable-xembed (makes traditional systray to work in a ugly way) and so having it disabled by default, but optional for who needs it i personally think that if we restrict some usabilities, ppl will move to, let's say kde or gnome just because it makes its needs working I think you missed the part about KDE dropping this completely as well. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
Hello, On Tue, Nov 4, 2014 at 8:18 PM, Thanatermesis thanatermesis.e...@gmail.com wrote: what about having an option like?: --enable-xembed (makes traditional systray to work in a ugly way) and so having it disabled by default, but optional for who needs it i personally think that if we restrict some usabilities, ppl will move to, let's say kde or gnome just because it makes its needs working They wont go to KDE for that purpose : https://plus.google.com/+MartinGr%C3%A4%C3%9Flin/posts/7YpzTNC3WF6 I think it is a very good opportunity for all desktop environment to phase it out. Everyone agree everywhere that it is broken. Only a few application resist doing the change. The more environment there is that doesn't work for them the more they will be forced into fixing their application. So I am also all for permanently phasing it out, no matter the cost ! If you have application requiring xembed, open a bug on the application side to move away from it. That's the best course of action. You have time until the release of E20... 2014-11-04 12:52 GMT+01:00 Tom Hacohen tom.haco...@samsung.com: On 04/11/14 11:00, Michael Hughes wrote: In Fedora, installing libappindicator and libappindicator-gtk3 makes the Network Manager Applet work without Xembed but the systray is all messed up. The first app loaded works properly but when you load additional apps, you get distorted and overlapping icons which do not go away entirely when the app is closed. Restarting E fixes the current problems but everything goes South again the next time you make any change to the systray. At any rate, it works a lot better with Xembed. AppIndicator probably needs more work before Xembed is eliminated. Please report bugs. The thing about appindicator is that it's very easy to debug and solve (compared to xembed). -- Tom. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Cedric BAIL -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: eldbus-codegen now outputs compileable code for complex method signatures
discomfitor pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=80076bffb91b09690067af6def78756f2ab9d95a commit 80076bffb91b09690067af6def78756f2ab9d95a Author: zmike michael.blumenkra...@gmail.com Date: Tue Nov 4 17:40:59 2014 -0500 eldbus-codegen now outputs compileable code for complex method signatures it would be an understatement to say that I am disappointed by the original author's decision to write zero tests for this utility. --- src/bin/eldbus/source_client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/bin/eldbus/source_client.c b/src/bin/eldbus/source_client.c index af21c29..b31c68a 100644 --- a/src/bin/eldbus/source_client.c +++ b/src/bin/eldbus/source_client.c @@ -103,7 +103,7 @@ source_client_complex_method_call_generate(const DBus_Method *method, Eina_Strbu eina_strbuf_append_printf(c_code, ERR(\Error: Filling message from eina value.\);\n); eina_strbuf_append_printf(c_code, return;\n); eina_strbuf_append_printf(c_code, }\n); -eina_strbuf_append_printf(c_code,eldbus_proxy_send(proxy, msg, %s, NULL, NULL, -1);\n, method-cb_name); +eina_strbuf_append_printf(c_code,eldbus_proxy_send(proxy, msg, NULL, NULL, -1);\n); eina_strbuf_append_printf(c_code, }\n); goto end; } --
[EGIT] [core/efl] master 01/01: addendum to previous commit: use callback param but still compile
discomfitor pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=dbd3bea99e9ad6baa4574b6259d6b627bc897d03 commit dbd3bea99e9ad6baa4574b6259d6b627bc897d03 Author: zmike michael.blumenkra...@gmail.com Date: Tue Nov 4 17:58:39 2014 -0500 addendum to previous commit: use callback param but still compile --- src/bin/eldbus/source_client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/bin/eldbus/source_client.c b/src/bin/eldbus/source_client.c index b31c68a..28a605a 100644 --- a/src/bin/eldbus/source_client.c +++ b/src/bin/eldbus/source_client.c @@ -103,7 +103,7 @@ source_client_complex_method_call_generate(const DBus_Method *method, Eina_Strbu eina_strbuf_append_printf(c_code, ERR(\Error: Filling message from eina value.\);\n); eina_strbuf_append_printf(c_code, return;\n); eina_strbuf_append_printf(c_code, }\n); -eina_strbuf_append_printf(c_code,eldbus_proxy_send(proxy, msg, NULL, NULL, -1);\n); +eina_strbuf_append_printf(c_code,eldbus_proxy_send(proxy, msg, %s, NULL, -1);\n, method-cb_name); eina_strbuf_append_printf(c_code, }\n); goto end; } --
[EGIT] [core/efl] master 01/02: warnings: remove 2 equality comparison with extraneous parentheses
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=704c448141888d18dde8a73b727856a77edcc189
commit 704c448141888d18dde8a73b727856a77edcc189
Author: Jean Guyomarc'h jean.guyoma...@gmail.com
Date: Tue Nov 4 23:59:59 2014 +0100
warnings: remove 2 equality comparison with extraneous parentheses
Reviewers: stefan_schmidt, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1644
Signed-off-by: Cedric BAIL ced...@osg.samsung.com
---
src/lib/ecore_x/xlib/ecore_x.c | 2 +-
src/modules/evas/engines/gl_common/evas_gl_api_gles1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/lib/ecore_x/xlib/ecore_x.c b/src/lib/ecore_x/xlib/ecore_x.c
index 2e84968..c1fb140 100644
--- a/src/lib/ecore_x/xlib/ecore_x.c
+++ b/src/lib/ecore_x/xlib/ecore_x.c
@@ -326,7 +326,7 @@ _ecore_x_modifiers_get(void)
if (ECORE_X_MODIFIER_SHIFT)
{
-if ((ECORE_X_MODIFIER_SHIFT == ECORE_X_MODIFIER_CTRL))
+if (ECORE_X_MODIFIER_SHIFT == ECORE_X_MODIFIER_CTRL)
{
ERR(CTRL conflicts with other modifiers. IGNORE CTRL);
ECORE_X_MODIFIER_CTRL = 0;
diff --git a/src/modules/evas/engines/gl_common/evas_gl_api_gles1.c
b/src/modules/evas/engines/gl_common/evas_gl_api_gles1.c
index 0e1a5e5..f03d731 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_api_gles1.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_api_gles1.c
@@ -974,7 +974,7 @@ _evgl_gles1_glGetIntegerv(GLenum pname, GLint *params)
*/
// If it hasn't been initialized yet, return img object size
- if ((pname == GL_SCISSOR_BOX)) //|| (pname == GL_VIEWPORT))
+ if (pname == GL_SCISSOR_BOX) //|| (pname == GL_VIEWPORT))
{
params[0] = 0;
params[1] = 0;
--
[EGIT] [core/efl] master 02/02: edje: fix edje_object_part_text_item_list_get and edje_object_part_text_item_geometry_get
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=a5e3e0d0d44f51b2c28a89413fdddf552fe636f3
commit a5e3e0d0d44f51b2c28a89413fdddf552fe636f3
Author: artem.popov artem.po...@samsung.com
Date: Wed Nov 5 00:00:45 2014 +0100
edje: fix edje_object_part_text_item_list_get and
edje_object_part_text_item_geometry_get
Summary:
There is copy-paste bug, when _anchors_get works in the same way like
_items_get. edje_object_part_text_item_list_get and
edje_object_part_text_item_geometry_get didn't work.
@fix
Reviewers: seoz, Hermet, raster, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1641
Signed-off-by: Cedric BAIL ced...@osg.samsung.com
---
src/lib/edje/edje_entry.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/lib/edje/edje_entry.c b/src/lib/edje/edje_entry.c
index be9f824..61d38b8 100644
--- a/src/lib/edje/edje_entry.c
+++ b/src/lib/edje/edje_entry.c
@@ -2961,7 +2961,7 @@ _edje_entry_item_geometry_get(Edje_Real_Part *rp, const
char *item, Evas_Coord *
EINA_LIST_FOREACH(en-anchors, l, an)
{
const char *n = an-name;
-if (an-item) continue;
+if (!an-item) continue;
if (!n) n = ;
if (!strcmp(item, n))
{
@@ -2988,7 +2988,7 @@ _edje_entry_items_list(Edje_Real_Part *rp)
EINA_LIST_FOREACH(en-anchors, l, an)
{
const char *n = an-name;
- if (an-item) continue;
+ if (!an-item) continue;
if (!n) n = ;
items = eina_list_append(items, strdup(n));
}
--
Re: [E-devel] Stable vs unstable convention?
Hello. On 03/11/14 01:44, Nex6|Bill wrote: so; each “branch” E17, E18, E19 would be considered “stable” but the verious OS teams and packaging teams are just being very conservative in staying with E17. since its the sort of proven stable, and the dependancies may be easier to target. We can only do the releases. It's up to the packagers to pick them up. regards Trying to reply to Stefan's comments in the gmail web interface (Sorry for the broken ness) In a lot of cases for Linux distro's (Gentoo, Debian, Fedora, etc) (Examples taken from what i heard on IRC) the main reason that there is no e19 yet is because no one has done the packaging work most distro's haven't had a dedicated person packaging and pushing new enlightenment releases over a long term period (2+ years), most packages seem to have been created by someone who had a bit of time at one point and then stopped, hence the wide range of different versions that can be found. Some notable exceptions, Arch has apparently always had up to date packages, at openSUSE there is a team of 2 of us (myself included) that do updates in our spare time, openSUSE 13.2 released yesterday ships with e19. Gentoo used to have dedicated people but from what i've heard they haven't got to the latest release yet (atleast in the official archive) Bodhi and elive both seem to still be focusing on e17 (although e19 is being worked on for bodhi) I think this is more of a issue that in the past they shipped alot of extra themes and modules that weren't officially supported and that no longer work in e19 (stuff like engage for example) As for BSD's in general its probably again mostly a case of no one sitting down to do alot of the packaging work but there may also be work needed to port some parts of the efl libs with only Linux and maybe Win32 support to BSD api's i think eeze is the main example normally bought up here, but i'm no expert and it may already work. Maybe someone else can comment. Cheers Simon Lees -- Enlightenment Maintainer - openSUSE -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: elua: load .dylib on OSX
2014-11-04 18:44 GMT+00:00 Adrien Nader adr...@notk.org: Hi, On Tue, Nov 04, 2014, Daniel Kolesa wrote: 2014-11-04 14:17 GMT+00:00 Tom Hacohen tom.haco...@samsung.com: That's why autofoo has a variable for lib extension. Use it... I was thinking about doing that, but decided it was counter-intuitive. It'd actually be more code to use that variable as well as make editing things more painful (as I'd have to generate util.lua, which would have a need for util.lua.in, which editors wouldn't recognize as lua... I'm not even talking about that it's not only an extension thing, Windows uses foo.dll pattern while other OSes typically use libfoo.ext). We don't currently support any OSes that don't follow this pattern - and if we ever do, it'll be very easy to detect and port, as that code path is triggered when you build the EFL - as such, I'd opt for keeping the current code as it is, and only use the variable if ever necessary (which I don't think will happen). Everything built through libtool, no matter if for Windows or not, will use the libfoo-X.bar pattern. In my builds for Windows, everything uses that except SDL and, of course, Qt. In that case, I will have to special-case Windows slightly more... Regards, Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel D5 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: eldbus-codegen now outputs compileable code for complex method signatures
Have you tried to write tests to D-Bus? We had try to write eldbus tests but it was not running and to fix we would need to make some changes on E test server(that I don't have access to do), so we had comment the tests and stopped to write more tests. Instead I had write a userfull module to E using this utility, to test it. Sorry for any inconvenience On Tue, Nov 4, 2014 at 8:45 PM, Mike Blumenkrantz michael.blumenkra...@gmail.com wrote: discomfitor pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=80076bffb91b09690067af6def78756f2ab9d95a commit 80076bffb91b09690067af6def78756f2ab9d95a Author: zmike michael.blumenkra...@gmail.com Date: Tue Nov 4 17:40:59 2014 -0500 eldbus-codegen now outputs compileable code for complex method signatures it would be an understatement to say that I am disappointed by the original author's decision to write zero tests for this utility. --- src/bin/eldbus/source_client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/bin/eldbus/source_client.c b/src/bin/eldbus/source_client.c index af21c29..b31c68a 100644 --- a/src/bin/eldbus/source_client.c +++ b/src/bin/eldbus/source_client.c @@ -103,7 +103,7 @@ source_client_complex_method_call_generate(const DBus_Method *method, Eina_Strbu eina_strbuf_append_printf(c_code, ERR(\Error: Filling message from eina value.\);\n); eina_strbuf_append_printf(c_code, return;\n); eina_strbuf_append_printf(c_code, }\n); -eina_strbuf_append_printf(c_code,eldbus_proxy_send(proxy, msg, %s, NULL, NULL, -1);\n, method-cb_name); +eina_strbuf_append_printf(c_code,eldbus_proxy_send(proxy, msg, NULL, NULL, -1);\n); eina_strbuf_append_printf(c_code, }\n); goto end; } -- -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Stable vs unstable convention?
There is one inaccuracy with what you are saying. In terms of gentoo there is no packaging necessary just the ebuilds need to be updated. and I would not be one bit suprised its already out int he wild for gentoo somewhere for testing and stabilization purposes --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-11-05 00:22, Simon Lees wrote: Hello. On 03/11/14 01:44, Nex6|Bill wrote: so; each branch E17, E18, E19 would be considered stable but the verious OS teams and packaging teams are just being very conservative in staying with E17. since its the sort of proven stable, and the dependancies may be easier to target. We can only do the releases. It's up to the packagers to pick them up. regards Trying to reply to Stefan's comments in the gmail web interface (Sorry for the broken ness) In a lot of cases for Linux distro's (Gentoo, Debian, Fedora, etc) (Examples taken from what i heard on IRC) the main reason that there is no e19 yet is because no one has done the packaging work most distro's haven't had a dedicated person packaging and pushing new enlightenment releases over a long term period (2+ years), most packages seem to have been created by someone who had a bit of time at one point and then stopped, hence the wide range of different versions that can be found. Some notable exceptions, Arch has apparently always had up to date packages, at openSUSE there is a team of 2 of us (myself included) that do updates in our spare time, openSUSE 13.2 released yesterday ships with e19. Gentoo used to have dedicated people but from what i've heard they haven't got to the latest release yet (atleast in the official archive) Bodhi and elive both seem to still be focusing on e17 (although e19 is being worked on for bodhi) I think this is more of a issue that in the past they shipped alot of extra themes and modules that weren't officially supported and that no longer work in e19 (stuff like engage for example) As for BSD's in general its probably again mostly a case of no one sitting down to do alot of the packaging work but there may also be work needed to port some parts of the efl libs with only Linux and maybe Win32 support to BSD api's i think eeze is the main example normally bought up here, but i'm no expert and it may already work. Maybe someone else can comment. Cheers Simon Lees -- Enlightenment Maintainer - openSUSE -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel [1] Links: -- [1] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/elementary] master 01/01: elm_general: Add '*' explicitly for function pointer parameter
hermet pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=cfa792d1024abba70a697abace080598497778c0
commit cfa792d1024abba70a697abace080598497778c0
Author: Tae-Hwan Kim the81@samsung.com
Date: Wed Nov 5 15:01:15 2014 +0900
elm_general: Add '*' explicitly for function pointer parameter
Reviewers: raster, cedric, huchi, Hermet
Reviewed By: Hermet
Differential Revision: https://phab.enlightenment.org/D1637
---
src/lib/elm_general.h | 2 +-
src/lib/elm_main.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/lib/elm_general.h b/src/lib/elm_general.h
index 2ce7236..86eba3b 100644
--- a/src/lib/elm_general.h
+++ b/src/lib/elm_general.h
@@ -301,7 +301,7 @@ EAPI Eina_Bool elm_quicklaunch_prepare(int argc, char
**argv, const char *cwd);
/**
* Exposed symbol used only by macros and should not be used by apps
*/
-EAPI Eina_Bool elm_quicklaunch_fork(int argc, char **argv, char *cwd, void
(postfork_func) (void *data), void *postfork_data);
+EAPI Eina_Bool elm_quicklaunch_fork(int argc, char **argv, char *cwd, void
(*postfork_func) (void *data), void *postfork_data);
/**
* Exposed symbol used only by macros and should not be used by apps
diff --git a/src/lib/elm_main.c b/src/lib/elm_main.c
index a708d12..e7ae247 100644
--- a/src/lib/elm_main.c
+++ b/src/lib/elm_main.c
@@ -903,7 +903,7 @@ EAPI Eina_Bool
elm_quicklaunch_fork(intargc,
char **argv,
char *cwd,
- void (postfork_func) (void *data),
+ void (*postfork_func) (void *data),
void *postfork_data)
{
#ifdef HAVE_FORK
--
