Re: [E-devel] Eolian meta-data parsing, episode 3 (The Ragel Strikes Back)
On 12/08/2013 01:26 PM, Davide Andreoli wrote:
2013/12/8 Yakov Goldberg yako...@samsung.com
So, as soon as Ragel Strikes Back
here is Elm_Image in Jeremy's format.
http://pastebin.com/xptFf6y0
Properties and Methods are as Jeremy described.
And in the end you can also find implements and signals.
Just one suggestion: lets move implements content into properties
and methods:
methods{
some_method {
...
};
Evas_Smart :: show;
};
...only some comments about properties.
If we want to override , only setter or getter we need to specify set
or get.
If you have better ideas about syntax, please suggest.
properties{
some_prop {
...
};
Evas_Object :: color;
Evas_Object :: size :: set;
Evas_Object :: visibility :: get;
};
==
Some additional question.
Here is some part of ElmFileselector.eo file.
You can see selected_set and selected_get are described as methods.
Why? Because I generate, this eo file, by parsing descriptions of eo
classes.
If there are two functions which have:
- the same name with set/get suffix;
- the same number of parameters;
- all parameters are in for set
- all parameters are out for get
it will be described as property; (or only_set/only_get property)
if one of these rules fails, functions will be generated as methods.
Because of legacy, selected_set func returns, so here I generate it as
method.
methods {
selected_set {
/*@ Set, programmatically, the currently selected file/directory
in the given file selector widget */
return Eina_Bool;
params {
in const char* path; /*@ */
};
};
selected_get {
/*@ Get the currently selected item's (full) path, in the given
file the given file selector widget */
return const char*;
params {
};
};
}
But maybe, as soon as it is almost property (only one ret gets in the
way here), we can describe it as property, which returns some value.
selected: {
set: {
return : Eina_Bool,
comment: Set, programmatically, the currently selected
file/directory in the given file selector widget
},
get: {
comment: Get the currently selected item's (full) path, in
the given file the given file selector widget
},
parameters: [
{
path: [const char*, ]
}
]
},
We will generate Eo and C - legacy functions as they are now.
eo macro: selected_set EO_TYPECHECK (path, const char*) EO_TYPECHECK
(ret, Eina_Bool *)
eo macro: selected_get EO_TYPECHECK (path, const char**)
legacy: Eina_Bool elm_fileselector_selected_set(Eo * obj, const char*
path)
legacy: const char * elm_fileselector_selected_get(Eo * obj)
And C++, python and other bindings will ignore ret in setters/getters and
use it as property:
fileselector.path = /root/some/path/filename
So the question is:
should we treat it like this, or leave it as methods?
Yakov.
Hi all,
I have one main concern about the generation of bindings using the eo file:
how we like to manage complex types (see Eina_List) in the target language?
(python for example)
As the py bindings are implemented now (and I really like this!), we do not
provide bindings for eina types, but we convert to the corresponding python
type for the user.
For example:
Elm_Map {
{
property {
overlays {
get {
/*@ get a list of all the overlays in the map */
};
params {
Eina_List overlays; /*@ actually a list of Elm_Map_Overlay objs
*/
};
};
};
};
In this case we don't know what the eina_list overlays contain thus we
cannot automatically convert to the corresponding python list of object.
Other example of complex types I found to be used in the current bindings
are C array (usually with strings inside).
How can we solve this?
we could add the content of the complex type in the eo files:
params {
Eina_List(Elm_Map_Overlay) overlays; /*@ ...or a different syntax */
};
params {
Eina_List(char *) names; /*@ ...for an eina list of strings */
};
Thanks for comments.
Looks like it's good idea to do smth like that. But some conversion API
from
Elm_Map_Overlay to python object should be implemented.
but this can be tricky for more complex types, how we describe a C array of
strings?
Could you please give an example, which API does use it?
what do you guys think?
regards
davemds
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
Re: [E-devel] Eolian meta-data parsing, episode 3 (The Ragel Strikes Back)
On 12/09/2013 10:28 AM, Yakov Goldberg wrote:
On 12/08/2013 01:26 PM, Davide Andreoli wrote:
2013/12/8 Yakov Goldberg yako...@samsung.com
So, as soon as Ragel Strikes Back
here is Elm_Image in Jeremy's format.
http://pastebin.com/xptFf6y0
Properties and Methods are as Jeremy described.
And in the end you can also find implements and signals.
Just one suggestion: lets move implements content into properties
and methods:
methods{
some_method {
...
};
Evas_Smart :: show;
};
...only some comments about properties.
If we want to override , only setter or getter we need to specify set
or get.
If you have better ideas about syntax, please suggest.
properties{
some_prop {
...
};
Evas_Object :: color;
Evas_Object :: size :: set;
Evas_Object :: visibility :: get;
};
==
Some additional question.
Here is some part of ElmFileselector.eo file.
You can see selected_set and selected_get are described as methods.
Why? Because I generate, this eo file, by parsing descriptions of eo
classes.
If there are two functions which have:
- the same name with set/get suffix;
- the same number of parameters;
- all parameters are in for set
- all parameters are out for get
it will be described as property; (or only_set/only_get property)
if one of these rules fails, functions will be generated as methods.
Because of legacy, selected_set func returns, so here I generate it as
method.
methods {
selected_set {
/*@ Set, programmatically, the currently selected file/directory
in the given file selector widget */
return Eina_Bool;
params {
in const char* path; /*@ */
};
};
selected_get {
/*@ Get the currently selected item's (full) path, in the given
file the given file selector widget */
return const char*;
params {
};
};
}
But maybe, as soon as it is almost property (only one ret gets in the
way here), we can describe it as property, which returns some value.
selected: {
set: {
return : Eina_Bool,
comment: Set, programmatically, the currently selected
file/directory in the given file selector widget
},
get: {
comment: Get the currently selected item's (full) path, in
the given file the given file selector widget
},
parameters: [
{
path: [const char*, ]
}
]
},
We will generate Eo and C - legacy functions as they are now.
eo macro: selected_set EO_TYPECHECK (path, const char*) EO_TYPECHECK
(ret, Eina_Bool *)
eo macro: selected_get EO_TYPECHECK (path, const char**)
legacy: Eina_Bool elm_fileselector_selected_set(Eo * obj, const char*
path)
legacy: const char * elm_fileselector_selected_get(Eo * obj)
And C++, python and other bindings will ignore ret in setters/getters and
use it as property:
fileselector.path = /root/some/path/filename
So the question is:
should we treat it like this, or leave it as methods?
Yakov.
Hi all,
I have one main concern about the generation of bindings using the eo file:
how we like to manage complex types (see Eina_List) in the target language?
(python for example)
As the py bindings are implemented now (and I really like this!), we do not
provide bindings for eina types, but we convert to the corresponding python
type for the user.
For example:
Elm_Map {
{
property {
overlays {
get {
/*@ get a list of all the overlays in the map */
};
params {
Eina_List overlays; /*@ actually a list of Elm_Map_Overlay objs
*/
};
};
};
};
In this case we don't know what the eina_list overlays contain thus we
cannot automatically convert to the corresponding python list of object.
Other example of complex types I found to be used in the current bindings
are C array (usually with strings inside).
How can we solve this?
we could add the content of the complex type in the eo files:
params {
Eina_List(Elm_Map_Overlay) overlays; /*@ ...or a different syntax */
};
params {
Eina_List(char *) names; /*@ ...for an eina list of strings */
};
Thanks for comments.
Looks like it's good idea to do smth like that. But some conversion API
from
Elm_Map_Overlay to python object should be implemented.
Maybe the conversion of the Elm_Map_Overlay will need to be done
manually because of its complexity. At least at the beginning.
By the way, this structure is private to elementary so you will never
have it public from Python :P
And most of (or maybe all) the functions using this overlay don't
receive an object as parameter. It means that Eolian will not
[EGIT] [core/efl] master 01/02: Evas: Fix crash in GL engine(s) during preload cancel
jpeg pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=ce166ec2232f7628fe5f57603b58c4e620c60567
commit ce166ec2232f7628fe5f57603b58c4e620c60567
Author: Jean-Philippe Andre jp.an...@samsung.com
Date: Mon Dec 9 17:28:02 2013 +0900
Evas: Fix crash in GL engine(s) during preload cancel
In my config, running terminology with the GL engine and under
cserve2, some image could not be loaded. The tex argument
in evas_gl_preload_target_[un]register was NULL, leading to
an immediate crash.
---
src/modules/evas/engines/gl_common/evas_gl_preload.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/modules/evas/engines/gl_common/evas_gl_preload.c
b/src/modules/evas/engines/gl_common/evas_gl_preload.c
index fee5823..1995232 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_preload.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_preload.c
@@ -408,6 +408,8 @@ _evas_gl_preload_target_die(void *data, Eo *obj,
void
evas_gl_preload_target_register(Evas_GL_Texture *tex, Eo *target)
{
+ EINA_SAFETY_ON_NULL_RETURN(tex);
+
eo_do(target,
eo_event_callback_add(EO_EV_DEL, _evas_gl_preload_target_die, tex));
tex-targets = eina_list_append(tex-targets, target);
@@ -420,6 +422,8 @@ evas_gl_preload_target_unregister(Evas_GL_Texture *tex, Eo
*target)
Eina_List *l;
const Eo *o;
+ EINA_SAFETY_ON_NULL_RETURN(tex);
+
eo_do(target,
eo_event_callback_del(EO_EV_DEL, _evas_gl_preload_target_die, tex));
--
[EGIT] [core/efl] master 02/02: Evas/cserve2: Fix crash during shutdown
jpeg pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=b10dcb5c2366c135bbae014d084b07f039b34fde
commit b10dcb5c2366c135bbae014d084b07f039b34fde
Author: Jean-Philippe Andre jp.an...@samsung.com
Date: Mon Dec 9 17:48:32 2013 +0900
Evas/cserve2: Fix crash during shutdown
If an image failed to load, and cserve2 returned an error message,
then the File_Entry was freed, but not removed from the hash.
Solution: remove entry from the hash, let the callback free the data.
---
src/lib/evas/cserve2/evas_cs2_client.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/src/lib/evas/cserve2/evas_cs2_client.c
b/src/lib/evas/cserve2/evas_cs2_client.c
index c5ef594..c65003f 100644
--- a/src/lib/evas/cserve2/evas_cs2_client.c
+++ b/src/lib/evas/cserve2/evas_cs2_client.c
@@ -690,8 +690,9 @@ _image_opened_cb(void *data, const void *msg_received, int
size)
}
ie-open_rid = 0;
- if (answer-type != CSERVE2_OPENED)
+ if ((answer-type != CSERVE2_OPENED) || (size (int) sizeof(*msg)))
{
+File_Entry *fentry = ie-data1;
if (answer-type == CSERVE2_ERROR)
{
const Msg_Error *msg_error = msg_received;
@@ -700,15 +701,9 @@ _image_opened_cb(void *data, const void *msg_received, int
size)
}
else
ERR(Invalid message type received: %d (%s), answer-type,
__FUNCTION__);
-free(ie-data1);
-ie-data1 = NULL;
-return EINA_TRUE;
- }
- else if (size (int) sizeof(*msg))
- {
-ERR(Received message is too small);
-free(ie-data1);
-ie-data1 = NULL;
+fentry = ie-data1;
+EINA_REFCOUNT_UNREF(fentry)
+ eina_hash_del(_file_entries, fentry-hkey, fentry);
return EINA_TRUE;
}
--
[EGIT] [core/efl] efl-1.8 01/02: Evas: Fix crash in GL engine(s) during preload cancel
jpeg pushed a commit to branch efl-1.8.
http://git.enlightenment.org/core/efl.git/commit/?id=e3c612f4b253ebb07a56e454adcf277db2266590
commit e3c612f4b253ebb07a56e454adcf277db2266590
Author: Jean-Philippe Andre jp.an...@samsung.com
Date: Mon Dec 9 17:28:02 2013 +0900
Evas: Fix crash in GL engine(s) during preload cancel
In my config, running terminology with the GL engine and under
cserve2, some image could not be loaded. The tex argument
in evas_gl_preload_target_[un]register was NULL, leading to
an immediate crash.
---
src/modules/evas/engines/gl_common/evas_gl_preload.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/modules/evas/engines/gl_common/evas_gl_preload.c
b/src/modules/evas/engines/gl_common/evas_gl_preload.c
index fee5823..1995232 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_preload.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_preload.c
@@ -408,6 +408,8 @@ _evas_gl_preload_target_die(void *data, Eo *obj,
void
evas_gl_preload_target_register(Evas_GL_Texture *tex, Eo *target)
{
+ EINA_SAFETY_ON_NULL_RETURN(tex);
+
eo_do(target,
eo_event_callback_add(EO_EV_DEL, _evas_gl_preload_target_die, tex));
tex-targets = eina_list_append(tex-targets, target);
@@ -420,6 +422,8 @@ evas_gl_preload_target_unregister(Evas_GL_Texture *tex, Eo
*target)
Eina_List *l;
const Eo *o;
+ EINA_SAFETY_ON_NULL_RETURN(tex);
+
eo_do(target,
eo_event_callback_del(EO_EV_DEL, _evas_gl_preload_target_die, tex));
--
[EGIT] [core/efl] efl-1.8 02/02: Evas/cserve2: Fix crash during shutdown
jpeg pushed a commit to branch efl-1.8.
http://git.enlightenment.org/core/efl.git/commit/?id=13cb9e18f497360f7d83c4b7eb55d936930bff09
commit 13cb9e18f497360f7d83c4b7eb55d936930bff09
Author: Jean-Philippe Andre jp.an...@samsung.com
Date: Mon Dec 9 17:48:32 2013 +0900
Evas/cserve2: Fix crash during shutdown
If an image failed to load, and cserve2 returned an error message,
then the File_Entry was freed, but not removed from the hash.
Solution: remove entry from the hash, let the callback free the data.
---
src/lib/evas/cserve2/evas_cs2_client.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/src/lib/evas/cserve2/evas_cs2_client.c
b/src/lib/evas/cserve2/evas_cs2_client.c
index c5ef594..c65003f 100644
--- a/src/lib/evas/cserve2/evas_cs2_client.c
+++ b/src/lib/evas/cserve2/evas_cs2_client.c
@@ -690,8 +690,9 @@ _image_opened_cb(void *data, const void *msg_received, int
size)
}
ie-open_rid = 0;
- if (answer-type != CSERVE2_OPENED)
+ if ((answer-type != CSERVE2_OPENED) || (size (int) sizeof(*msg)))
{
+File_Entry *fentry = ie-data1;
if (answer-type == CSERVE2_ERROR)
{
const Msg_Error *msg_error = msg_received;
@@ -700,15 +701,9 @@ _image_opened_cb(void *data, const void *msg_received, int
size)
}
else
ERR(Invalid message type received: %d (%s), answer-type,
__FUNCTION__);
-free(ie-data1);
-ie-data1 = NULL;
-return EINA_TRUE;
- }
- else if (size (int) sizeof(*msg))
- {
-ERR(Received message is too small);
-free(ie-data1);
-ie-data1 = NULL;
+fentry = ie-data1;
+EINA_REFCOUNT_UNREF(fentry)
+ eina_hash_del(_file_entries, fentry-hkey, fentry);
return EINA_TRUE;
}
--
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
Hello. On Mon, 2013-12-09 at 08:12, Stefan Schmidt wrote: On Sun, 2013-12-08 at 16:32, Jeff Hoogland wrote: E18 rc1 doesn't appear to build here: CC temperature/tempget.o CCLD temperature/tempget make[4]: *** No rule to make target `physics/e-module-physics.edj', needed by `all-am'. Stop. make[4]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src/modules' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src/modules' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1' make: *** [all] Error 2 Interesting. Do you have --disable-ephysics or --disable-physics in your configure? I tried various things here but I'm not able to reproduce it. I would need more information about your build setup. Is anyone else seeing this? regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Weekly news from the automated build and QA front
Hello. Summary: o Builds for 1.8.x stable branches. Running on every commit to the stable branches for efl and elementary This should give everyone an overview over what has happened in the last week on the QA front. The numbers in parentheses reflect the values from last week to give you a trend. CI: o Overall build statistic: 4.39% (4.18%) failed. https://build.enlightenment.org/ clang scan-build: o EFL scan-build reports 485 (493) issues. https://build.enlightenment.org/job/nightly_efl_clang_x86_64/lastSuccessfu lBuild/artifact/scan-build/build/ Exactness: o The edje exactness builds are working now. Elm exactness still failing. o Problems with icons and paths (file selector widget) o Still waiting for the first successful run on jenkins Unit tests: o 282 (279) unit tests for efl and none failing Coverage: o EFL total coverage is at 26.2% (26.1%) lines and 28.9% (28.9%) functions https://build.enlightenment.org/view/Test%20Coverage/ Coverity: o EFL: Outstanding defects 413 (416) with a density of 0.70 (0.71) o Elm: Outstanding defects 25 (26) with a density of 0.11 (0.12) o E: Outstanding defects 191 (205) with a density of 0.69 (0.74) o Terminology: Outstanding defects 10 (10) with a density of 0.15 (0.15) Phab: o Total bug count: 167 (154) o Pending patch reviews: 15 (15) If anybody wants to see something added here let me know and be my guest. regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: fix seb fix commit that causes lots of segvs.
raster pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=82841fefe30df6a406cf549db60daf806c5f10eb
commit 82841fefe30df6a406cf549db60daf806c5f10eb
Author: Carsten Haitzler (Rasterman) ras...@rasterman.com
Date: Mon Dec 9 18:39:07 2013 +0900
fix seb fix commit that causes lots of segvs.
this fixes 04e0a6d95ec5610e35fe9b1be1a361f177ae which introduced
copy paste segv's by properly terminating the right buffer.
---
doc/images.mk| 2 +-
src/lib/ecore_x/xlib/ecore_x_selection.c | 12 +---
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/doc/images.mk b/doc/images.mk
index b2d8045..20d8d63 100644
--- a/doc/images.mk
+++ b/doc/images.mk
@@ -1,2 +1,2 @@
EXTRA_DIST += \
-img/01_hash-table.eps img/01_hash-table.png img/alignment-hints.eps
img/alignment-hints.png img/any-policy.eps img/any-policy.png
img/aspect-control-both.eps img/aspect-control-both.png
img/aspect-control-horizontal.eps img/aspect-control-horizontal.png
img/aspect-control-none-neither.eps img/aspect-control-none-neither.png
img/b1.png img/b2.png img/b3.png img/b4.png img/b5.png img/b6.png img/b7.png
img/b8.png img/b9.png img/basic2final.eps img/basic2final.png
img/border-effect.eps img/b [...]
+img/01_hash-table.eps img/01_hash-table.png img/alignment-hints.eps
img/alignment-hints.png img/any-policy.eps img/any-policy.png
img/aspect-control-both.eps img/aspect-control-both.png
img/aspect-control-horizontal.eps img/aspect-control-horizontal.png
img/aspect-control-none-neither.eps img/aspect-control-none-neither.png
img/b1.png img/b2.png img/b3.png img/b4.png img/b5.png img/b6.png img/b7.png
img/b8.png img/b9.png img/basic2final.eps img/basic2final.png
img/border-effect.eps img/b [...]
diff --git a/src/lib/ecore_x/xlib/ecore_x_selection.c
b/src/lib/ecore_x/xlib/ecore_x_selection.c
index 0bbd601..13a24fc 100644
--- a/src/lib/ecore_x/xlib/ecore_x_selection.c
+++ b/src/lib/ecore_x/xlib/ecore_x_selection.c
@@ -599,13 +599,11 @@ ecore_x_selection_converter_text(char *target,
text_prop) == Success)
{
int bufsize = strlen((char *)text_prop.value);
-*data_ret = malloc(bufsize + 1);
-if (!*data_ret)
- {
- return EINA_FALSE;
- }
-memcpy(*data_ret, text_prop.value, bufsize);
-((char **)data_ret)[bufsize] = 0;
+char *s = malloc(bufsize + 1);
+if (!s) return EINA_FALSE;
+*data_ret = s;
+memcpy(s, text_prop.value, bufsize);
+s[bufsize] = 0;
*size_ret = bufsize;
XFree(text_prop.value);
return EINA_TRUE;
--
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On 12/09/2013 05:40 PM, Stefan Schmidt wrote: Hello. On Sun, 2013-12-08 at 14:58, Jeff Hoogland wrote: Just wanted to confirm emotion generic players isn't getting a 1.8.1 release. Confirmed. Emotion generic players had not a single commit since 1.8.0. Nothing to release. regards Stefan Schmidt From a packagers perspective it would be great if we could keep the efl, elementary and evas/emotion_generic_loaders version numbers the same even if there are no changes, the same as we did for the 1.7 tree. I'll leave it for you guys to decide though. Cheers, Simon -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
Hello. On Mon, 2013-12-09 at 20:05, Simon wrote: On 12/09/2013 05:40 PM, Stefan Schmidt wrote: Hello. On Sun, 2013-12-08 at 14:58, Jeff Hoogland wrote: Just wanted to confirm emotion generic players isn't getting a 1.8.1 release. Confirmed. Emotion generic players had not a single commit since 1.8.0. Nothing to release. regards Stefan Schmidt From a packagers perspective it would be great if we could keep the efl, elementary and evas/emotion_generic_loaders version numbers the same even if there are no changes, the same as we did for the 1.7 tree. I'll leave it for you guys to decide though. I was pondering about that. For 1.7.x we had way more tarballs for one release. Due to the merged efl tree this really got down. Would you expect emotion generic player release tarballs for 1.8.1 and 1.8.2 even when not a single commit hit that repo? We can switch back to that model but I'm not a fan of doing empty releases just to stay in sync for the version number. It would only heppen from 1.8.3 though. Skipping a minor release for everything but efl. IT will always be out of sync with e18 in any case. In sumarry I have no hard feeling in any direction. :) regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On 12/09/2013 08:33 PM, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 20:05, Simon wrote: On 12/09/2013 05:40 PM, Stefan Schmidt wrote: Hello. On Sun, 2013-12-08 at 14:58, Jeff Hoogland wrote: Just wanted to confirm emotion generic players isn't getting a 1.8.1 release. Confirmed. Emotion generic players had not a single commit since 1.8.0. Nothing to release. regards Stefan Schmidt From a packagers perspective it would be great if we could keep the efl, elementary and evas/emotion_generic_loaders version numbers the same even if there are no changes, the same as we did for the 1.7 tree. I'll leave it for you guys to decide though. I was pondering about that. For 1.7.x we had way more tarballs for one release. Due to the merged efl tree this really got down. Would you expect emotion generic player release tarballs for 1.8.1 and 1.8.2 even when not a single commit hit that repo? We can switch back to that model but I'm not a fan of doing empty releases just to stay in sync for the version number. It would only heppen from 1.8.3 though. Skipping a minor release for everything but efl. IT will always be out of sync with e18 in any case. In sumarry I have no hard feeling in any direction. :) regards Stefan Schmidt I wasn't much of a fan of the empty releases at first either, but realistic the enlightenment foundation libraries are efl, elementary and e*_generic_loaders, its just some components are built separately because its easier and others due to licensing. From a user perspective particularly in regards to filing bugs it makes it easier if they all follow the same versioning, especially if efl and elementary are out of sync. I understand and treat Enlightenment as a different thing and that i understand. Cheers Simon -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: When changing the gravity setting, one cannot reset it to 0, as the setting is not properly shown when reopening the dialog. It's always shown a
Awful commit message format. Doesn't follow our (git's) conventions.
--
Tom.
On 29/11/13 23:19, Olaf Conradi wrote:
discomfitor pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=39a986aace0f0f2d0b4bacfa80fc5a951254aa68
commit 39a986aace0f0f2d0b4bacfa80fc5a951254aa68
Author: Olaf Conradi o...@conradi.org
Date: Fri Nov 29 18:15:25 2013 -0500
When changing the gravity setting, one cannot reset it to 0, as the
setting is
not properly shown when reopening the dialog. It's always shown as 0 and
therefore not saveable.
---
src/modules/physics/e_mod_config.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/modules/physics/e_mod_config.c
b/src/modules/physics/e_mod_config.c
index c2dbc44..ace03a9 100644
--- a/src/modules/physics/e_mod_config.c
+++ b/src/modules/physics/e_mod_config.c
@@ -6,7 +6,7 @@ struct _E_Config_Dialog_Data
{
double delay; /* delay before applying physics */
double max_mass; /* maximum mass for a window */
- double gravity; /* maximum mass for a window */
+ double gravity; /* gravity for a window */
Eina_Bool ignore_fullscreen;
Eina_Bool ignore_maximized;
Eina_Bool ignore_shelves;
@@ -58,6 +58,7 @@ _create_data(E_Config_Dialog *cfd __UNUSED__)
cfdata-delay = _physics_mod-conf-delay;
cfdata-max_mass = _physics_mod-conf-max_mass;
+ cfdata-gravity = _physics_mod-conf-gravity;
return cfdata;
}
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Exquisite source code
On 01/12/13 19:00, Thanatermesis wrote: Exquisite was a very nice app, seems like it was only SVN but now I don't found it, can we have it back on GIT ? Sure. Will try to do soon. I have some backlog. :) -- Tom. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/enlightenment] master 01/01: gdb crashdump - restore old e_sys magic into e_start
raster pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=0ec99b2ac553809b57993b34de3228b2380b34c2
commit 0ec99b2ac553809b57993b34de3228b2380b34c2
Author: Carsten Haitzler (Rasterman) ras...@rasterman.com
Date: Mon Dec 9 19:51:24 2013 +0900
gdb crashdump - restore old e_sys magic into e_start
---
src/bin/e_start_main.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/bin/e_start_main.c b/src/bin/e_start_main.c
index 22994de..22af23d 100644
--- a/src/bin/e_start_main.c
+++ b/src/bin/e_start_main.c
@@ -566,8 +566,13 @@ main(int argc, char **argv)
if (home)
{
/* call e_sys gdb */
- snprintf(buffer, 4096,
- gdb %i %s/.e-crashdump.txt,
+ snprintf(buffer, sizeof(buffer),
+ gdb
+ --pid=%i
+ -batch
+ -ex 'set logging file
%s/.e-crashdump.txt'
+ -ex 'thread apply all backtrace
full'
+ -ex detach /dev/null 21
/dev/zero,
child,
home);
r = system(buffer);
--
[EGIT] [core/efl] master 01/01: ecore_evas/wayland: Update withdrawn property, and inform state_changed.
antognolli pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=cb3fcca0e7f6af0dd095a0ea5ec0f2360ab4269d
commit cb3fcca0e7f6af0dd095a0ea5ec0f2360ab4269d
Author: Rafael Antognolli rafael.antogno...@intel.com
Date: Wed Dec 4 18:50:19 2013 -0200
ecore_evas/wayland: Update withdrawn property, and inform state_changed.
---
src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
index 8c02856..2d03700 100644
--- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
+++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
@@ -1484,10 +1484,17 @@ _ecore_evas_wl_common_withdrawn_set(Ecore_Evas *ee, int
val)
{
LOGFN(__FILE__, __LINE__, __FUNCTION__);
+ val = !!val;
+
+ if (ee-prop.withdrawn == val)
+ return;
+
+ ee-prop.withdrawn = val;
if (val)
ecore_evas_hide(ee);
else
ecore_evas_show(ee);
+ _ecore_evas_wl_common_state_update(ee);
}
void
--
[EGIT] [core/efl] efl-1.8 01/01: ecore_evas/wayland: Update withdrawn property, and inform state_changed.
antognolli pushed a commit to branch efl-1.8.
http://git.enlightenment.org/core/efl.git/commit/?id=f34a8c639c717d9c26d90ece58403dad27cb635a
commit f34a8c639c717d9c26d90ece58403dad27cb635a
Author: Rafael Antognolli rafael.antogno...@intel.com
Date: Wed Dec 4 18:50:19 2013 -0200
ecore_evas/wayland: Update withdrawn property, and inform state_changed.
---
src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
index d6f2272..c5b04fb 100644
--- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
+++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
@@ -1482,10 +1482,17 @@ _ecore_evas_wl_common_withdrawn_set(Ecore_Evas *ee, int
val)
{
LOGFN(__FILE__, __LINE__, __FUNCTION__);
+ val = !!val;
+
+ if (ee-prop.withdrawn == val)
+ return;
+
+ ee-prop.withdrawn = val;
if (val)
ecore_evas_hide(ee);
else
ecore_evas_show(ee);
+ _ecore_evas_wl_common_state_update(ee);
}
void
--
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
From a packagers perspective it would be great if we could keep the efl, elementary and evas/emotion_generic_loaders version numbers the same even if there are no changes, the same as we did for the 1.7 tree. I'll leave it for you guys to decide though. + 1 2013/12/9 Simon si...@simotek.net On 12/09/2013 08:33 PM, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 20:05, Simon wrote: On 12/09/2013 05:40 PM, Stefan Schmidt wrote: Hello. On Sun, 2013-12-08 at 14:58, Jeff Hoogland wrote: Just wanted to confirm emotion generic players isn't getting a 1.8.1 release. Confirmed. Emotion generic players had not a single commit since 1.8.0. Nothing to release. regards Stefan Schmidt From a packagers perspective it would be great if we could keep the efl, elementary and evas/emotion_generic_loaders version numbers the same even if there are no changes, the same as we did for the 1.7 tree. I'll leave it for you guys to decide though. I was pondering about that. For 1.7.x we had way more tarballs for one release. Due to the merged efl tree this really got down. Would you expect emotion generic player release tarballs for 1.8.1 and 1.8.2 even when not a single commit hit that repo? We can switch back to that model but I'm not a fan of doing empty releases just to stay in sync for the version number. It would only heppen from 1.8.3 though. Skipping a minor release for everything but efl. IT will always be out of sync with e18 in any case. In sumarry I have no hard feeling in any direction. :) regards Stefan Schmidt I wasn't much of a fan of the empty releases at first either, but realistic the enlightenment foundation libraries are efl, elementary and e*_generic_loaders, its just some components are built separately because its easier and others due to licensing. From a user perspective particularly in regards to filing bugs it makes it easier if they all follow the same versioning, especially if efl and elementary are out of sync. I understand and treat Enlightenment as a different thing and that i understand. Cheers Simon -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/enlightenment] master 01/01: comp - remove sync support in comp - it should be off by default anyway.
raster pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=835a3dfac6c3b6ea209c71e8771467e65e956969
commit 835a3dfac6c3b6ea209c71e8771467e65e956969
Author: Carsten Haitzler (Rasterman) ras...@rasterman.com
Date: Mon Dec 9 20:43:35 2013 +0900
comp - remove sync support in comp - it should be off by default anyway.
this was never a great idea, and it has too many buglets in corner
cases (eg window resizing) so remove it. simpler is better.
---
src/bin/e_comp.c | 312 ++-
src/bin/e_comp.h | 1 -
src/bin/e_comp_cfdata.c | 4 -
src/bin/e_comp_cfdata.h | 2 -
src/modules/conf_comp/e_mod_config.c | 16 --
5 files changed, 16 insertions(+), 319 deletions(-)
diff --git a/src/bin/e_comp.c b/src/bin/e_comp.c
index 6315d25..00bdc81 100644
--- a/src/bin/e_comp.c
+++ b/src/bin/e_comp.c
@@ -512,7 +512,6 @@ _e_comp_win_ready_timeout_setup(E_Comp_Win *cw)
cw-ready_timeout = NULL;
}
if (cw-show_ready) return;
- if (cw-counter) return;
// FIXME: make show_ready option
if (0)
{
@@ -1199,14 +1198,6 @@ _e_comp_cb_nocomp_begin(E_Comp *c)
cw-update = 0;
cw-c-updates = eina_list_remove(cw-c-updates, cw);
}
- if (cw-counter)
- {
-if (cw-bd)
- ecore_x_e_comp_sync_cancel_send(cw-bd-client.win);
-else
- ecore_x_e_comp_sync_cancel_send(cw-win);
-ecore_x_sync_counter_inc(cw-counter, 1);
- }
DBG(JOB2...);
_e_comp_render_queue(c);
}
@@ -1257,13 +1248,6 @@ _e_comp_cb_nocomp_end(E_Comp *c)
_e_comp_event_source_visibility(cw);
// no need for effect
}
-if (cw-counter)
- {
- if (cw-bd)
- ecore_x_e_comp_sync_begin_send(cw-bd-client.win);
- else
- ecore_x_e_comp_sync_begin_send(cw-win);
- }
}
}
@@ -1286,7 +1270,6 @@ _e_comp_cb_update(E_Comp *c)
{
E_Comp_Win *cw;
Eina_List *new_updates = NULL; // for failed pixmap fetches - get them next
frame
- Eina_List *update_done = NULL;
// static int doframeinfo = -1;
if (!c) return EINA_FALSE;
@@ -1301,22 +1284,7 @@ _e_comp_cb_update(E_Comp *c)
}
EINA_LIST_FREE(c-updates, cw)
{
-if (conf-efl_sync)
- {
- if (((cw-counter) (cw-drawme)) || (!cw-counter))
- {
- _e_comp_win_update(cw);
- if (cw-drawme)
-{
- update_done = eina_list_append(update_done, cw);
- cw-drawme = 0;
-}
- }
- else
- cw-update = 0;
- }
-else
- _e_comp_win_update(cw);
+_e_comp_win_update(cw);
if (cw-update)
{
new_updates = eina_list_append(new_updates, cw);
@@ -1389,13 +1357,6 @@ _e_comp_cb_update(E_Comp *c)
DBG(MANUAL RENDER...);
//if (!c-nocomp) ecore_evas_manual_render(c-ee);
}
- if (conf-efl_sync)
- {
-EINA_LIST_FREE(update_done, cw)
- {
- ecore_x_sync_counter_inc(cw-counter, 1);
- }
- }
if (conf-grab)
{
if (c-grabbed)
@@ -1588,27 +1549,6 @@ _e_comp_win_do_shadow(E_Comp_Win *cw)
return 1;
}
-static Eina_Bool
-_e_comp_win_damage_timeout(void *data)
-{
- E_Comp_Win *cw = data;
-
- if (!cw-update)
- {
-if (cw-update_timeout)
- {
- ecore_timer_del(cw-update_timeout);
- cw-update_timeout = NULL;
- }
-cw-update = 1;
-cw-c-updates = eina_list_append(cw-c-updates, cw);
- }
- cw-drawme = 1;
- _e_comp_win_render_queue(cw);
- cw-update_timeout = NULL;
- return ECORE_CALLBACK_CANCEL;
-}
-
static void
_e_comp_object_del(void *data, void *obj)
{
@@ -1619,20 +1559,10 @@ _e_comp_object_del(void *data, void *obj)
_e_comp_win_render_queue(cw);
if (obj == cw-bd)
{
-if (cw-counter)
- {
- if (cw-bd)
- ecore_x_e_comp_sync_cancel_send(cw-bd-client.win);
- else
- ecore_x_e_comp_sync_cancel_send(cw-win);
- ecore_x_sync_counter_inc(cw-counter, 1);
- }
if (cw-bd) eina_hash_del(borders,
e_util_winid_str_get(cw-bd-client.win), cw);
cw-bd-cw = NULL;
cw-bd = NULL;
evas_object_data_del(cw-shobj, border);
-// hmm - lockup?
-//cw-counter = 0;
}
else if (obj == cw-pop)
{
@@ -1699,28 +1629,6 @@ _e_comp_hide_done(void *data, Evas_Object *obj
EINA_UNUSED, const char *emission
}
static void
-_e_comp_win_sync_setup(E_Comp_Win *cw, Ecore_X_Window win)
-{
- if (!conf-efl_sync) return;
-
- if (cw-bd)
- {
-if (_e_comp_win_is_borderless(cw) ||
-(conf-loose_sync))
[EGIT] [core/enlightenment] master 01/01: improve efm popup display with multiple monitors
discomfitor pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=400f966b70dbc3529bcf4a2188340e0b2dfe9d40 commit 400f966b70dbc3529bcf4a2188340e0b2dfe9d40 Author: Mike Blumenkrantz zm...@samsung.com Date: Mon Dec 9 07:26:33 2013 -0500 improve efm popup display with multiple monitors previously we'd clamp to the current screen, but that's not really necessary. also e_popup sucks, so trying to create zone-relative coords is not going to work - just use first zone always --- src/modules/fileman/e_fwin.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/modules/fileman/e_fwin.c b/src/modules/fileman/e_fwin.c index f43479c..ca7bf16 100644 --- a/src/modules/fileman/e_fwin.c +++ b/src/modules/fileman/e_fwin.c @@ -819,8 +819,8 @@ _e_fwin_icon_popup(void *data) y -= fwin-zone-y; } else - fx = fwin-win-x, fy = fwin-win-y; - fwin-popup = e_popup_new(zone, 0, 0, 1, 1); + fx = fwin-win-border-x, fy = fwin-win-border-y; + fwin-popup = e_popup_new(eina_list_data_get(zone-container-zones), 0, 0, 1, 1); e_popup_ignore_events_set(fwin-popup, 1); bg = edje_object_add(fwin-popup-evas); @@ -850,7 +850,7 @@ _e_fwin_icon_popup(void *data) /* if it's offscreen, try right of icon */ if (px 0) px = (fx + x + w) + 3; /* fuck this, stick it right on the icon */ - if (px + mw + 3 zone-w) + if ((px + mw + 3 zone-x + zone-w) (!e_zone_exists_direction(zone, E_ZONE_EDGE_RIGHT))) px = (x + w / 2) - (mw / 2); /* give up */ if (px 0) px = 0; @@ -860,7 +860,7 @@ _e_fwin_icon_popup(void *data) /* if it's offscreen, try below icon */ if (py 0) py = (fy + y + h) + 3; /* fuck this, stick it right on the icon */ - if (py + mh + 3 zone-h) + if ((py + mh + 3 zone-x + zone-h) (!e_zone_exists_direction(zone, E_ZONE_EDGE_BOTTOM))) py = (y + h / 2) - (mh / 2); /* give up */ if (py 0) py = 0; --
[EGIT] [core/efl] master 01/01: autotools: work around buggy macro to force C++ compiler detection.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=6f50fc9d63f9448d87e14e954d28e0f7a6bd3fd3
commit 6f50fc9d63f9448d87e14e954d28e0f7a6bd3fd3
Author: Cedric Bail cedric.b...@samsung.com
Date: Mon Dec 9 21:35:56 2013 +0900
autotools: work around buggy macro to force C++ compiler detection.
---
configure.ac | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 3c70192..edc1207 100644
--- a/configure.ac
+++ b/configure.ac
@@ -283,7 +283,11 @@ AM_PROG_CC_C_O
if test x${ac_cv_prog_cc_c99} = xno ; then
AC_MSG_ERROR([efl requires a c99-capable compiler])
fi
-if test x${CXX} = x; then
+# We should be using ${CXX} here, but there is a bug in
+# autotools macro and CXX is always set to g++ even if
+# it's not found. So we are using an internal variable
+# that does the work for now, may get broken in the future.
+if test x${ac_ct_CXX} = x; then
AC_MSG_ERROR([efl requires a C++ compiler])
fi
--
[EGIT] [core/efl] efl-1.8 01/01: autotools: work around buggy macro to force C++ compiler detection.
cedric pushed a commit to branch efl-1.8.
http://git.enlightenment.org/core/efl.git/commit/?id=1fa0821e4f9f61c8172eb047596a2b2bc5dd2b50
commit 1fa0821e4f9f61c8172eb047596a2b2bc5dd2b50
Author: Cedric Bail cedric.b...@samsung.com
Date: Mon Dec 9 21:35:56 2013 +0900
autotools: work around buggy macro to force C++ compiler detection.
---
configure.ac | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index ef6c80d..8d3a383 100644
--- a/configure.ac
+++ b/configure.ac
@@ -283,7 +283,11 @@ AM_PROG_CC_C_O
if test x${ac_cv_prog_cc_c99} = xno ; then
AC_MSG_ERROR([efl requires a c99-capable compiler])
fi
-if test x${CXX} = x; then
+# We should be using ${CXX} here, but there is a bug in
+# autotools macro and CXX is always set to g++ even if
+# it's not found. So we are using an internal variable
+# that does the work for now, may get broken in the future.
+if test x${ac_ct_CXX} = x; then
AC_MSG_ERROR([efl requires a C++ compiler])
fi
--
[EGIT] [core/enlightenment] master 01/01: backlight - save after actions change backlight too.
raster pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=9ce8d91f6d54afac67f7653700205ee24206e3a2 commit 9ce8d91f6d54afac67f7653700205ee24206e3a2 Author: Carsten Haitzler (Rasterman) ras...@rasterman.com Date: Mon Dec 9 21:52:18 2013 +0900 backlight - save after actions change backlight too. --- src/bin/e_actions.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/bin/e_actions.c b/src/bin/e_actions.c index e9d45a2..182dd19 100644 --- a/src/bin/e_actions.c +++ b/src/bin/e_actions.c @@ -2855,6 +2855,7 @@ ACT_FN_GO(backlight_set, ) } e_backlight_mode_set(zone, E_BACKLIGHT_MODE_NORMAL); e_backlight_level_set(zone, ((double)v / 100.0), -1.0); + e_config_save_queue(); } ACT_FN_GO(backlight_adjust, ) @@ -2865,6 +2866,7 @@ ACT_FN_GO(backlight_adjust, ) v = atoi(params); e_backlight_mode_set(zone, E_BACKLIGHT_MODE_NORMAL); e_backlight_level_set(zone, e_backlight_level_get(zone) + ((double)v / 100.0), -1.0); + e_config_save_queue(); } ACT_FN_GO(kbd_layout, ) --
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
[ 175s] make[4]: *** No rule to make target `physics/e-module-physics.edj', needed by `all-am'. Stop. On 12/09/2013 09:02 AM, Jeff Hoogland wrote: E18 rc1 doesn't appear to build here: CC temperature/tempget.o CCLD temperature/tempget make[4]: *** No rule to make target `physics/e-module-physics.edj', needed by `all-am'. Stop. make[4]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src/modules' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src/modules' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1' make: *** [all] Error 2 Same error here, make[4]: *** No rule to make target 'physics/e-module-physics.edj', needed by 'all-am'. Stop. https://build.opensuse.org/package/live_build_log/X11:Enlightenment:Factory/enlightenment/openSUSE_13.1/x86_64 I have physics enabled in the efl and enlightenment is built with no configure flags passed. alpha4 worked fine On Sun, Dec 8, 2013 at 2:58 PM, Jeff Hoogland jeffhoogl...@linux.comwrote: Just wanted to confirm emotion generic players isn't getting a 1.8.1 release. On Sun, Dec 8, 2013 at 2:32 PM, Stefan Schmidt ste...@datenfreihafen.orgwrote: Hello. On Fri, 2013-12-06 at 12:35, Stefan Schmidt wrote: On Thu, 2013-12-05 at 08:55, Stefan Schmidt wrote: On Thu, 2013-12-05 at 08:53, Stefan Schmidt wrote: Hello. [Now CC'ed to enlightenment-release] Everybody could see that this was a lie but is true now... On Wed, 2013-12-04 at 14:44, Stefan Schmidt wrote: It seems all 1.8 branches have accumulated enough fixes already to allow for a 1.8.x release on Friday. If you have backported your _tested_ important fixes to the stable branch consider yourself a good person. If know anything else that needs backporting please do so by Thursday evening. I don't want last minutes commits just a second before the release. This needs to be adapted slightly. As Mike pointed out we have a policy for having the tarballs around for 24h to allow testing before doing the final announce. This is a really good thing so I plan to stick with it. Adaption to my current plan would be that I prepare the tarballs and everythign on Friday evening European time and allow for testing until Sunday (I'm off Saturday) and if the tarball have been fine do the announcement on Sunday. Due to laptop and hard disk dieing I have to move this forward a bit. I really need the time to recover. Tarballs for testing should be out on Sunday evening and release announcement 24h later if nothing problematic comes up. On the good side we will have an e18-rc1 together with these. In the spirit of all the other releases I also pushed out the TESTING tarballs for efl, elm evas_generic_loaders and e18. While efl, elm and evas_generic loaders are stable releases e18 gets his first release candidate together with them. THIS MIGHT NOT BE THE FINAL TARBALLS. Please test them and let me know any problems. If nothing shows I will make them final in 24h. http://download.enlightenment.org/rel/libs/efl/efl-1.8.2.tar.gz http://download.enlightenment.org/rel/libs/evas_generic_loaders/evas_generic_loaders-1.8.1.tar.gz http://download.enlightenment.org/rel/libs/elementary/elementary-1.8.1.tar.gz http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.18.0-rc1.tar.gz Happy testing. regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ~Jeff Hoogland http://jeffhoogland.com/ Thoughts on Technology http://jeffhoogland.blogspot.com/, Tech Blog Bodhi Linux http://bodhilinux.com/, Enlightenment for your Desktop -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
there haven't been any changes to this in months, so it's definitely something on your systems. On Mon, 09 Dec 2013 23:26:27 +1030 Simon si...@simotek.net wrote: [ 175s] make[4]: *** No rule to make target `physics/e-module-physics.edj', needed by `all-am'. Stop. On 12/09/2013 09:02 AM, Jeff Hoogland wrote: E18 rc1 doesn't appear to build here: CC temperature/tempget.o CCLD temperature/tempget make[4]: *** No rule to make target `physics/e-module-physics.edj', needed by `all-am'. Stop. make[4]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src/modules' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src/modules' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1' make: *** [all] Error 2 Same error here, make[4]: *** No rule to make target 'physics/e-module-physics.edj', needed by 'all-am'. Stop. https://build.opensuse.org/package/live_build_log/X11:Enlightenment:Factory/enlightenment/openSUSE_13.1/x86_64 I have physics enabled in the efl and enlightenment is built with no configure flags passed. alpha4 worked fine On Sun, Dec 8, 2013 at 2:58 PM, Jeff Hoogland jeffhoogl...@linux.comwrote: Just wanted to confirm emotion generic players isn't getting a 1.8.1 release. On Sun, Dec 8, 2013 at 2:32 PM, Stefan Schmidt ste...@datenfreihafen.orgwrote: Hello. On Fri, 2013-12-06 at 12:35, Stefan Schmidt wrote: On Thu, 2013-12-05 at 08:55, Stefan Schmidt wrote: On Thu, 2013-12-05 at 08:53, Stefan Schmidt wrote: Hello. [Now CC'ed to enlightenment-release] Everybody could see that this was a lie but is true now... On Wed, 2013-12-04 at 14:44, Stefan Schmidt wrote: It seems all 1.8 branches have accumulated enough fixes already to allow for a 1.8.x release on Friday. If you have backported your _tested_ important fixes to the stable branch consider yourself a good person. If know anything else that needs backporting please do so by Thursday evening. I don't want last minutes commits just a second before the release. This needs to be adapted slightly. As Mike pointed out we have a policy for having the tarballs around for 24h to allow testing before doing the final announce. This is a really good thing so I plan to stick with it. Adaption to my current plan would be that I prepare the tarballs and everythign on Friday evening European time and allow for testing until Sunday (I'm off Saturday) and if the tarball have been fine do the announcement on Sunday. Due to laptop and hard disk dieing I have to move this forward a bit. I really need the time to recover. Tarballs for testing should be out on Sunday evening and release announcement 24h later if nothing problematic comes up. On the good side we will have an e18-rc1 together with these. In the spirit of all the other releases I also pushed out the TESTING tarballs for efl, elm evas_generic_loaders and e18. While efl, elm and evas_generic loaders are stable releases e18 gets his first release candidate together with them. THIS MIGHT NOT BE THE FINAL TARBALLS. Please test them and let me know any problems. If nothing shows I will make them final in 24h. http://download.enlightenment.org/rel/libs/efl/efl-1.8.2.tar.gz http://download.enlightenment.org/rel/libs/evas_generic_loaders/evas_generic_loaders-1.8.1.tar.gz http://download.enlightenment.org/rel/libs/elementary/elementary-1.8.1.tar.gz http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.18.0-rc1.tar.gz Happy testing. regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ~Jeff Hoogland http://jeffhoogland.com/ Thoughts on Technology http://jeffhoogland.blogspot.com/, Tech Blog Bodhi Linux http://bodhilinux.com/, Enlightenment for your Desktop -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On 12/09/2013 11:32 PM, Michael Blumenkrantz wrote: there haven't been any changes to this in months, so it's definitely something on your systems. someone hasn't changed autofooness? the only thing that changed in our build system is efl 1.8.2 instead of 1.8.1 On Mon, 09 Dec 2013 23:26:27 +1030 Simon si...@simotek.net wrote: [ 175s] make[4]: *** No rule to make target `physics/e-module-physics.edj', needed by `all-am'. Stop. On 12/09/2013 09:02 AM, Jeff Hoogland wrote: E18 rc1 doesn't appear to build here: CC temperature/tempget.o CCLD temperature/tempget make[4]: *** No rule to make target `physics/e-module-physics.edj', needed by `all-am'. Stop. make[4]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src/modules' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src/modules' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1' make: *** [all] Error 2 Same error here, make[4]: *** No rule to make target 'physics/e-module-physics.edj', needed by 'all-am'. Stop. https://build.opensuse.org/package/live_build_log/X11:Enlightenment:Factory/enlightenment/openSUSE_13.1/x86_64 I have physics enabled in the efl and enlightenment is built with no configure flags passed. alpha4 worked fine On Sun, Dec 8, 2013 at 2:58 PM, Jeff Hoogland jeffhoogl...@linux.comwrote: Just wanted to confirm emotion generic players isn't getting a 1.8.1 release. On Sun, Dec 8, 2013 at 2:32 PM, Stefan Schmidt ste...@datenfreihafen.orgwrote: Hello. On Fri, 2013-12-06 at 12:35, Stefan Schmidt wrote: On Thu, 2013-12-05 at 08:55, Stefan Schmidt wrote: On Thu, 2013-12-05 at 08:53, Stefan Schmidt wrote: Hello. [Now CC'ed to enlightenment-release] Everybody could see that this was a lie but is true now... On Wed, 2013-12-04 at 14:44, Stefan Schmidt wrote: It seems all 1.8 branches have accumulated enough fixes already to allow for a 1.8.x release on Friday. If you have backported your _tested_ important fixes to the stable branch consider yourself a good person. If know anything else that needs backporting please do so by Thursday evening. I don't want last minutes commits just a second before the release. This needs to be adapted slightly. As Mike pointed out we have a policy for having the tarballs around for 24h to allow testing before doing the final announce. This is a really good thing so I plan to stick with it. Adaption to my current plan would be that I prepare the tarballs and everythign on Friday evening European time and allow for testing until Sunday (I'm off Saturday) and if the tarball have been fine do the announcement on Sunday. Due to laptop and hard disk dieing I have to move this forward a bit. I really need the time to recover. Tarballs for testing should be out on Sunday evening and release announcement 24h later if nothing problematic comes up. On the good side we will have an e18-rc1 together with these. In the spirit of all the other releases I also pushed out the TESTING tarballs for efl, elm evas_generic_loaders and e18. While efl, elm and evas_generic loaders are stable releases e18 gets his first release candidate together with them. THIS MIGHT NOT BE THE FINAL TARBALLS. Please test them and let me know any problems. If nothing shows I will make them final in 24h. http://download.enlightenment.org/rel/libs/efl/efl-1.8.2.tar.gz http://download.enlightenment.org/rel/libs/evas_generic_loaders/evas_generic_loaders-1.8.1.tar.gz http://download.enlightenment.org/rel/libs/elementary/elementary-1.8.1.tar.gz http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.18.0-rc1.tar.gz Happy testing. regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ~Jeff Hoogland http://jeffhoogland.com/ Thoughts on Technology http://jeffhoogland.blogspot.com/, Tech Blog Bodhi Linux http://bodhilinux.com/, Enlightenment for your Desktop -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing
Re: [E-devel] [EGIT] [core/enlightenment] master 01/10: Check return value from mkdir
On Sun, Dec 8, 2013 at 7:34 PM, Sebastian Dransfeld s...@tango.flipp.net
wrote:
On 12/08/2013 01:41 AM, Gustavo Sverzut Barbieri wrote:
On Sat, Dec 7, 2013 at 7:29 PM, Sebastian Dransfeld s...@tango.flipp.net
wrote:
englebass pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=05f00710f22382902ac866461f8287a0fce90616
commit 05f00710f22382902ac866461f8287a0fce90616
Author: Sebastian Dransfeld s...@tango.flipp.net
Date: Sat Dec 7 21:32:11 2013 +0100
Check return value from mkdir
If mkdir fails, no need to stat.
Fixes CID 1039963
---
src/bin/e_ipc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/e_ipc.c b/src/bin/e_ipc.c
index 765b56e..e2853ce 100644
--- a/src/bin/e_ipc.c
+++ b/src/bin/e_ipc.c
@@ -80,7 +80,8 @@ e_ipc_init(void)
{
snprintf(buf, sizeof(buf), %s/e-%s@%x,
base, user, id1);
good! While not fully related to this patch, but it remembered me that
if set $XDG_RUNTIME_DIR we should use that instead of base + user. It
is guaranteed to be an user-private directory if set (just systemd
does that AFAIK), we can keep the old case for legacy systems.
The code already uses XDG_RUNTIME_DIR.
S.
$XDG_RUNTIME_DIR
good! I checked it here, still have the redundant user name in there,
but doesn't matter much :-)
--
Gustavo Sverzut Barbieri
--
Mobile: +55 (19) 9225-2202
Contact: http://www.gustavobarbieri.com.br/contact
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
I'm not sure this is the case - just like Simon alpha4 builds fine here. At any rate I guess I'll try just disabling physics then. On Mon, Dec 9, 2013 at 7:02 AM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: there haven't been any changes to this in months, so it's definitely something on your systems. On Mon, 09 Dec 2013 23:26:27 +1030 Simon si...@simotek.net wrote: [ 175s] make[4]: *** No rule to make target `physics/e-module-physics.edj', needed by `all-am'. Stop. On 12/09/2013 09:02 AM, Jeff Hoogland wrote: E18 rc1 doesn't appear to build here: CC temperature/tempget.o CCLD temperature/tempget make[4]: *** No rule to make target `physics/e-module-physics.edj', needed by `all-am'. Stop. make[4]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src/modules' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src/modules' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1' make: *** [all] Error 2 Same error here, make[4]: *** No rule to make target 'physics/e-module-physics.edj', needed by 'all-am'. Stop. https://build.opensuse.org/package/live_build_log/X11:Enlightenment:Factory/enlightenment/openSUSE_13.1/x86_64 I have physics enabled in the efl and enlightenment is built with no configure flags passed. alpha4 worked fine On Sun, Dec 8, 2013 at 2:58 PM, Jeff Hoogland jeffhoogl...@linux.com wrote: Just wanted to confirm emotion generic players isn't getting a 1.8.1 release. On Sun, Dec 8, 2013 at 2:32 PM, Stefan Schmidt ste...@datenfreihafen.orgwrote: Hello. On Fri, 2013-12-06 at 12:35, Stefan Schmidt wrote: On Thu, 2013-12-05 at 08:55, Stefan Schmidt wrote: On Thu, 2013-12-05 at 08:53, Stefan Schmidt wrote: Hello. [Now CC'ed to enlightenment-release] Everybody could see that this was a lie but is true now... On Wed, 2013-12-04 at 14:44, Stefan Schmidt wrote: It seems all 1.8 branches have accumulated enough fixes already to allow for a 1.8.x release on Friday. If you have backported your _tested_ important fixes to the stable branch consider yourself a good person. If know anything else that needs backporting please do so by Thursday evening. I don't want last minutes commits just a second before the release. This needs to be adapted slightly. As Mike pointed out we have a policy for having the tarballs around for 24h to allow testing before doing the final announce. This is a really good thing so I plan to stick with it. Adaption to my current plan would be that I prepare the tarballs and everythign on Friday evening European time and allow for testing until Sunday (I'm off Saturday) and if the tarball have been fine do the announcement on Sunday. Due to laptop and hard disk dieing I have to move this forward a bit. I really need the time to recover. Tarballs for testing should be out on Sunday evening and release announcement 24h later if nothing problematic comes up. On the good side we will have an e18-rc1 together with these. In the spirit of all the other releases I also pushed out the TESTING tarballs for efl, elm evas_generic_loaders and e18. While efl, elm and evas_generic loaders are stable releases e18 gets his first release candidate together with them. THIS MIGHT NOT BE THE FINAL TARBALLS. Please test them and let me know any problems. If nothing shows I will make them final in 24h. http://download.enlightenment.org/rel/libs/efl/efl-1.8.2.tar.gz http://download.enlightenment.org/rel/libs/evas_generic_loaders/evas_generic_loaders-1.8.1.tar.gz http://download.enlightenment.org/rel/libs/elementary/elementary-1.8.1.tar.gz http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.18.0-rc1.tar.gz Happy testing. regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ~Jeff Hoogland http://jeffhoogland.com/ Thoughts on Technology http://jeffhoogland.blogspot.com/, Tech Blog Bodhi Linux http://bodhilinux.com/, Enlightenment for your Desktop
Re: [E-devel] NEWS and ChangeLog updates in 1.9 cycle
On 03/12/13 18:58, Iván Briano wrote: On Tue, Dec 3, 2013 at 3:10 PM, Stefan Schmidt ste...@datenfreihafen.org wrote: Hello. On Mon, 2013-12-02 at 11:02, Stefan Schmidt wrote: Please be aware that we don't want to update NEWS and Changelog with every commit in this cycle anymore. I have just seen some commits doing that. They only copy the commit subject into two more files. I will go through the commit log before cutting tarballs and update them accordingly. So please put your energy into writing good commit messages instead of updating two moe files with the same content. Seems people are still struggling what I expect from them in the commit message to make my life easier. I don't have a template for you as I don't want to cut down your creativity. :) What I can give you is a few questions you can ask yourself when writing it. o Is it a bug fix? If yes please mention this somehow in the commit message e.g. evas: Fix length check to avoid slow path in evas line That would perfectly indicate to me that this is a bug fix. o Does the bug have a phab ticket? (It should) Please mention the phab ticket number. Same for the coverity ID. o Bug fixes for features that just merged in this cycle are good but long standing bugs from older releases are more important to get mentioned. o For bigger features which might span over several patches I really would appreciate a good high level description that goes either directly into the release notes wiki page or in one of the first commits. If you do the later please point this out to me so I can bring it over to the release note page. (Hint: Directly put it into the wiki makes both our life easier.) Thats is for now. Once I find more problems I will let you know. For now I would like to keep this lean and grow more naturally. If I may add, commit messages that describe obvious code don't help, but adding the reason why the change matters does. So don't just describe what you did, but tell us why, what was the problem, why did that part of the code caused it, why does your change fix it. This helps also not only to review the actual patch but to find out if the fix is the best we can come up with, or if maybe it's not the right fix but it's covering a deeper problem. Yes, I hate those commit messages! Added an if to check some-crazy-shit is equal to 8 in some-other-crazy-shit. -- Tom. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
that's probably a good idea since it no longer exists. On Mon, 9 Dec 2013 07:11:00 -0600 Jeff Hoogland jeffhoogl...@linux.com wrote: I'm not sure this is the case - just like Simon alpha4 builds fine here. At any rate I guess I'll try just disabling physics then. On Mon, Dec 9, 2013 at 7:02 AM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: there haven't been any changes to this in months, so it's definitely something on your systems. On Mon, 09 Dec 2013 23:26:27 +1030 Simon si...@simotek.net wrote: [ 175s] make[4]: *** No rule to make target `physics/e-module-physics.edj', needed by `all-am'. Stop. On 12/09/2013 09:02 AM, Jeff Hoogland wrote: E18 rc1 doesn't appear to build here: CC temperature/tempget.o CCLD temperature/tempget make[4]: *** No rule to make target `physics/e-module-physics.edj', needed by `all-am'. Stop. make[4]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src/modules' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src/modules' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jeff/0.18.0-rc1/enlightenment-0.18.0-rc1' make: *** [all] Error 2 Same error here, make[4]: *** No rule to make target 'physics/e-module-physics.edj', needed by 'all-am'. Stop. https://build.opensuse.org/package/live_build_log/X11:Enlightenment:Factory/enlightenment/openSUSE_13.1/x86_64 I have physics enabled in the efl and enlightenment is built with no configure flags passed. alpha4 worked fine On Sun, Dec 8, 2013 at 2:58 PM, Jeff Hoogland jeffhoogl...@linux.com wrote: Just wanted to confirm emotion generic players isn't getting a 1.8.1 release. On Sun, Dec 8, 2013 at 2:32 PM, Stefan Schmidt ste...@datenfreihafen.orgwrote: Hello. On Fri, 2013-12-06 at 12:35, Stefan Schmidt wrote: On Thu, 2013-12-05 at 08:55, Stefan Schmidt wrote: On Thu, 2013-12-05 at 08:53, Stefan Schmidt wrote: Hello. [Now CC'ed to enlightenment-release] Everybody could see that this was a lie but is true now... On Wed, 2013-12-04 at 14:44, Stefan Schmidt wrote: It seems all 1.8 branches have accumulated enough fixes already to allow for a 1.8.x release on Friday. If you have backported your _tested_ important fixes to the stable branch consider yourself a good person. If know anything else that needs backporting please do so by Thursday evening. I don't want last minutes commits just a second before the release. This needs to be adapted slightly. As Mike pointed out we have a policy for having the tarballs around for 24h to allow testing before doing the final announce. This is a really good thing so I plan to stick with it. Adaption to my current plan would be that I prepare the tarballs and everythign on Friday evening European time and allow for testing until Sunday (I'm off Saturday) and if the tarball have been fine do the announcement on Sunday. Due to laptop and hard disk dieing I have to move this forward a bit. I really need the time to recover. Tarballs for testing should be out on Sunday evening and release announcement 24h later if nothing problematic comes up. On the good side we will have an e18-rc1 together with these. In the spirit of all the other releases I also pushed out the TESTING tarballs for efl, elm evas_generic_loaders and e18. While efl, elm and evas_generic loaders are stable releases e18 gets his first release candidate together with them. THIS MIGHT NOT BE THE FINAL TARBALLS. Please test them and let me know any problems. If nothing shows I will make them final in 24h. http://download.enlightenment.org/rel/libs/efl/efl-1.8.2.tar.gz http://download.enlightenment.org/rel/libs/evas_generic_loaders/evas_generic_loaders-1.8.1.tar.gz http://download.enlightenment.org/rel/libs/elementary/elementary-1.8.1.tar.gz http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.18.0-rc1.tar.gz Happy testing. regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
Hello. On Mon, 2013-12-09 at 12:26, Thanatermesis wrote: From a packagers perspective it would be great if we could keep the efl, elementary and evas/emotion_generic_loaders version numbers the same even if there are no changes, the same as we did for the 1.7 tree. I'll leave it for you guys to decide though. + 1 This counts not all all for me. If you have reasons let people known them. +1 has the same status as an empty mail for me. regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/enlightenment] master 01/02: remove unnecessary file
discomfitor pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=93ddaf2846617c3429533f80d15223e9c1d50942 commit 93ddaf2846617c3429533f80d15223e9c1d50942 Author: Mike Blumenkrantz zm...@samsung.com Date: Mon Dec 9 08:10:36 2013 -0500 remove unnecessary file --- src/modules/wl_screenshot/module.desktop | 20 1 file changed, 20 deletions(-) diff --git a/src/modules/wl_screenshot/module.desktop b/src/modules/wl_screenshot/module.desktop deleted file mode 100644 index 697b38e..000 --- a/src/modules/wl_screenshot/module.desktop +++ /dev/null @@ -1,20 +0,0 @@ -[Desktop Entry] -Encoding=UTF-8 -Type=Link -Name=Wayland Screenshot -Name[ca]=Wayland Capturador de pantalla -Name[eo]=Ekrankopiilo de Wayland -Name[es]=Wayland Capturador de pantalla -Name[fr]=Copie d'écran de Wayland -Name[gl]=Wayland Capturador de pantalla -Name[pt]=Wayland - Captura de ecrã -Comment=Enlightenment Wayland Screenshot Module -Comment[ca]=Mòdul de l'Enlightenment per a capturar la pantalla de Wayland -Comment[eo]=Modulo de Enlightenment por ekrankopii en Wayland -Comment[es]=Módulo de Enlightenment para capturar la pantalla en Wayland -Comment[fr]=Module de capture d'écran Wayland pour Enlightenment -Comment[gl]=Módulo de Enlightenment para capturar a pantalla en Wayland -Comment[it]=Modulo di Enlightenment per screenshot in Wayland -Comment[pt]=Módulo de captura de ecrã -Icon=e-module-wl_screenshot.edj -X-Enlightenment-ModuleType=look --
[EGIT] [core/enlightenment] master 02/02: remove physics module
discomfitor pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=27d607d8639a303226673cd14de886e70b59b397 commit 27d607d8639a303226673cd14de886e70b59b397 Author: Mike Blumenkrantz zm...@samsung.com Date: Mon Dec 9 08:20:28 2013 -0500 remove physics module realistically I shouldn't have merged this into the release last year. failing that, I probably should have removed it after the release. even if I didn't remove it, I should have at least updated/tested it. I did none of these things, and neither did anyone else, and thus we have an unmaintained module in core. NOT ON MY WATCH --- configure.ac | 33 -- po/POTFILES.in | 2 - src/modules/Makefile.am| 4 - src/modules/Makefile_physics.am| 25 - src/modules/physics/TODO | 22 - src/modules/physics/e-module-physics.edj | Bin 11935 - 0 bytes src/modules/physics/e_mod_config.c | 183 -- src/modules/physics/e_mod_main.c | 127 src/modules/physics/e_mod_main.h | 33 -- src/modules/physics/e_mod_physics.c| 911 - src/modules/physics/e_mod_physics.h| 11 - src/modules/physics/e_mod_physics_cfdata.c | 48 -- src/modules/physics/e_mod_physics_cfdata.h | 32 - src/modules/physics/module.desktop.in | 23 - 14 files changed, 1454 deletions(-) diff --git a/configure.ac b/configure.ac index 43e2503..171e6e4 100644 --- a/configure.ac +++ b/configure.ac @@ -718,37 +718,6 @@ define([CHECK_MODULE_NOTIFICATION], fi ]) -have_ephysics=no -AM_CONDITIONAL([HAVE_EPHYSICS], [false]) -AC_ARG_ENABLE([ephysics], - AC_HELP_STRING([--disable-ephysics], [disable Ephysics support @:@default=detect@:@]), - [e_cv_want_ephysics=$enableval], - AC_CACHE_VAL([e_cv_want_ephysics], [e_cv_want_ephysics=yes]) -) -if test x$e_cv_want_ephysics != xno ; then - AC_E_CHECK_PKG(EPHYSICS, [ ephysics ], - [ -AC_DEFINE_UNQUOTED([HAVE_EPHYSICS], [1], [enable ephysics]) - ], - [ -AC_MSG_NOTICE([ephysics disabled]) -e_cv_want_ephysics=no - ]) -else - AC_MSG_NOTICE([ephysics disabled]) -e_cv_want_ephysics=no -fi -AC_SUBST([EPHYSICS_CFLAGS]) -AC_SUBST([EPHYSICS_LIBS]) - -AM_CONDITIONAL(HAVE_PHYSICS, false) -define([CHECK_MODULE_PHYSICS], -[ - if test x$e_cv_want_ephysics = xno ; then -PHYSICS=false - fi -]) - AM_CONDITIONAL(HAVE_ALSA, false) define([CHECK_MODULE_MIXER], [ @@ -901,7 +870,6 @@ AC_E_OPTIONAL_MODULE([syscon], true) AC_E_OPTIONAL_MODULE([everything], true) AC_E_OPTIONAL_MODULE([systray], true) AC_E_OPTIONAL_MODULE([appmenu], true) -AC_E_OPTIONAL_MODULE([physics], true, [CHECK_MODULE_PHYSICS]) AC_E_OPTIONAL_MODULE([quickaccess], true) AC_E_OPTIONAL_MODULE([teamwork], true) AC_E_OPTIONAL_MODULE([shot], true) @@ -1025,7 +993,6 @@ src/modules/everything/everything.pc src/modules/systray/module.desktop src/modules/appmenu/module.desktop src/modules/conf_comp/module.desktop -src/modules/physics/module.desktop src/modules/quickaccess/module.desktop src/modules/teamwork/module.desktop src/modules/shot/module.desktop diff --git a/po/POTFILES.in b/po/POTFILES.in index 7e53461..ea89127 100644 --- a/po/POTFILES.in +++ b/po/POTFILES.in @@ -259,8 +259,6 @@ src/modules/notification/e_mod_config.c src/modules/notification/e_mod_main.c src/modules/pager/e_mod_config.c src/modules/pager/e_mod_main.c -src/modules/physics/e_mod_config.c -src/modules/physics/e_mod_main.c src/modules/quickaccess/e_mod_config.c src/modules/quickaccess/e_mod_main.c src/modules/quickaccess/e_mod_quickaccess.c diff --git a/src/modules/Makefile.am b/src/modules/Makefile.am index af7a270..464144e 100644 --- a/src/modules/Makefile.am +++ b/src/modules/Makefile.am @@ -195,10 +195,6 @@ if USE_MODULE_APPMENU include Makefile_appmenu.am endif -if USE_MODULE_PHYSICS -include Makefile_physics.am -endif - if USE_MODULE_QUICKACCESS include Makefile_quickaccess.am endif diff --git a/src/modules/Makefile_physics.am b/src/modules/Makefile_physics.am deleted file mode 100644 index fcf1895..000 --- a/src/modules/Makefile_physics.am +++ /dev/null @@ -1,25 +0,0 @@ -physicsdir = $(MDIR)/physics -physics_DATA = physics/e-module-physics.edj \ - physics/module.desktop - -EXTRA_DIST += $(physics_DATA) - -physics_module_la_CFLAGS = $(AM_CFLAGS) -physics_module_la_CFLAGS += @EPHYSICS_CFLAGS@ - -physicspkgdir = $(MDIR)/physics/$(MODULE_ARCH) -physicspkg_LTLIBRARIES = physics/module.la - -physics_module_la_SOURCES = physics/e_mod_main.c \ - physics/e_mod_main.h \ - physics/e_mod_config.c \ - physics/e_mod_physics_cfdata.c \ - physics/e_mod_physics_cfdata.h \ - physics/e_mod_physics.c \ - physics/e_mod_physics.h -
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
Hello. On Mon, 2013-12-09 at 07:11, Jeff Hoogland wrote: I'm not sure this is the case - just like Simon alpha4 builds fine here. Really strange. I reviewd the commits that gone into rc1 and efl 1.8.2 but I can't see anything that broke this. Also its building fine for me and on jenkins. At any rate I guess I'll try just disabling physics then. Please do. The physics module was not really maintained and Mike just removed it so it will be gone in the next rc and the final release anyway. Having it disabled manually for the rc1 should be ok for the people encountering this problem. Does that sound good for you guys? regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: Evas textblock: Slightly improve paragraph items freeing.
tasn pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=b5262de237adf650e3cafd9fb7ffab828d62345e
commit b5262de237adf650e3cafd9fb7ffab828d62345e
Author: Tom Hacohen t...@stosb.com
Date: Mon Dec 9 13:33:46 2013 +
Evas textblock: Slightly improve paragraph items freeing.
Use the EINA_LIST_FREE macro instead of a safe loop and a list free.
This is faster and cleaner.
---
src/lib/evas/canvas/evas_object_textblock.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/lib/evas/canvas/evas_object_textblock.c
b/src/lib/evas/canvas/evas_object_textblock.c
index 2c6c8f3..41cd764 100644
--- a/src/lib/evas/canvas/evas_object_textblock.c
+++ b/src/lib/evas/canvas/evas_object_textblock.c
@@ -2886,13 +2886,11 @@ _paragraph_free(const Evas_Object *eo_obj,
Evas_Object_Textblock_Paragraph *par)
_paragraph_clear(eo_obj, par);
{
-Eina_List *i, *i_prev;
Evas_Object_Textblock_Item *it;
-EINA_LIST_FOREACH_SAFE(par-logical_items, i, i_prev, it)
+EINA_LIST_FREE(par-logical_items, it)
{
_item_free(eo_obj, NULL, it);
}
-eina_list_free(par-logical_items);
}
#ifdef BIDI_SUPPORT
if (par-bidi_props)
--
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On Mon, 9 Dec 2013 14:23:21 +0100 Stefan Schmidt ste...@datenfreihafen.org wrote: Hello. On Mon, 2013-12-09 at 12:26, Thanatermesis wrote: From a packagers perspective it would be great if we could keep the efl, elementary and evas/emotion_generic_loaders version numbers the same even if there are no changes, the same as we did for the 1.7 tree. I'll leave it for you guys to decide though. + 1 This counts not all all for me. If you have reasons let people known them. +1 has the same status as an empty mail for me. regards Stefan Schmidt Agree I'm guessing that in the future we'll continue to merge things. Elementary will probably get merged into the EFL tree, and maybe emotion generic will merge into the evas generic tree. It's annoying to have to upgrade (for users and packagers) packages when nothing has changed except a version number, but it does make bug filing/fixing easier. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
Hello. On Mon, 2013-12-09 at 14:28, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 07:11, Jeff Hoogland wrote: I'm not sure this is the case - just like Simon alpha4 builds fine here. Really strange. I reviewd the commits that gone into rc1 and efl 1.8.2 but I can't see anything that broke this. Also its building fine for me and on jenkins. At any rate I guess I'll try just disabling physics then. Please do. The physics module was not really maintained and Mike just removed it so it will be gone in the next rc and the final release anyway. Having it disabled manually for the rc1 should be ok for the people encountering this problem. Does that sound good for you guys? To avoid any more confusion on this Mike and I decided that I will prepare a new rc1 tarball with the removal commit and upload it. Will send a mail once its up. regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On Mon, 9 Dec 2013 14:37:58 +0100 Stefan Schmidt ste...@datenfreihafen.org wrote: Hello. On Mon, 2013-12-09 at 14:28, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 07:11, Jeff Hoogland wrote: I'm not sure this is the case - just like Simon alpha4 builds fine here. Really strange. I reviewd the commits that gone into rc1 and efl 1.8.2 but I can't see anything that broke this. Also its building fine for me and on jenkins. At any rate I guess I'll try just disabling physics then. Please do. The physics module was not really maintained and Mike just removed it so it will be gone in the next rc and the final release anyway. Having it disabled manually for the rc1 should be ok for the people encountering this problem. Does that sound good for you guys? To avoid any more confusion on this Mike and I decided that I will prepare a new rc1 tarball with the removal commit and upload it. Will send a mail once its up. regards Stefan Schmidt I approve this message. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
Hello. On Mon, 2013-12-09 at 14:37, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 14:28, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 07:11, Jeff Hoogland wrote: I'm not sure this is the case - just like Simon alpha4 builds fine here. Really strange. I reviewd the commits that gone into rc1 and efl 1.8.2 but I can't see anything that broke this. Also its building fine for me and on jenkins. At any rate I guess I'll try just disabling physics then. Please do. The physics module was not really maintained and Mike just removed it so it will be gone in the next rc and the final release anyway. Having it disabled manually for the rc1 should be ok for the people encountering this problem. Does that sound good for you guys? To avoid any more confusion on this Mike and I decided that I will prepare a new rc1 tarball with the removal commit and upload it. Will send a mail once its up. http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.18.0-rc1.tar.gz I hope the testing with this one goes better. regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Exquisite source code
On 01/12/13 19:00, Thanatermesis wrote: Exquisite was a very nice app, seems like it was only SVN but now I don't found it, can we have it back on GIT ? Before I migrate it I need to know: Is it still actively maintained? (I don't know if I should migrate it or not). If I should migrate it, please also include a description summary and a suggested classification (like the others at git.e.org). -- Tom. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
Hello. On Mon, 2013-12-09 at 20:48, Simon wrote: On 12/09/2013 08:33 PM, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 20:05, Simon wrote: On 12/09/2013 05:40 PM, Stefan Schmidt wrote: Hello. On Sun, 2013-12-08 at 14:58, Jeff Hoogland wrote: Just wanted to confirm emotion generic players isn't getting a 1.8.1 release. Confirmed. Emotion generic players had not a single commit since 1.8.0. Nothing to release. regards Stefan Schmidt From a packagers perspective it would be great if we could keep the efl, elementary and evas/emotion_generic_loaders version numbers the same even if there are no changes, the same as we did for the 1.7 tree. I'll leave it for you guys to decide though. I was pondering about that. For 1.7.x we had way more tarballs for one release. Due to the merged efl tree this really got down. Would you expect emotion generic player release tarballs for 1.8.1 and 1.8.2 even when not a single commit hit that repo? We can switch back to that model but I'm not a fan of doing empty releases just to stay in sync for the version number. It would only heppen from 1.8.3 though. Skipping a minor release for everything but efl. IT will always be out of sync with e18 in any case. In sumarry I have no hard feeling in any direction. :) regards Stefan Schmidt I wasn't much of a fan of the empty releases at first either, but realistic the enlightenment foundation libraries are efl, elementary and e*_generic_loaders, its just some components are built separately because its easier and others due to licensing. From a user perspective particularly in regards to filing bugs it makes it easier if they all follow the same versioning, especially if efl and elementary are out of sync. We did it with 1.7.x and its seems to make packagers life easier as well as versions for bug reports, etc. So be it. From 1.8.3 I will do collective releases for efl, elm, evas and emotion generic loaders. Even if the specific tarballs have no changes. regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Proposal of EFL_SAFE_FREE macro
+1 EINA_SAFE_FREE
-Regards, Hermet-
-Original Message-
From: daniel.za...@samsung.comdaniel.za...@samsung.com
To: Enlightenment developer listenlightenment-devel@lists.sourceforge.net;
Cc:
Sent: 2013-12-08 (일) 14:17:13
Subject: Re: [E-devel] Proposal of EFL_SAFE_FREE macro
On 12/07/2013 04:56 PM, Daniel Juyung Seo wrote:
On Sat, Dec 7, 2013 at 11:27 PM, Gustavo Sverzut Barbieri
barbi...@gmail.com wrote:
On Fri, Dec 6, 2013 at 10:19 PM, Carsten Haitzler raster@rasterman.com
wrote:
On Fri, 6 Dec 2013 17:26:21 -0200 Gustavo Sverzut Barbieri
barbi...@gmail.com
said:
On Fri, Dec 6, 2013 at 10:42 AM, David Seikel onefang@gmail.com
wrote:
On Fri, 6 Dec 2013 10:12:09 -0200 Gustavo Sverzut Barbieri
barbieri@gmail.com wrote:
On Thu, Dec 5, 2013 at 10:23 PM, Daniel Juyung Seo
seojuyung2@gmail.com wrote:
Dear all, this is Daniel Juyung Seo.
I propose EFL_SAFE_FREE macro for efl.
It looks like:
# define EFL_SAFE_FREE(_h, _fn) do { if (_h) { _fn((void*)_h);
_h
= NULL; } } while (0)
As I have been using ELM_SAFE_FREE for months, I found out that
this macro is quite useful in terms of code readability, reducing
human mistakes, and using much smaller number of lines with the
same functionality.
Enlightenment has
# define E_FREE_FUNC(_h, _fn) do { if (_h) { _fn((void*)_h); _h =
NULL; } } while (0)
Elementary has
#define ELM_SAFE_FREE(_h, _fn) do { if (_h) { _fn((void*)_h); _h =
NULL; } } while (0)
So why not efl?
By using EFL_SAFE_FREE, this (Old) code will reborn as a (New)
code.
5 lines down to 1 line.
(Old)
if (svr-until_deletion)
{
ecore_timer_del(svr-until_deletion);
svr-until_deletion = NULL;
}
(New)
EFL_SAFE_FREE(svr-until_deletion, ecore_timer_del);
bad name as there is nothing save in it.
EINA_FREE_AND_NULL(ptr, freefunc) would be more descriptive, code is
the same. Or:
EINA_FREE_AND_NULL(ptr) // does free()
EINA_DISPOSE_AND_NULL(ptr, disposefunc) // generic version
I'm not a native speaker, eventually there is a better name for the
second one.
Safe, as in this is the safe way to do it, nothing to do with
saving
things.
i know, but what is safe in it? Because it checks for null before
Hello
the safe here is that it makes things safe afterwards. you no longer
have a
dangling pointer variable (in case you use it again now you've freed the
object).
Yes. Exactly that is what this macro intended.
As we discussed the same thing, ELM_SAFE_FREE, long ago in the mailing
list, safe looks good to me.
I've mentioned this over an over, while in some places we do want to
NULL the pointer because it is a valid value indicating something (ie:
no timer running, no object in use...) many others we do NOT want to
zero this pointer because the pointer shouldn't be used at all... and
if we stick a NULL and then check for such special value elsewhere
we're hiding bugs.
Sure exactly. I already know that you mentioned this long before in the
mailing list.
As I mentioned in the first mail,this macro is not a silver bullet and
should not be overused.
So use it only when you have to.
And about your suggestion about EINA_FREE_AND_NULL, having this macro in
eina looks good.
How do others think?
EINA_SAFE_FREE!
ok for me. ELM_SAFE_FREE is very useful and it could be good to have the
same for efl. The name seems good too imo.
Also, if you set a pointer to NULL you lose valgrind tracing. If you
do not set to NULL you can get it to say that the pointer was freed
elsewhere and then you can easily trace why your bug happened.
Yes I also remember you mentioned this before in the mailing list.
So we should use this macro only when we really need it.
If there is no objection I will work on EINA_SAFE_FREE.
Thanks.
Daniel Juyung Seo (SeoZ)
--
Gustavo Sverzut Barbieri
--
Mobile: +55 (19) 9225-2202
Contact: http://www.gustavobarbieri.com.br/contact
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Terminology 0.4.0 is out!
What's the best way to reset the settings? Mine seems to be stuck in a bizarre state. On Sun, 8 Dec 2013 16:39:39 +0100 Boris Faure bo...@fau.re wrote: We are pleased to announce the release of Terminology 0.4 You can download the tarball either as [1]terminology-0.4.0.tar.gz or as [2]terminology-0.4.0.tar.bz2. This release features: * text reflow on resize, * full 256 colors support, * improved terminal compatibility, * improved selection handling, * backscroll compression to reduce memory usage, * many bug fixes, * and more! It is best run with the EFL 1.8 but also works with EFL 1.7. Happy compiling! 1. http://download.enlightenment.org/rel/apps/terminology/terminology-0.4.0.tar.gz 2. http://download.enlightenment.org/rel/apps/terminology/terminology-0.4.0.tar.bz2 -- Boris Faure for the Terminology team -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Terminology 0.4.0 is out!
On 09/12/13 15:15, Adam Flott wrote: What's the best way to reset the settings? Mine seems to be stuck in a bizarre state. Close terminology and run: rm -r ~/.config/terminology -- Tom. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [enlightenment/modules/elfe] master 01/01: Fix build with E18 rc1. E changed completly how composite windows work. I need to figure out how it works now, to get the win list choice back. For no
captainigloo pushed a commit to branch master.
http://git.enlightenment.org/enlightenment/modules/elfe.git/commit/?id=1ec0e7713c3ca901014811ff78277d9e2aaac981
commit 1ec0e7713c3ca901014811ff78277d9e2aaac981
Author: Nicolas Aguirre aguirre.nico...@gmail.com
Date: Mon Dec 9 16:44:23 2013 +0100
Fix build with E18 rc1.
E changed completly how composite windows work.
I need to figure out how it works now, to get the win list choice back.
For now just comment out the not working code.
---
src/winlist.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/winlist.c b/src/winlist.c
index f4e3bcf..06021c0 100644
--- a/src/winlist.c
+++ b/src/winlist.c
@@ -17,6 +17,7 @@ typedef struct _Elfe_Winlist_Item Elfe_Winlist_Item;
typedef struct _Elfe_Winlist Elfe_Winlist;
static Eina_Bool show = EINA_FALSE;
+#if 0
struct _E_Comp_Win
{
EINA_INLIST;
@@ -88,7 +89,7 @@ struct _E_Comp_Win
Eina_Bool inhash : 1;
Eina_Bool show_ready : 1;
};
-
+#endif
struct _Elfe_Winlist_Item
{
Elfe_Winlist *winlist;
@@ -103,7 +104,7 @@ struct _Elfe_Winlist_Item
Evas_Coord x, y;
} history[SWIPE_MOVES];
Ecore_Timer *swipe_timer;
- E_Manager_Comp_Source *src;
+ /*E_Manager_Comp_Source *src;*/
E_Manager *man;
};
@@ -351,7 +352,7 @@ _winlist_del(Elfe_Winlist *winlist)
EINA_LIST_FREE(winlist-windows, it)
{
-e_manager_comp_src_hidden_set(it-man, it-src, EINA_FALSE);
+ /*e_manager_comp_src_hidden_set(it-man, it-src, EINA_FALSE);*/
e_object_unref(E_OBJECT(it-bd));
if (it-swipe_timer)
ecore_timer_del(it-swipe_timer);
@@ -386,13 +387,14 @@ _window_mouse_clicked_cb(void *data, Evas_Object *obj,
const char *emission, con
ecore_x_netwm_client_active_request(0, it-bd-client.win,
1, 0);
- e_manager_comp_src_hidden_set(it-man, it-src, EINA_FALSE);
+ /* e_manager_comp_src_hidden_set(it-man, it-src, EINA_FALSE);*/
_winlist_del(it-winlist);
}
static void
_elfe_action(const char *params, int modifiers, int method)
{
+#if 0
E_Manager_Comp_Source *src;
Eina_List *l;
Eina_List *handlers;
@@ -621,6 +623,7 @@ _elfe_action(const char *params, int modifiers, int method)
evas_object_show(bx);
elm_object_content_set(sc, bx);
}
+#endif
}
static void
--
Re: [E-devel] Terminology 0.4.0 is out!
On Mon, 09 Dec 2013 15:35:11 + Tom Hacohen tom.haco...@samsung.com wrote: On 09/12/13 15:15, Adam Flott wrote: What's the best way to reset the settings? Mine seems to be stuck in a bizarre state. Close terminology and run: rm -r ~/.config/terminology Awesome. Thanks. Any reason ~/.terminology exists? -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: ecore_evas: added missing documentation for ecore_evas_manual_render_set/get().
seoz pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=e163b3eef52533cb0bc23bf1dce284f6462826c9 commit e163b3eef52533cb0bc23bf1dce284f6462826c9 Author: Daniel Juyung Seo seojuyu...@gmail.com Date: Mon Dec 9 20:17:05 2013 +0900 ecore_evas: added missing documentation for ecore_evas_manual_render_set/get(). --- src/lib/ecore_evas/Ecore_Evas.h | 29 + 1 file changed, 29 insertions(+) diff --git a/src/lib/ecore_evas/Ecore_Evas.h b/src/lib/ecore_evas/Ecore_Evas.h index 83ebf10..20e7f4b 100644 --- a/src/lib/ecore_evas/Ecore_Evas.h +++ b/src/lib/ecore_evas/Ecore_Evas.h @@ -1896,7 +1896,36 @@ EAPI voidecore_evas_sticky_set(Ecore_Evas *ee, Eina_Bool sticky); * */ EAPI Eina_Bool ecore_evas_sticky_get(const Ecore_Evas *ee); + +/** + * Enable/disable manual render + * + * @paream ee An @c Ecore_Evas handle + * @param manual_render Enable/disable manual render. @c EINA_TRUE to enable + * manual render, @c EINA_FALSE to disable manual render. @c EINA_FALSE by + * default + * + * If @p manual_render is true, default ecore_evas render routine would be + * disabled and rendering will be done only manually. If @p manual_render is + * false, rendering will be done by default ecore_evas rendering routine, but + * still manual rendering is available. Call ecore_evas_manual_render() to + * force immediate render. + * + * @see ecore_evas_manual_render_get() + * @see ecore_evas_manual_render() + */ EAPI voidecore_evas_manual_render_set(Ecore_Evas *ee, Eina_Bool manual_render); + +/** + * Get enable/disable status of manual render + * + * @paream ee An @c Ecore_Evas handle + * @return @c EINA_TRUE if manual render is enabled, @c EINA_FALSE if manual + * render is disabled + * + * @see ecore_evas_manual_render_set() + * @see ecore_evas_manual_render() + */ EAPI Eina_Bool ecore_evas_manual_render_get(const Ecore_Evas *ee); /** --
Re: [E-devel] Terminology 0.4.0 is out!
On 09/12/13 15:56, Adam Flott wrote: On Mon, 09 Dec 2013 15:35:11 + Tom Hacohen tom.haco...@samsung.com wrote: On 09/12/13 15:15, Adam Flott wrote: What's the best way to reset the settings? Mine seems to be stuck in a bizarre state. Close terminology and run: rm -r ~/.config/terminology Awesome. Thanks. Any reason ~/.terminology exists? Either an old version of terminology, or maybe something is set up wrong on your system. -- Tom. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/elementary] master 01/01: test_dnd: clean up dnd sample code.
seoz pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=7850b395522714a803cb24049a42e82ead5ff4d2
commit 7850b395522714a803cb24049a42e82ead5ff4d2
Author: Daniel Juyung Seo juyung@samsung.com
Date: Tue Dec 10 01:03:27 2013 +0900
test_dnd: clean up dnd sample code.
- fixed formatting.
- set timer pointer to null when canceling the timer.
---
src/bin/test_dnd.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/bin/test_dnd.c b/src/bin/test_dnd.c
index d3fddf0..04cd2a1 100644
--- a/src/bin/test_dnd.c
+++ b/src/bin/test_dnd.c
@@ -401,8 +401,8 @@ static Eina_Bool
_5s_timeout_gone(void *data)
{
printf(Cancel DnD\n);
- Evas_Object *obj = data;
- elm_drag_cancel(obj);
+ elm_drag_cancel(data);
+ _5s_timeout = NULL;
return ECORE_CALLBACK_CANCEL;
}
@@ -681,14 +681,15 @@ _gl_dragstart(void *data EINA_UNUSED, Evas_Object *obj)
{
printf(%s %d\n, __func__, __LINE__);
if (_5s_cancel)
- _5s_timeout = ecore_timer_add(5.0, _5s_timeout_gone, obj);
+ _5s_timeout = ecore_timer_add(5.0, _5s_timeout_gone, obj);
}
static Eina_Bool
_grid_data_getcb(Evas_Object *obj, /* The genlist object */
- Elm_Object_Item *it,
- Elm_Drag_User_Info *info)
-{ /* This called before starting to drag, mouse-down was on it */
+ Elm_Object_Item *it,
+ Elm_Drag_User_Info *info)
+{
+ /* This called before starting to drag, mouse-down was on it */
info-format = ELM_SEL_FORMAT_TARGETS;
info-createicon = _gl_createicon;
info-createdata = it;
@@ -905,7 +906,7 @@ test_dnd_genlist_gengrid(void *data EINA_UNUSED,
Evas_Object *obj EINA_UNUSED, v
NULL, NULL, NULL, NULL, _grid_dropcb, NULL);
elm_drag_item_container_add(grid, ANIM_TIME, DRAG_TIMEOUT,
- _grid_item_getcb, _grid_data_getcb);
+_grid_item_getcb, _grid_data_getcb);
for (i = 0; i 20; i++)
{
snprintf(buf, sizeof(buf), %s/images/%s,
elm_app_data_dir_get(), img[(i % 9)]);
--
[EGIT] [core/efl] master 01/01: ecore_imf/wayland: Only call hide_input_panel on im_context_hide().
antognolli pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=15b5497dfa674ada0ec98805f009b63e3a39f04d
commit 15b5497dfa674ada0ec98805f009b63e3a39f04d
Author: Rafael Antognolli rafael.antogno...@intel.com
Date: Mon Dec 9 14:21:29 2013 -0200
ecore_imf/wayland: Only call hide_input_panel on im_context_hide().
There's no need to call it on text_input_leave too, otherwise this would
be called twice, the one from text_input_leave possibly being called
after the focus was regain already by a text input, causing the bug
described in T237.
This fixes T237.
---
src/modules/ecore_imf/wayland/wayland_imcontext.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/modules/ecore_imf/wayland/wayland_imcontext.c
b/src/modules/ecore_imf/wayland/wayland_imcontext.c
index 6e301c9..6e28cee 100644
--- a/src/modules/ecore_imf/wayland/wayland_imcontext.c
+++ b/src/modules/ecore_imf/wayland/wayland_imcontext.c
@@ -512,9 +512,6 @@ text_input_leave(void *data,
{
WaylandIMContext *imcontext = (WaylandIMContext *)data;
- if (text_input)
- wl_text_input_hide_input_panel(text_input);
-
/* clear preedit */
commit_preedit(imcontext);
clear_preedit(imcontext);
--
[EGIT] [core/efl] efl-1.8 01/01: ecore_imf/wayland: Only call hide_input_panel on im_context_hide().
antognolli pushed a commit to branch efl-1.8.
http://git.enlightenment.org/core/efl.git/commit/?id=1808adbe7a1693a642915c7760850607978a3709
commit 1808adbe7a1693a642915c7760850607978a3709
Author: Rafael Antognolli rafael.antogno...@intel.com
Date: Mon Dec 9 14:21:29 2013 -0200
ecore_imf/wayland: Only call hide_input_panel on im_context_hide().
There's no need to call it on text_input_leave too, otherwise this would
be called twice, the one from text_input_leave possibly being called
after the focus was regain already by a text input, causing the bug
described in T237.
This fixes T237.
---
src/modules/ecore_imf/wayland/wayland_imcontext.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/modules/ecore_imf/wayland/wayland_imcontext.c
b/src/modules/ecore_imf/wayland/wayland_imcontext.c
index 6e301c9..6e28cee 100644
--- a/src/modules/ecore_imf/wayland/wayland_imcontext.c
+++ b/src/modules/ecore_imf/wayland/wayland_imcontext.c
@@ -512,9 +512,6 @@ text_input_leave(void *data,
{
WaylandIMContext *imcontext = (WaylandIMContext *)data;
- if (text_input)
- wl_text_input_hide_input_panel(text_input);
-
/* clear preedit */
commit_preedit(imcontext);
clear_preedit(imcontext);
--
Re: [E-devel] [EGIT] [enlightenment/modules/elfe] master 01/01: Fix build with E18 rc1. E changed completly how composite windows work. I need to figure out how it works now, to get the win list choic
On Mon, 09 Dec 2013 07:45:33 -0800
Nicolas Aguirre aguirre.nico...@gmail.com wrote:
captainigloo pushed a commit to branch master.
http://git.enlightenment.org/enlightenment/modules/elfe.git/commit/?id=1ec0e7713c3ca901014811ff78277d9e2aaac981
commit 1ec0e7713c3ca901014811ff78277d9e2aaac981
Author: Nicolas Aguirre aguirre.nico...@gmail.com
Date: Mon Dec 9 16:44:23 2013 +0100
Fix build with E18 rc1.
E changed completly how composite windows work.
I need to figure out how it works now, to get the win list choice back.
For now just comment out the not working code.
my advice would be don't bother. it changes again completely in e19, which will
be merged soon
---
src/winlist.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/winlist.c b/src/winlist.c
index f4e3bcf..06021c0 100644
--- a/src/winlist.c
+++ b/src/winlist.c
@@ -17,6 +17,7 @@ typedef struct _Elfe_Winlist_Item Elfe_Winlist_Item;
typedef struct _Elfe_Winlist Elfe_Winlist;
static Eina_Bool show = EINA_FALSE;
+#if 0
struct _E_Comp_Win
{
EINA_INLIST;
@@ -88,7 +89,7 @@ struct _E_Comp_Win
Eina_Bool inhash : 1;
Eina_Bool show_ready : 1;
};
-
+#endif
struct _Elfe_Winlist_Item
{
Elfe_Winlist *winlist;
@@ -103,7 +104,7 @@ struct _Elfe_Winlist_Item
Evas_Coord x, y;
} history[SWIPE_MOVES];
Ecore_Timer *swipe_timer;
- E_Manager_Comp_Source *src;
+ /*E_Manager_Comp_Source *src;*/
E_Manager *man;
};
@@ -351,7 +352,7 @@ _winlist_del(Elfe_Winlist *winlist)
EINA_LIST_FREE(winlist-windows, it)
{
-e_manager_comp_src_hidden_set(it-man, it-src, EINA_FALSE);
+ /*e_manager_comp_src_hidden_set(it-man, it-src, EINA_FALSE);*/
e_object_unref(E_OBJECT(it-bd));
if (it-swipe_timer)
ecore_timer_del(it-swipe_timer);
@@ -386,13 +387,14 @@ _window_mouse_clicked_cb(void *data, Evas_Object *obj,
const char *emission, con
ecore_x_netwm_client_active_request(0, it-bd-client.win,
1, 0);
- e_manager_comp_src_hidden_set(it-man, it-src, EINA_FALSE);
+ /* e_manager_comp_src_hidden_set(it-man, it-src, EINA_FALSE);*/
_winlist_del(it-winlist);
}
static void
_elfe_action(const char *params, int modifiers, int method)
{
+#if 0
E_Manager_Comp_Source *src;
Eina_List *l;
Eina_List *handlers;
@@ -621,6 +623,7 @@ _elfe_action(const char *params, int modifiers, int
method)
evas_object_show(bx);
elm_object_content_set(sc, bx);
}
+#endif
}
static void
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] What is a withdrawn window?
The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. U. Artie -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] What is a withdrawn window?
On Mon, 9 Dec 2013 16:53:38 + Eoff, Ullysses A ullysses.a.e...@intel.com wrote: The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. U. Artie withdrawn is the same as iconify, except that the application may decide to free/destroy/reduce functionality in order to conserve system resources. it's like how android apps never close but also aren't in the foreground or using noticeable cpu/battery. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] What is a withdrawn window?
On 09/12/13 16:53, Eoff, Ullysses A wrote: The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. As I said on IRC, if I remember correctly withdrawn is the super-hidden. That is hidden + it's safe to release some resources as it'll be hidden for a while/we need the resources. That's just from the top of my head, I guess raster might be able to remember. We also need to sort out (higher level, not in the engine) all of the withdrawn true/false settings on hide and show and decide what can and should be done in many cases. For example, if we switch to show, does the state automatically change? Can we have a withdrawn state even when shown, and then make it actually do something only when the window is hidden? I don't know, it's kind of weird. -- Tom. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] What is a withdrawn window?
On Mon, Dec 9, 2013 at 3:04 PM, Tom Hacohen tom.haco...@samsung.com wrote: On 09/12/13 16:53, Eoff, Ullysses A wrote: The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. As I said on IRC, if I remember correctly withdrawn is the super-hidden. That is hidden + it's safe to release some resources as it'll be hidden for a while/we need the resources. That's just from the top of my head, I guess raster might be able to remember. OK, your answer seems aligned to Mike's one. So, another question: when we iconify a window, it should still appear in the toplevel list of windows, e.g. for ALT+Tab. Does the same happen when we hide/withdrawn a window? Would be good to have a clear difference between iconify, withdrawn and hide. So far, withdrawn and hide are being treated exactly the same in Wayland engines, while iconify will be different (it's a server-side thing, the client won't free any resources at all). We also need to sort out (higher level, not in the engine) all of the withdrawn true/false settings on hide and show and decide what can and should be done in many cases. For example, if we switch to show, does the state automatically change? Can we have a withdrawn state even when shown, and then make it actually do something only when the window is hidden? I don't know, it's kind of weird. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] What is a withdrawn window?
At Mon, 9 Dec 2013 16:53:38 + Enlightenment developer list enlightenment-devel@lists.sourceforge.net wrote: The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? It is a *standard* window manager thing: a withdrawn is a window that has been unmapped (or never mapped). Just about all widget toolkits have this sort of feature, usually there is some 'window manager' interface API for this and other interactions with the window manager (such as size / geometry hints and grabbing access to the 'close/delete' window function, window resizing/moving, and things like window manager decoration and things like transient properties. (Tcl/Tk has a function 'wm' for all of that for example). Usually this is done because: 1) A bunch of complex stuff will be placed in the window and the the programmer does not want to give the user an 'interesting' view of the window being set up (think: keeping the curtian closed while the stage hands set up the scenery). 2) The window is a dialog box (or something) that gets re-used and is withdrawn when not in use. Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. U. Artie -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] What is a withdrawn window?
At Mon, 9 Dec 2013 15:09:44 -0200 Enlightenment developer list enlightenment-devel@lists.sourceforge.net wrote: On Mon, Dec 9, 2013 at 3:04 PM, Tom Hacohen tom.haco...@samsung.com wrote: On 09/12/13 16:53, Eoff, Ullysses A wrote: The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. As I said on IRC, if I remember correctly withdrawn is the super-hidden. That is hidden + it's safe to release some resources as it'll be hidden for a while/we need the resources. That's just from the top of my head, I guess raster might be able to remember. OK, your answer seems aligned to Mike's one. So, another question: when we iconify a window, it should still appear in the toplevel list of windows, e.g. for ALT+Tab. Does the same happen when we hide/withdrawn a window? Would be good to have a clear difference between iconify, withdrawn and hide. Not sure what 'hide' is exactly, but iconify and withdrawn define two states: iconified: window is not visible, but an icon is visible as a 'place holder'. Some (old school?) window managers place the icon on the desktop itself, but most window managers now put the icon in an icon box, icon manager, or a task manager. The user can click on the icon to make the window visible again. withdrawn: the window is not visible, and there is no UI indication that it even exists. The application must do something to make the window visible. This might be in response to some user action or for some other reason, like a background task completing or some other event happening. So far, withdrawn and hide are being treated exactly the same in Wayland engines, while iconify will be different (it's a server-side thing, the client won't free any resources at all). We also need to sort out (higher level, not in the engine) all of the withdrawn true/false settings on hide and show and decide what can and should be done in many cases. For example, if we switch to show, does the state automatically change? Can we have a withdrawn state even when shown, and then make it actually do something only when the window is hidden? I don't know, it's kind of weird. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
Stefan Schmidt schrieb: Hello. On Mon, 2013-12-09 at 20:48, Simon wrote: On 12/09/2013 08:33 PM, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 20:05, Simon wrote: On 12/09/2013 05:40 PM, Stefan Schmidt wrote: Hello. On Sun, 2013-12-08 at 14:58, Jeff Hoogland wrote: Just wanted to confirm emotion generic players isn't getting a 1.8.1 release. Confirmed. Emotion generic players had not a single commit since 1.8.0. Nothing to release. regards Stefan Schmidt From a packagers perspective it would be great if we could keep the efl, elementary and evas/emotion_generic_loaders version numbers the same even if there are no changes, the same as we did for the 1.7 tree. I'll leave it for you guys to decide though. I was pondering about that. For 1.7.x we had way more tarballs for one release. Due to the merged efl tree this really got down. Would you expect emotion generic player release tarballs for 1.8.1 and 1.8.2 even when not a single commit hit that repo? We can switch back to that model but I'm not a fan of doing empty releases just to stay in sync for the version number. It would only heppen from 1.8.3 though. Skipping a minor release for everything but efl. IT will always be out of sync with e18 in any case. In sumarry I have no hard feeling in any direction. :) regards Stefan Schmidt I wasn't much of a fan of the empty releases at first either, but realistic the enlightenment foundation libraries are efl, elementary and e*_generic_loaders, its just some components are built separately because its easier and others due to licensing. From a user perspective particularly in regards to filing bugs it makes it easier if they all follow the same versioning, especially if efl and elementary are out of sync. We did it with 1.7.x and its seems to make packagers life easier as well as versions for bug reports, etc. So be it. From 1.8.3 I will do collective releases for efl, elm, evas and emotion generic loaders. Even if the specific tarballs have no changes. regards Stefan Schmidt How does it make packagers life easier, if there are empty version bumps, which also need to be followed by the package manager? From my experience as a packager, it only means more work for no gain, since the content is the same. So as an experience result of the 1.7 series and to avoid wasting time for everyone, i strongly object against doing empty releases again. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eolian meta-data parsing, episode 3 (The Ragel Strikes Back)
2013/12/9 Yakov Goldberg yako...@samsung.com
On 12/08/2013 01:26 PM, Davide Andreoli wrote:
2013/12/8 Yakov Goldberg yako...@samsung.com
So, as soon as Ragel Strikes Back
here is Elm_Image in Jeremy's format.
http://pastebin.com/xptFf6y0
Properties and Methods are as Jeremy described.
And in the end you can also find implements and signals.
Just one suggestion: lets move implements content into properties
and methods:
methods{
some_method {
...
};
Evas_Smart :: show;
};
...only some comments about properties.
If we want to override , only setter or getter we need to specify set
or get.
If you have better ideas about syntax, please suggest.
properties{
some_prop {
...
};
Evas_Object :: color;
Evas_Object :: size :: set;
Evas_Object :: visibility :: get;
};
==
Some additional question.
Here is some part of ElmFileselector.eo file.
You can see selected_set and selected_get are described as methods.
Why? Because I generate, this eo file, by parsing descriptions of eo
classes.
If there are two functions which have:
- the same name with set/get suffix;
- the same number of parameters;
- all parameters are in for set
- all parameters are out for get
it will be described as property; (or only_set/only_get property)
if one of these rules fails, functions will be generated as methods.
Because of legacy, selected_set func returns, so here I generate it as
method.
methods {
selected_set {
/*@ Set, programmatically, the currently selected
file/directory
in the given file selector widget */
return Eina_Bool;
params {
in const char* path; /*@ */
};
};
selected_get {
/*@ Get the currently selected item's (full) path, in the
given
file the given file selector widget */
return const char*;
params {
};
};
}
But maybe, as soon as it is almost property (only one ret gets in
the
way here), we can describe it as property, which returns some value.
selected: {
set: {
return : Eina_Bool,
comment: Set, programmatically, the currently selected
file/directory in the given file selector widget
},
get: {
comment: Get the currently selected item's (full) path, in
the given file the given file selector widget
},
parameters: [
{
path: [const char*, ]
}
]
},
We will generate Eo and C - legacy functions as they are now.
eo macro: selected_set EO_TYPECHECK (path, const char*) EO_TYPECHECK
(ret, Eina_Bool *)
eo macro: selected_get EO_TYPECHECK (path, const char**)
legacy: Eina_Bool elm_fileselector_selected_set(Eo * obj, const char*
path)
legacy: const char * elm_fileselector_selected_get(Eo * obj)
And C++, python and other bindings will ignore ret in setters/getters
and
use it as property:
fileselector.path = /root/some/path/filename
So the question is:
should we treat it like this, or leave it as methods?
Yakov.
Hi all,
I have one main concern about the generation of bindings using the eo
file:
how we like to manage complex types (see Eina_List) in the target
language?
(python for example)
As the py bindings are implemented now (and I really like this!), we do
not
provide bindings for eina types, but we convert to the corresponding
python
type for the user.
For example:
Elm_Map {
{
property {
overlays {
get {
/*@ get a list of all the overlays in the map */
};
params {
Eina_List overlays; /*@ actually a list of Elm_Map_Overlay
objs
*/
};
};
};
};
In this case we don't know what the eina_list overlays contain thus we
cannot automatically convert to the corresponding python list of object.
Other example of complex types I found to be used in the current bindings
are C array (usually with strings inside).
How can we solve this?
we could add the content of the complex type in the eo files:
params {
Eina_List(Elm_Map_Overlay) overlays; /*@ ...or a different syntax
*/
};
params {
Eina_List(char *) names; /*@ ...for an eina list of strings */
};
Thanks for comments.
Looks like it's good idea to do smth like that. But some conversion API
from
Elm_Map_Overlay to python object should be implemented.
but this can be tricky for more complex types, how we describe a C array
of
strings?
Could you please give an example, which API does use it?
void elm_calendar_weekdays_names_set (Evas_Object *obj, const char
*weekdays[])
const char **
[EGIT] [core/enlightenment] annotated tag v0.18.0-rc1 created
stefan pushed a change to annotated tag v0.18.0-rc1 in repository core/enlightenment. at 32eeb33858 (tag) tagging 27d607d8639a303226673cd14de886e70b59b397 (commit) replaces v0.18.0-alpha4 tagged by Stefan Schmidt on Mon Dec 9 21:24:57 2013 +0100 - Log - v0.18.0-rc1 Boris Faure (2): update .mailmap update .mailmap Carsten Haitzler (9): double free coverty complaint - it doesn't know the action re-execs e_sys - address security concerns with environment and gdb e_sys - address security concerns with environment - more bump randr settings up 1 more epoch for e18 release e_sys - fix busy spin problem with security clamp-down comp - disable grab by default due to it causing erratic rendering gdb crashdump - restore old e_sys magic into e_start comp - remove sync support in comp - it should be off by default anyway. backlight - save after actions change backlight too. Jérémy Zurcher (2): mixer: load module config in e_modapi_init(), same as others mixer: add option disable_pulseaudio Mike Blumenkrantz (32): recover option to set startup splash and stick it into theme config dialog set initial value of show_splash in theme config dialog fix stringshare magic failure in theme dialog, unbreaks apply button improve theme apply to actually apply startup splash setting... remove an old case of raise on focus from focus revert fix winlist first selection check fix pulse mixer startup remove some eldbus stragglers from pulse mixer only try to start pulseaudio once improve upgrade path for removal of raise on focus option fix menu race condition crash related to screen edges add more borderless checks for shape cutting to catch weirdly-set borderless windows raise fullscreen borders before entering nocomp move dnd input window free to drag free function fix evry crash when switching views only force custom icon view for efm desktops when creating a fileman path for the first time unify efm icon positioning code ensmallen efm icon event area bugfix: don't add NoDisplay .desktop files to evry apps view remove ability to alter gadgets in EFM toolbars tons of cl/news updates :( remove call to useless gadcon function move and unify a gadcon drag block remove more calls to useless gadcon function subtract zone position from initial gadcon client drag coordinates don't try to apply gadcon container geometry when injecting finally fix bug where gadgets on shelves would randomly reorder during drags rc1 will go out sometime soon unbreak menu dnd improve efm popup display with multiple monitors remove unnecessary file remove physics module Olaf Conradi (1): When changing the gravity setting, one cannot reset it to 0, as the setting is Sebastian Dransfeld (11): Check return value from mkdir reduce indent level break out of while, not return Use strncpy instead of strcpy Initialize siginfo_t Fix 03d50e9546ced3f7c135cad6617f4e397a024fce Remove assignment to unused variable bd-zone is always set It is correct to fall through here Find correct border under pointer e: handle e_util_head_exec display env --- No new revisions were added by this update. --
[EGIT] [core/evas_generic_loaders] annotated tag v1.8.1 created
stefan pushed a change to annotated tag v1.8.1 in repository core/evas_generic_loaders. at 27b4f0499a (tag) tagging db5cb8326e4c9864bb1354f291ec9911567c2089 (commit) replaces v1.8.0 tagged by Stefan Schmidt on Mon Dec 9 21:28:54 2013 +0100 - Log - v1.8.1 Mike Blumenkrantz (4): bugfix: support gstreamer 0.10 and 1.0 Revert bugfix: support gstreamer 0.10 and 1.0 bugfix: unbreak gstreamer plugin bugfix: add a typefind to gstreamer plugin pipeline Stefan Schmidt (1): release: UPdate NEWS and bump version for 1.8.1 release --- No new revisions were added by this update. --
[EGIT] [core/elementary] annotated tag v1.8.1 created
stefan pushed a change to annotated tag v1.8.1 in repository core/elementary. at df59181e87 (tag) tagging cf46c6dfb5c37e5f4e2d6b8f3a1d6136bcb289bf (commit) replaces v1.8.0 tagged by Stefan Schmidt on Mon Dec 9 21:30:02 2013 +0100 - Log - v1.8.1 Carsten Haitzler (1): theme - fix evrything theme elements for enlightenment Cedric BAIL (2): elementary: shuttup autotools. naviframe: clip the shadow also. Daniel Juyung Seo (4): NEWS: added the latest version marker for NEWS. gengrid: refactoring of commit 7187a3124fc6c169fcfec2c249a1fd483481fbba. elm_interface_scrollable.c: reset momentum_animator to null when return cancel from the animator. elm_interface_scrollable.c: fix scroller page flick calculation roundup routine. Mike Blumenkrantz (2): add 1.8 release to changelog fix mouse eventing in e border theme Sanghyeon Lee (1): [Gengrid] Enable Scroll To Type when item bring in or show region. Stefan Schmidt (1): release: Update NEWS and bump version for 1.8.1 release WooHyun Jung (1): elementary/elm_button.c : Change the timing of signal_emitting. --- No new revisions were added by this update. --
[EGIT] [core/efl] annotated tag v1.8.2 created
stefan pushed a change to annotated tag v1.8.2 in repository core/efl. at 887fe896de (tag) tagging 22560c63ea84af333d4ebb357e96761be0b9de10 (commit) replaces v1.8.0 tagged by Stefan Schmidt on Mon Dec 9 21:33:03 2013 +0100 - Log - v1.8.2 Carsten Haitzler (5): FUCK - remove logic to silently add -release names to libtool builds v1.8.1 efreet - protect efreetd from recursing too far to save overhead and mem efreet - fix recusrion checks need to pop as well as push. evas - fix overdraw + too many rects problem found in some expedite tests Cedric BAIL (5): evas: bugfix in evas_render of not maintaining changed flags on object correctly. Revert eina: check if the complete hash match before checking if the key match during children walk. evas: fix loader to properly define _XOPEN_SOURCE for Solaris. eina: increase hash matching inside of Eina_Hash. evil: use the right ifdef. Christopher Michael (3): Add code to deal with min, max, step, aspect, and base sizes. Add common function prototype for setting ecore_evas aspect ratio Set engine aspect function pointer Daniel Juyung Seo (3): NEWS: added 1.8.1 NEWS entry. ecore ecore_x_e: check 0 and -1 for ecore_x_window_prop_card32_get() return value which mean fail. ecore ecore_glib.c: fixed documentation about glib integration always configure option. Rafael Antognolli (5): evas/wayland_shm: Don't use a global var to store the sent buffer. ecore_evas/wayland: Implement ecore_evas_withdrawn_set. ecore_evas/wayland_egl: Unset the surface on window hide. ecore_evas/wayland: Add a function to cleanup the frame callback. Backport branch 'withdrawn' into efl-1.8 Stefan Schmidt (1): release: Update NEWS and bump version for efl 1.8.2 release Vostokov Sergey (1): evas - Clip mark performance improvement --- No new revisions were added by this update. --
[EGIT] [website/www] master 01/01: downloads: Update links for latest stable releases
stefan pushed a commit to branch master. http://git.enlightenment.org/website/www.git/commit/?id=0294a948260e53f04e66c14e50155b998653647d commit 0294a948260e53f04e66c14e50155b998653647d Author: Stefan Schmidt ste...@datenfreihafen.org Date: Mon Dec 9 21:41:25 2013 +0100 downloads: Update links for latest stable releases --- public_html/p/download/en-body | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/public_html/p/download/en-body b/public_html/p/download/en-body index 40598b2..ddf9e77 100644 --- a/public_html/p/download/en-body +++ b/public_html/p/download/en-body @@ -71,18 +71,18 @@ td class='main' ?php frame1(width=100%);? - div class=mainpbEFL/b em1.8.1/em/pp + div class=mainpbEFL/b em1.8.2/em/pp Core libraries. /pp align=right?php blinkdl(i/dl.png, DOWNLOAD, - http://download.enlightenment.org/rel/libs/efl/efl-1.8.1.tar.gz; + http://download.enlightenment.org/rel/libs/efl/efl-1.8.2.tar.gz; );?/p/div ?php frame2();? ?php frame1(width=100%);? - div class=mainpbElementary/b em1.8.0/em/pp + div class=mainpbElementary/b em1.8.1/em/pp Widget set/toolkit. /pp align=right?php blinkdl(i/dl.png, DOWNLOAD, - http://download.enlightenment.org/rel/libs/elementary/elementary-1.8.0.tar.gz; + http://download.enlightenment.org/rel/libs/elementary/elementary-1.8.1.tar.gz; );?/p/div ?php frame2();? @@ -95,10 +95,10 @@ ?php frame2();? ?php frame1(width=100%);? - div class=mainpbEvas Generic Loaders/b em1.8.0/em/pp + div class=mainpbEvas Generic Loaders/b em1.8.1/em/pp Extra image decoders. /pp align=right?php blinkdl(i/dl.png, DOWNLOAD, - http://download.enlightenment.org/rel/libs/evas_generic_loaders/evas_generic_loaders-1.8.0.tar.gz; + http://download.enlightenment.org/rel/libs/evas_generic_loaders/evas_generic_loaders-1.8.1.tar.gz; );?/p/div ?php frame2();? --
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On 12/10/2013 12:07 AM, Michael Blumenkrantz wrote: On Mon, 9 Dec 2013 14:23:21 +0100 Stefan Schmidt ste...@datenfreihafen.org wrote: Hello. On Mon, 2013-12-09 at 12:26, Thanatermesis wrote: From a packagers perspective it would be great if we could keep the efl, elementary and evas/emotion_generic_loaders version numbers the same even if there are no changes, the same as we did for the 1.7 tree. I'll leave it for you guys to decide though. + 1 This counts not all all for me. If you have reasons let people known them. +1 has the same status as an empty mail for me. regards Stefan Schmidt Agree I'm guessing that in the future we'll continue to merge things. Elementary will probably get merged into the EFL tree, and maybe emotion generic will merge into the evas generic tree. It's annoying to have to upgrade (for users and packagers) packages when nothing has changed except a version number, but it does make bug filing/fixing easier. I guess i should point out that with our build system it takes less then 2 minutes to bump a version number, so as i found the other night its easier for me if they are all the same number as i spent more time going back and looking at which package needed which version then it would have taken to package the one package that hadn’t changed. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On Mon, Dec 09, 2013 at 08:21:41PM +0100, Thomas Sachau wrote: How does it make packagers life easier, if there are empty version bumps, which also need to be followed by the package manager? From my experience as a packager, it only means more work for no gain, since the content is the same. So as an experience result of the 1.7 series and to avoid wasting time for everyone, i strongly object against doing empty releases again. As meta-efl (OpenEmbedded layer) maintainer I agree, better to have different, but correct versions, than rebuilding the same source multiple times. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] EFL 1.8.2, Elementary 1.8.1, evas generic loaders and Enlightenment rc1 releases
We are pleased to announce that our second set of stable updates for the 1.8 series are now available for download at: http://download.enlightenment.org/rel The relevant components are: http://download.enlightenment.org/rel/libs/efl/efl-1.8.2.tar.gz http://download.enlightenment.org/rel/libs/elementary/elementary-1.8.1.tar.gz http://download.enlightenment.org/rel/libs/evas_generic_loaders/evas_generic_loaders-1.8.1.tar.gz If you are compiling the above, please compile them in the following order: efl elementary evas_generic_loaders If you have an existing EFL or Elementary install, you may wish to delete its header files and libraries before building the above. In addition we have also put up a first release candidate of Enlightenment 0.18 available here: http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.18.0-rc1.tar.gz Please file bug tasks on http://phab.enlightenment.org and we will address them as best as possible for release. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On Tue, Dec 10, 2013 at 07:14:18AM +1030, Simon wrote: On 12/10/2013 12:07 AM, Michael Blumenkrantz wrote: I'm guessing that in the future we'll continue to merge things. Elementary will probably get merged into the EFL tree, and maybe emotion generic will merge into the evas generic tree. It's annoying to have to upgrade (for users and packagers) packages when nothing has changed except a version number, but it does make bug filing/fixing easier. I guess i should point out that with our build system it takes less then 2 minutes to bump a version number, so as i found the other night its easier for me if they are all the same number as i spent more time going back and looking at which package needed which version then it would have taken to package the one package that hadn’t changed. For distributions where the users are responsible to build the stuff it's really bad. It takes 2 minutes for me to update the recipes in meta-efl for new version, but it will take many hours for each user of these metadata to recreate binaries with updated version, but otherwise exactly the same content. I don't see how it makes bug tracking better, because if someone reports bug against 1.8.2 which is exactly the same source as 1.8.1, then it looks like new issue was introduced in 1.8.2, but it's probably just something overlooked when the same 1.8.1 was being used in the distro. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Python-EFL 1.8.0 released
On Sun, Dec 08, 2013 at 09:46:50PM +0200, Kai Huuhko wrote: = Python-EFL 1.8.0 release = We are pleased to announce that **Python-EFL** 1.8.0 is now released and available for download. == Download == http://download.enlightenment.org/rel/bindings/python/python-efl-1.8.0.tar.gz Hi, just for sake of consistency with other releases, would you mind to add .bz2 archive? -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/enlightenment] master 01/01: cl/news for physics module removal
discomfitor pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=6bcdc4efab3cf3aa2265c9e903edeb48dc876468 commit 6bcdc4efab3cf3aa2265c9e903edeb48dc876468 Author: discomfitor michael.blumenkra...@gmail.com Date: Mon Dec 9 16:03:58 2013 -0500 cl/news for physics module removal --- ChangeLog | 4 NEWS | 1 + 2 files changed, 5 insertions(+) diff --git a/ChangeLog b/ChangeLog index 88725b3..1636c3d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2013-12-09 Mike Blumenkrantz + +* removed physics module + 2013-12-04 Mike Blumenkrantz * Fixed cases where gadgets would sometimes reorder randomly on shelves diff --git a/NEWS b/NEWS index 50bd8c6..8fa52fc 100644 --- a/NEWS +++ b/NEWS @@ -84,6 +84,7 @@ Removed: * HAL support for filemanager * raise on focus config option * ability to alter gadgets in EFM toolbars +* physics module Improvements: * mixer shows more channels when using alsa subsystem and correctly disable controls --
[EGIT] [core/enlightenment] master 01/01: hide teamwork popups on desk flip
discomfitor pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=c0a1d4104f49730018e34c8d0ac03a0eb1cd410e
commit c0a1d4104f49730018e34c8d0ac03a0eb1cd410e
Author: Mike Blumenkrantz zm...@samsung.com
Date: Mon Dec 9 17:05:23 2013 -0500
hide teamwork popups on desk flip
---
src/modules/teamwork/e_mod_tw.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/src/modules/teamwork/e_mod_tw.c b/src/modules/teamwork/e_mod_tw.c
index 68a026d..d224452 100644
--- a/src/modules/teamwork/e_mod_tw.c
+++ b/src/modules/teamwork/e_mod_tw.c
@@ -1113,12 +1113,10 @@ tw_show_local_file(const char *uri)
e_object_data_set(E_OBJECT(tw_mod-pop), eina_stringshare_add(uri));
}
-static Eina_Bool
-focus_out(void *data EINA_UNUSED, int type EINA_UNUSED,
E_Event_Border_Focus_Out *ev EINA_UNUSED)
+static void
+tw_handler_hide(void)
{
- if (!tw_mod-pop) return ECORE_CALLBACK_RENEW;
- if (e_config-focus_policy == E_FOCUS_CLICK) return ECORE_CALLBACK_RENEW;
- if (tw_mod-force || tw_mod-sticky) return ECORE_CALLBACK_RENEW;
+ if (tw_mod-force || tw_mod-sticky) return;
if (tw_config-mouse_out_delay)
{
if (tw_hide_timer) ecore_timer_reset(tw_hide_timer);
@@ -1127,6 +1125,20 @@ focus_out(void *data EINA_UNUSED, int type EINA_UNUSED,
E_Event_Border_Focus_Out
else
tw_hide(NULL);
tw_mod-force = 0;
+}
+
+static Eina_Bool
+desk_show(void *data EINA_UNUSED, int type EINA_UNUSED,
E_Event_Border_Focus_Out *ev EINA_UNUSED)
+{
+ if (tw_mod-pop) tw_handler_hide();
+ return ECORE_CALLBACK_RENEW;
+}
+
+static Eina_Bool
+focus_out(void *data EINA_UNUSED, int type EINA_UNUSED,
E_Event_Border_Focus_Out *ev EINA_UNUSED)
+{
+ if (e_config-focus_policy == E_FOCUS_CLICK) return ECORE_CALLBACK_RENEW;
+ if (tw_mod-pop) tw_handler_hide();
return ECORE_CALLBACK_RENEW;
}
@@ -1200,6 +1212,7 @@ e_tw_init(void)
E_LIST_HANDLER_APPEND(handlers, ECORE_CON_EVENT_URL_PROGRESS,
download_media_status, tw_mod);
E_LIST_HANDLER_APPEND(handlers, ECORE_CON_EVENT_URL_DATA,
download_media_data, tw_mod);
E_LIST_HANDLER_APPEND(handlers, E_EVENT_BORDER_FOCUS_OUT, focus_out,
tw_mod);
+ E_LIST_HANDLER_APPEND(handlers, E_EVENT_DESK_SHOW, desk_show, tw_mod);
tw_mod-media =
eina_hash_string_superfast_new((Eina_Free_Cb)download_media_free);
return 1;
--
[EGIT] [core/enlightenment] master 01/01: set pass events on efm icon objects
discomfitor pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=ec156f71aafc9f1242fe5357c2a13ff0d3e8 commit ec156f71aafc9f1242fe5357c2a13ff0d3e8 Author: Mike Blumenkrantz zm...@samsung.com Date: Mon Dec 9 17:38:01 2013 -0500 set pass events on efm icon objects we don't get events from the theme any more, so ensure that edje isn't grabbing events randomly T377 --- src/bin/e_fm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/bin/e_fm.c b/src/bin/e_fm.c index e2c509a..11c95cc 100644 --- a/src/bin/e_fm.c +++ b/src/bin/e_fm.c @@ -4829,6 +4829,7 @@ _e_fm2_icon_realize(E_Fm2_Icon *ic) evas_event_freeze(e); ic-obj = edje_object_add(e); edje_object_freeze(ic-obj); + evas_object_pass_events_set(ic-obj, 1); evas_object_smart_member_add(ic-obj, ic-sd-obj); ic-rect = evas_object_rectangle_add(e); evas_object_color_set(ic-rect, 0, 0, 0, 0); --
[EGIT] [core/enlightenment] master 01/01: backlight - companion backlight fix patch actually changes config level
raster pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=98e503595702c4e03ac1c495659f7e84ed68dd3b commit 98e503595702c4e03ac1c495659f7e84ed68dd3b Author: Carsten Haitzler (Rasterman) ras...@rasterman.com Date: Tue Dec 10 08:40:46 2013 +0900 backlight - companion backlight fix patch actually changes config level goes with 9ce8d91f6d54afac67f7653700205ee24206e3a2. --- src/bin/e_actions.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/bin/e_actions.c b/src/bin/e_actions.c index 182dd19..b767ee4 100644 --- a/src/bin/e_actions.c +++ b/src/bin/e_actions.c @@ -2855,6 +2855,7 @@ ACT_FN_GO(backlight_set, ) } e_backlight_mode_set(zone, E_BACKLIGHT_MODE_NORMAL); e_backlight_level_set(zone, ((double)v / 100.0), -1.0); + e_config-backlight.normal = e_backlight_level_get(zone); e_config_save_queue(); } @@ -2866,6 +2867,7 @@ ACT_FN_GO(backlight_adjust, ) v = atoi(params); e_backlight_mode_set(zone, E_BACKLIGHT_MODE_NORMAL); e_backlight_level_set(zone, e_backlight_level_get(zone) + ((double)v / 100.0), -1.0); + e_config-backlight.normal = e_backlight_level_get(zone); e_config_save_queue(); } --
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On Mon, 9 Dec 2013 14:37:58 +0100 Stefan Schmidt ste...@datenfreihafen.org said: Hello. On Mon, 2013-12-09 at 14:28, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 07:11, Jeff Hoogland wrote: I'm not sure this is the case - just like Simon alpha4 builds fine here. Really strange. I reviewd the commits that gone into rc1 and efl 1.8.2 but I can't see anything that broke this. Also its building fine for me and on jenkins. At any rate I guess I'll try just disabling physics then. Please do. The physics module was not really maintained and Mike just removed it so it will be gone in the next rc and the final release anyway. Having it disabled manually for the rc1 should be ok for the people encountering this problem. Does that sound good for you guys? To avoid any more confusion on this Mike and I decided that I will prepare a new rc1 tarball with the removal commit and upload it. Will send a mail once its up. how about.. rc2? :) regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Exquisite source code
On Mon, 09 Dec 2013 14:09:37 + Tom Hacohen tom.haco...@samsung.com said: On 01/12/13 19:00, Thanatermesis wrote: Exquisite was a very nice app, seems like it was only SVN but now I don't found it, can we have it back on GIT ? Before I migrate it I need to know: Is it still actively maintained? (I don't know if I should migrate it or not). If I should migrate it, please also include a description summary and a suggested classification (like the others at git.e.org). it's up for download on download.enlightenment.org - it just hasn't needed any new features because no one is pushing it. it probably should get some at some point - like support for evas drm/kms stuff that will come - but it's not there yet, so no need to update. fb will do for now. also it likely would/should update to support systemd stuff as it s intended to integrate into a bootup, but no one is using it currently. someone needs to go integrate it into a distro to actually make use of it somewhere. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On Tue, 10 Dec 2013 08:51:50 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 9 Dec 2013 14:37:58 +0100 Stefan Schmidt ste...@datenfreihafen.org said: Hello. On Mon, 2013-12-09 at 14:28, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 07:11, Jeff Hoogland wrote: I'm not sure this is the case - just like Simon alpha4 builds fine here. Really strange. I reviewd the commits that gone into rc1 and efl 1.8.2 but I can't see anything that broke this. Also its building fine for me and on jenkins. At any rate I guess I'll try just disabling physics then. Please do. The physics module was not really maintained and Mike just removed it so it will be gone in the next rc and the final release anyway. Having it disabled manually for the rc1 should be ok for the people encountering this problem. Does that sound good for you guys? To avoid any more confusion on this Mike and I decided that I will prepare a new rc1 tarball with the removal commit and upload it. Will send a mail once its up. how about.. rc2? :) I don't want to drag this process out unnecessarily. regards Stefan Schmidt -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On Mon, 9 Dec 2013 15:11:31 +0100 Stefan Schmidt ste...@datenfreihafen.org said: Hello. On Mon, 2013-12-09 at 20:48, Simon wrote: On 12/09/2013 08:33 PM, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 20:05, Simon wrote: On 12/09/2013 05:40 PM, Stefan Schmidt wrote: Hello. On Sun, 2013-12-08 at 14:58, Jeff Hoogland wrote: Just wanted to confirm emotion generic players isn't getting a 1.8.1 release. Confirmed. Emotion generic players had not a single commit since 1.8.0. Nothing to release. regards Stefan Schmidt From a packagers perspective it would be great if we could keep the efl, elementary and evas/emotion_generic_loaders version numbers the same even if there are no changes, the same as we did for the 1.7 tree. I'll leave it for you guys to decide though. I was pondering about that. For 1.7.x we had way more tarballs for one release. Due to the merged efl tree this really got down. Would you expect emotion generic player release tarballs for 1.8.1 and 1.8.2 even when not a single commit hit that repo? We can switch back to that model but I'm not a fan of doing empty releases just to stay in sync for the version number. It would only heppen from 1.8.3 though. Skipping a minor release for everything but efl. IT will always be out of sync with e18 in any case. In sumarry I have no hard feeling in any direction. :) regards Stefan Schmidt I wasn't much of a fan of the empty releases at first either, but realistic the enlightenment foundation libraries are efl, elementary and e*_generic_loaders, its just some components are built separately because its easier and others due to licensing. From a user perspective particularly in regards to filing bugs it makes it easier if they all follow the same versioning, especially if efl and elementary are out of sync. We did it with 1.7.x and its seems to make packagers life easier as well as versions for bug reports, etc. So be it. From 1.8.3 I will do collective releases for efl, elm, evas and emotion generic loaders. Even if the specific tarballs have no changes. we did it for efl 1.8 because we had like 12+ packages and we often depended on a bugfix in one efl pkg to make another work right. now our lives are MUCH simpler. :) the generic loaders + players pkgs are small and dont get a lot of traffic. we likely could merge those into some single efl-loaders tree with ease. that'd be wise as emotion and evas are now together too in efl. at this stage elementary will be a hard nut to merge primarily because of elm_web and webkit. we need to get our support straight there. what we do is undecided at the moment, but the likeliest scenario is that we import an entire webkit tree into EFL. it's basically the only way to make it work - specially cherry pick the right webkit version that happens to work and then import it and every now and again when a known tested webkit tree update works.. import that wholesale. and for those who don't know. webkit-efl requires efl. elementary optionally requires webkit-efl. we can't merge elementary and build elm_web support if elm is merged into efl as webkit-efl can't be built until you have efl and not efl requires webkit-efl... :S -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eolian meta-data parsing, episode 3 (The Ragel Strikes Back)
On Mon, 9 Dec 2013 21:08:32 +0100 Davide Andreoli d...@gurumeditation.it said:
2013/12/9 Yakov Goldberg yako...@samsung.com
On 12/08/2013 01:26 PM, Davide Andreoli wrote:
2013/12/8 Yakov Goldberg yako...@samsung.com
So, as soon as Ragel Strikes Back
here is Elm_Image in Jeremy's format.
http://pastebin.com/xptFf6y0
Properties and Methods are as Jeremy described.
And in the end you can also find implements and signals.
Just one suggestion: lets move implements content into properties
and methods:
methods{
some_method {
...
};
Evas_Smart :: show;
};
...only some comments about properties.
If we want to override , only setter or getter we need to specify set
or get.
If you have better ideas about syntax, please suggest.
properties{
some_prop {
...
};
Evas_Object :: color;
Evas_Object :: size :: set;
Evas_Object :: visibility :: get;
};
==
Some additional question.
Here is some part of ElmFileselector.eo file.
You can see selected_set and selected_get are described as methods.
Why? Because I generate, this eo file, by parsing descriptions of eo
classes.
If there are two functions which have:
- the same name with set/get suffix;
- the same number of parameters;
- all parameters are in for set
- all parameters are out for get
it will be described as property; (or only_set/only_get property)
if one of these rules fails, functions will be generated as methods.
Because of legacy, selected_set func returns, so here I generate it as
method.
methods {
selected_set {
/*@ Set, programmatically, the currently selected
file/directory
in the given file selector widget */
return Eina_Bool;
params {
in const char* path; /*@ */
};
};
selected_get {
/*@ Get the currently selected item's (full) path, in the
given
file the given file selector widget */
return const char*;
params {
};
};
}
But maybe, as soon as it is almost property (only one ret gets in
the
way here), we can describe it as property, which returns some value.
selected: {
set: {
return : Eina_Bool,
comment: Set, programmatically, the currently selected
file/directory in the given file selector widget
},
get: {
comment: Get the currently selected item's (full) path, in
the given file the given file selector widget
},
parameters: [
{
path: [const char*, ]
}
]
},
We will generate Eo and C - legacy functions as they are now.
eo macro: selected_set EO_TYPECHECK (path, const char*) EO_TYPECHECK
(ret, Eina_Bool *)
eo macro: selected_get EO_TYPECHECK (path, const char**)
legacy: Eina_Bool elm_fileselector_selected_set(Eo * obj, const char*
path)
legacy: const char * elm_fileselector_selected_get(Eo * obj)
And C++, python and other bindings will ignore ret in setters/getters
and
use it as property:
fileselector.path = /root/some/path/filename
So the question is:
should we treat it like this, or leave it as methods?
Yakov.
Hi all,
I have one main concern about the generation of bindings using the eo
file:
how we like to manage complex types (see Eina_List) in the target
language?
(python for example)
As the py bindings are implemented now (and I really like this!), we do
not
provide bindings for eina types, but we convert to the corresponding
python
type for the user.
For example:
Elm_Map {
{
property {
overlays {
get {
/*@ get a list of all the overlays in the map */
};
params {
Eina_List overlays; /*@ actually a list of Elm_Map_Overlay
objs
*/
};
};
};
};
In this case we don't know what the eina_list overlays contain thus we
cannot automatically convert to the corresponding python list of object.
Other example of complex types I found to be used in the current bindings
are C array (usually with strings inside).
How can we solve this?
we could add the content of the complex type in the eo files:
params {
Eina_List(Elm_Map_Overlay) overlays; /*@ ...or a different syntax
*/
};
params {
Eina_List(char *) names; /*@ ...for an eina list of strings */
};
Thanks for comments.
Looks like it's good idea to do smth like that. But some conversion API
from
Elm_Map_Overlay to python object should be implemented.
but this can be
Re: [E-devel] What is a withdrawn window?
On Mon, 9 Dec 2013 12:00:32 -0500 Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Mon, 9 Dec 2013 16:53:38 + Eoff, Ullysses A ullysses.a.e...@intel.com wrote: The ELM docs don't explain the concept... nor does a Google search AFAICT. So what is it? Currently, setting a window as withdrawn appears to just hide it (i.e. elm_win_withdrawn_set(..., EINA_TRUE))... so what's the point, why not use evas_object_hide(...) instead? Next, if we call evas_object_show(...) on a withdrawn window, should it be unwithdrawn too? This is how it works right now on X11 engine, but is that correct? Or should you be required to call elm_win_withdrawn_set(..., EINA_FALSE)? Essentially, I'm asking because I want to make sure it's consistent (which it's not) and correct across engines (e.g. X11 vs. Wayland), or should it be? As Tom basically stated on IRC, this probably shouldn't even be logic that is specific to any engine, rather it's a general thing. Finally, the clear definition of a withdrawn window should be added to the docs. U. Artie withdrawn is the same as iconify, except that the application may decide to free/destroy/reduce functionality in order to conserve system resources. it's like how android apps never close but also aren't in the foreground or using noticeable cpu/battery. actually no. it's not the same as iconified. its basically a window that is no longer managed at all by the window manager. it has been widthdrawn. it is the same as just hide()ing it. http://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] Terminology 0.4.0 is out!
On Mon, 9 Dec 2013 08:24:26 -0500 Shawn Haworth shawn...@gmail.com said: On Sun, Dec 8, 2013 at 10:39 AM, Boris Faure bo...@fau.re wrote: We are pleased to announce the release of Terminology 0.4 You can download the tarball either as [1]terminology-0.4.0.tar.gz or as [2]terminology-0.4.0.tar.bz2. This release features: * text reflow on resize, * full 256 colors support, * improved terminal compatibility, * improved selection handling, * backscroll compression to reduce memory usage, What's the compression ratio? How much memory can I expect to be unused compared to 0.3.0? Thanks! i measured about 60% savings of backscroll memory on average. (si it was 40% its original size). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On Mon, 9 Dec 2013 19:02:50 -0500 Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Tue, 10 Dec 2013 08:51:50 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 9 Dec 2013 14:37:58 +0100 Stefan Schmidt ste...@datenfreihafen.org said: Hello. On Mon, 2013-12-09 at 14:28, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 07:11, Jeff Hoogland wrote: I'm not sure this is the case - just like Simon alpha4 builds fine here. Really strange. I reviewd the commits that gone into rc1 and efl 1.8.2 but I can't see anything that broke this. Also its building fine for me and on jenkins. At any rate I guess I'll try just disabling physics then. Please do. The physics module was not really maintained and Mike just removed it so it will be gone in the next rc and the final release anyway. Having it disabled manually for the rc1 should be ok for the people encountering this problem. Does that sound good for you guys? To avoid any more confusion on this Mike and I decided that I will prepare a new rc1 tarball with the removal commit and upload it. Will send a mail once its up. how about.. rc2? :) I don't want to drag this process out unnecessarily. there are still bugs being filed on phab... and i was more making the point that re-spinning a tarball with the same name/version is not a good thing. which rc1 do you have? i don't know. rc1!. :) if there is a re-spin.. at least call it rc2... :) i could have done a re spin for 1.8.1 (another 1.8.0) as no code changed - it was a m4 macro doing the totally unexpected. but i had to do 1.8.1 :( -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] Terminology 0.4.0 is out!
On Mon, 9 Dec 2013 19:28:43 -0500 Shawn Haworth shawn...@gmail.com said: On Mon, Dec 9, 2013 at 7:08 PM, Carsten Haitzler ras...@rasterman.com wrote: On Mon, 9 Dec 2013 08:24:26 -0500 Shawn Haworth shawn...@gmail.com said: On Sun, Dec 8, 2013 at 10:39 AM, Boris Faure bo...@fau.re wrote: We are pleased to announce the release of Terminology 0.4 You can download the tarball either as [1]terminology-0.4.0.tar.gz or as [2]terminology-0.4.0.tar.bz2. This release features: * text reflow on resize, * full 256 colors support, * improved terminal compatibility, * improved selection handling, * backscroll compression to reduce memory usage, What's the compression ratio? How much memory can I expect to be unused compared to 0.3.0? Thanks! i measured about 60% savings of backscroll memory on average. (si it was 40% its original size). In the frozen tundra of the Northeast US (New England) I can only max out my machine at 2GB ram (DDR Pentium 4). Running LXDE + Terminology w/ 10k scroll buffer + chromium-browser (or bsu when i'm bored) + tmux + vim = heavy swappage. :| I'm thinking about switching my desktop environment to Ratpoison so I can stay in hard memory. Either that or shit-can Terminology for lxterminal. chromium is what is really eating all your memory. you can fiddle about at the edges, but that's your real problem. do some memory profiling some time. fyi i have a test machine - pentium-m @ 600mhz, 512m ram. runs e18, terminology etc. just fine. even chromium as long as i keep it to simple stuff and don't use multiple tabs. no gpu either. also one thing that hurts you is using lxde. lxde will have its own libraries/internals, where e re-uses the same efl code that it shares with terminology. scrollbuffers are not that expensive really. it's 8 bytes per char and only the chars on each line until the last non-blank one are actually allocated. so assume 50% on average of every line in scrollback is used, a full 10k scrollback before compression will cost about 3.2m. with compression that comes down to 1.3m also remember if you go back through scrollback terminology has to uncompress as it goes and memory will balloon out again until it gets to re-compressing it again (when it goes idle). that's one terminal. also you may want to use the multiple instances, one process option under behavior. it only uses a single terminology process for all terminals. fyi terminology uses fairly little memory on its own - it's mostly efl and other shared libs. if everything is re-using the same ones the cost drops a lot. Don't get me wrong, I love e17 and Terminology but it's too expensive for me to run at the moment (wallet + memory wise). I miss the good ole' days of e16 with gkrellm. My GPU was more expensive than my rig. (VGA compatible controller: NVIDIA Corporation NV35 [GeForce FX 5900] (rev a1)) -- woooh doggy. Anyway, keep up the fantastic coding. Love you guys and everything you stand for. Shawn -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On Tue, 10 Dec 2013 09:34:57 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 9 Dec 2013 19:02:50 -0500 Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Tue, 10 Dec 2013 08:51:50 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 9 Dec 2013 14:37:58 +0100 Stefan Schmidt ste...@datenfreihafen.org said: Hello. On Mon, 2013-12-09 at 14:28, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 07:11, Jeff Hoogland wrote: I'm not sure this is the case - just like Simon alpha4 builds fine here. Really strange. I reviewd the commits that gone into rc1 and efl 1.8.2 but I can't see anything that broke this. Also its building fine for me and on jenkins. At any rate I guess I'll try just disabling physics then. Please do. The physics module was not really maintained and Mike just removed it so it will be gone in the next rc and the final release anyway. Having it disabled manually for the rc1 should be ok for the people encountering this problem. Does that sound good for you guys? To avoid any more confusion on this Mike and I decided that I will prepare a new rc1 tarball with the removal commit and upload it. Will send a mail once its up. how about.. rc2? :) I don't want to drag this process out unnecessarily. there are still bugs being filed on phab... and i was more making the point that re-spinning a tarball with the same name/version is not a good thing. which rc1 do you have? i don't know. rc1!. :) if there is a re-spin.. at least call it rc2... :) i could have done a re spin for 1.8.1 (another 1.8.0) as no code changed - it was a m4 macro doing the totally unexpected. but i had to do 1.8.1 :( there was no re spin as you call it. the tarballs sent to the list were PREVIEW tarballs, and it was explicitly stated that they may or may not have been the final release tarballs for those versions. you absolutely could not have done the same thing, as you did not send your prepared tarballs to any lists prior to doing the release. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/elementary] master 01/01: elementary - revert ddc3cf80ce0a50a9161fcb212d3414f5d7b5898c
On Thu, Sep 12, 2013 at 5:45 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: I like how regardless of location or topic, we can always count on a Daniel to be at every EFL-related meeting, discussion, or conference. Hahahahahahahahahahahahah. I am watching you. Daniel Juyung Seo (SeoZ) On Thu, Sep 12, 2013 at 9:32 AM, Daniel Juyung Seo seojuyu...@gmail.comwrote: I also agree with this idea. This is the most convenient and safe way to handle this issue sanely among suggested ideas. Thanks. Daniel Juyung Seo (SeoZ) On Thu, Sep 12, 2013 at 2:45 PM, ChunEon Park her...@naver.com wrote: Hi, I reverted elm_object_item_get() API. Cedric, Raster, Daniel, Me together discussed for more proper way instead of the API. In the end, Cedric suggested to return the rectangle object that's a kind of fake object of the object item's real object. and All of us agreed on it. Now, I will add 2 more APIs elm_object_item_object_track(), elm_object_item_object_untrack() to return/retrieve the fake object. Maybe, all guys will be happy with these APis. If you have some other idea or whatever opinions, please reply on this email. Thank you. -Regards, Hermet- -Original Message- From: ChunEon Park - Enlightenment Gitno-re...@enlightenment.org To: enlightenment-...@lists.sourceforge.net; Cc: Sent: 2013-09-12 (목) 14:15:15 Subject: [EGIT] [core/elementary] master 01/01: elementary - revert ddc3cf80ce0a50a9161fcb212d3414f5d7b5898c -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: autotools: try to figure out what our buildbot get here.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=5f2687b1f4a66ff4008e0949bdf0464d0e079523
commit 5f2687b1f4a66ff4008e0949bdf0464d0e079523
Author: Cedric Bail cedric.b...@samsung.com
Date: Tue Dec 10 11:30:43 2013 +0900
autotools: try to figure out what our buildbot get here.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index edc1207..2c0d218 100644
--- a/configure.ac
+++ b/configure.ac
@@ -288,7 +288,7 @@ fi
# it's not found. So we are using an internal variable
# that does the work for now, may get broken in the future.
if test x${ac_ct_CXX} = x; then
- AC_MSG_ERROR([efl requires a C++ compiler])
+ AC_MSG_ERROR([efl requires a C++ compiler got ${ac_ct_CXX} and ${CXX}.])
fi
AC_SYS_LARGEFILE
--
[EGIT] [core/efl] master 01/01: Evas textblock: Fix crash with empty markups values
jpeg pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=0cb048f9b681d43fe905d948e4f7b8e51bed9aa4
commit 0cb048f9b681d43fe905d948e4f7b8e51bed9aa4
Author: Jean-Philippe Andre jp.an...@samsung.com
Date: Tue Dec 10 11:39:15 2013 +0900
Evas textblock: Fix crash with empty markups values
Markup parsing will segv if a value string is empty,
as in style=. Sure, this is invalid, but hey, it could
definitely be used from an app or even by a user writing
his own markups :)
The internal doc says this function expects an item to be
of the form key=val but there are no checks beyond the
presence of = in the string before calling it.
---
src/lib/evas/canvas/evas_object_textblock.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/lib/evas/canvas/evas_object_textblock.c
b/src/lib/evas/canvas/evas_object_textblock.c
index 41cd764..f1c3018 100644
--- a/src/lib/evas/canvas/evas_object_textblock.c
+++ b/src/lib/evas/canvas/evas_object_textblock.c
@@ -2362,6 +2362,7 @@ _format_param_parse(const char *item, const char **key,
Eina_Tmpstr **val)
else len = strlen(start);
tmp = (char*) eina_tmpstr_add_length(start, len);
+ if (!tmp) goto end;
for (d = tmp, s = tmp; *s; s++)
{
@@ -2373,6 +2374,7 @@ _format_param_parse(const char *item, const char **key,
Eina_Tmpstr **val)
}
*d = '\0';
+end:
*val = tmp;
}
@@ -2450,7 +2452,7 @@ _format_fill(Evas_Object *eo_obj,
Evas_Object_Textblock_Format *fmt, const char
Eina_Tmpstr *val = NULL;
_format_param_parse(item, key, val);
- _format_command(eo_obj, fmt, key, val);
+ if ((key) (val)) _format_command(eo_obj, fmt, key, val);
eina_stringshare_del(key);
eina_tmpstr_del(val);
}
--
[EGIT] [bindings/python/python-efl] master 01/01: Elementary.general: Add missing enums that were documented but not added.
kuuko pushed a commit to branch master. http://git.enlightenment.org/bindings/python/python-efl.git/commit/?id=438c10f2cca4663d57936315de710abc1c464ea2 commit 438c10f2cca4663d57936315de710abc1c464ea2 Author: Kai Huuhko kai.huu...@gmail.com Date: Tue Dec 10 06:55:36 2013 +0200 Elementary.general: Add missing enums that were documented but not added. --- efl/elementary/enums.pxd | 9 + efl/elementary/general.pyx | 8 2 files changed, 17 insertions(+) diff --git a/efl/elementary/enums.pxd b/efl/elementary/enums.pxd index 675ba9f..9db9ac9 100644 --- a/efl/elementary/enums.pxd +++ b/efl/elementary/enums.pxd @@ -349,6 +349,15 @@ cdef extern from Elementary.h: ELM_POLICY_QUIT_NONE ELM_POLICY_QUIT_LAST_WINDOW_CLOSED +ctypedef enum Elm_Policy_Exit: +ELM_POLICY_EXIT_NONE +ELM_POLICY_EXIT_WINDOWS_DEL + +ctypedef enum Elm_Policy_Throttle: +ELM_POLICY_THROTTLE_CONFIG +ELM_POLICY_THROTTLE_HIDDEN_ALWAYS +ELM_POLICY_THROTTLE_NEVER + ctypedef enum Elm_Popup_Orient: ELM_POPUP_ORIENT_TOP ELM_POPUP_ORIENT_CENTER diff --git a/efl/elementary/general.pyx b/efl/elementary/general.pyx index 5aa282e..a1e7fad 100644 --- a/efl/elementary/general.pyx +++ b/efl/elementary/general.pyx @@ -139,10 +139,18 @@ import traceback cimport enums ELM_POLICY_QUIT = enums.ELM_POLICY_QUIT +ELM_POLICY_EXIT = enums.ELM_POLICY_EXIT +ELM_POLICY_THROTTLE = enums.ELM_POLICY_THROTTLE ELM_POLICY_QUIT_NONE = enums.ELM_POLICY_QUIT_NONE ELM_POLICY_QUIT_LAST_WINDOW_CLOSED = enums.ELM_POLICY_QUIT_LAST_WINDOW_CLOSED +ELM_POLICY_EXIT_NONE = enums.ELM_POLICY_EXIT_NONE +ELM_POLICY_EXIT_WINDOWS_DEL = enums.ELM_POLICY_EXIT_WINDOWS_DEL + +ELM_POLICY_THROTTLE_CONFIG = enums.ELM_POLICY_THROTTLE_CONFIG +ELM_POLICY_THROTTLE_HIDDEN_ALWAYS = enums.ELM_POLICY_THROTTLE_HIDDEN_ALWAYS +ELM_POLICY_THROTTLE_NEVER = enums.ELM_POLICY_THROTTLE_NEVER cdef class FontProperties(object): --
[EGIT] [core/efl] master 01/01: ecore-evas - disable comp syncing by default (can be turned on though still)
raster pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=b3d69254b6c651d4c35e3c90bc9367f5916e50c4 commit b3d69254b6c651d4c35e3c90bc9367f5916e50c4 Author: Carsten Haitzler (Rasterman) ras...@rasterman.com Date: Tue Dec 10 14:02:27 2013 +0900 ecore-evas - disable comp syncing by default (can be turned on though still) --- src/lib/ecore_evas/ecore_evas.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/lib/ecore_evas/ecore_evas.c b/src/lib/ecore_evas/ecore_evas.c index db2ada7..e338016 100644 --- a/src/lib/ecore_evas/ecore_evas.c +++ b/src/lib/ecore_evas/ecore_evas.c @@ -33,7 +33,7 @@ #include ecore_evas_extn.h #include ecore_evas_win32.h -EAPI Eina_Bool _ecore_evas_app_comp_sync = 1; +EAPI Eina_Bool _ecore_evas_app_comp_sync = EINA_FALSE; EAPI int _ecore_evas_log_dom = -1; static int _ecore_evas_init_count = 0; static Ecore_Fd_Handler *_ecore_evas_async_events_fd = NULL; @@ -366,7 +366,9 @@ ecore_evas_init(void) EINA_LOG_STATE_INIT); if (getenv(ECORE_EVAS_COMP_NOSYNC)) - _ecore_evas_app_comp_sync = 0; + _ecore_evas_app_comp_sync = EINA_FALSE; + else if (getenv(ECORE_EVAS_COMP_SYNC)) + _ecore_evas_app_comp_sync = EINA_TRUE; return _ecore_evas_init_count; shutdown_ecore: --
Re: [E-devel] Python-EFL 1.8.0 released
09.12.2013 22:57, Martin Jansa kirjoitti: On Sun, Dec 08, 2013 at 09:46:50PM +0200, Kai Huuhko wrote: = Python-EFL 1.8.0 release = We are pleased to announce that **Python-EFL** 1.8.0 is now released and available for download. == Download == http://download.enlightenment.org/rel/bindings/python/python-efl-1.8.0.tar.gz Hi, just for sake of consistency with other releases, would you mind to add .bz2 archive? If it's only for consistency, we'll add .bz2 format to our tarballs in the next (bug fix) release. If you really need it now then that's another matter. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] Terminology 0.4.0 is out!
On Mon, 9 Dec 2013 20:18:00 -0500 Shawn Haworth shawn...@gmail.com said: On Mon, Dec 9, 2013 at 7:58 PM, Carsten Haitzler ras...@rasterman.com wrote: On Mon, 9 Dec 2013 19:28:43 -0500 Shawn Haworth shawn...@gmail.com said: On Mon, Dec 9, 2013 at 7:08 PM, Carsten Haitzler ras...@rasterman.com wrote: On Mon, 9 Dec 2013 08:24:26 -0500 Shawn Haworth shawn...@gmail.com said: On Sun, Dec 8, 2013 at 10:39 AM, Boris Faure bo...@fau.re wrote: We are pleased to announce the release of Terminology 0.4 You can download the tarball either as [1]terminology-0.4.0.tar.gz or as [2]terminology-0.4.0.tar.bz2. This release features: * text reflow on resize, * full 256 colors support, * improved terminal compatibility, * improved selection handling, * backscroll compression to reduce memory usage, What's the compression ratio? How much memory can I expect to be unused compared to 0.3.0? Thanks! i measured about 60% savings of backscroll memory on average. (si it was 40% its original size). In the frozen tundra of the Northeast US (New England) I can only max out my machine at 2GB ram (DDR Pentium 4). Running LXDE + Terminology w/ 10k scroll buffer + chromium-browser (or bsu when i'm bored) + tmux + vim = heavy swappage. :| I'm thinking about switching my desktop environment to Ratpoison so I can stay in hard memory. Either that or shit-can Terminology for lxterminal. chromium is what is really eating all your memory. you can fiddle about at the edges, but that's your real problem. do some memory profiling some time. I definitely will, and provide a comparison on e-users. Perhaps it will help someone else along the way who has the same troubles as me. sure. :) fyi i have a test machine - pentium-m @ 600mhz, 512m ram. runs e18, terminology etc. just fine. even chromium as long as i keep it to simple stuff and don't use multiple tabs. no gpu either. I read on another thread you saying e18 is actually less bleeding edge than e17. Do you suggest running the e18 branch to gain more stability? i would say its rock solidly stable. it works better than e17. it should also use less memory (when compositing). e18 has no choice there though. you composite like it or not. :) also one thing that hurts you is using lxde. lxde will have its own libraries/internals, where e re-uses the same efl code that it shares with terminology. scrollbuffers are not that expensive really. it's 8 bytes per char and only the chars on each line until the last non-blank one are actually allocated. so assume 50% on average of every line in scrollback is used, a full 10k scrollback before compression will cost about 3.2m. with compression that comes down to 1.3m also remember if you go back through scrollback terminology has to uncompress as it goes and memory will balloon out again until it gets to re-compressing it again (when it goes idle). that's one terminal. also you may want to use the multiple instances, one process option under behavior. it only uses a single terminology process for all terminals. Makes sense. I'm going to change my environment and configuration to match what you have on your test machine. Thanks for giving a shit about the little guy. :) we do care. :) there is always a price to pay for things. features are generally not free. but.. where we can - we try and minimize the cost. compressed scrollback buffers are an example. it's memory that is not regularly accessed and thus can do with being compressed with little to no real effect. it also obscures your terminal scrollback so if you swap... and somone gets your hdd and runs strings on your swap partition... they wont get your whole history log from the terminal (easily). it takes much more effort and smarts. so it serves a security by obscurity purpose too. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
On Mon, 9 Dec 2013 20:23:39 -0500 Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Tue, 10 Dec 2013 09:34:57 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 9 Dec 2013 19:02:50 -0500 Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Tue, 10 Dec 2013 08:51:50 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 9 Dec 2013 14:37:58 +0100 Stefan Schmidt ste...@datenfreihafen.org said: Hello. On Mon, 2013-12-09 at 14:28, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 07:11, Jeff Hoogland wrote: I'm not sure this is the case - just like Simon alpha4 builds fine here. Really strange. I reviewd the commits that gone into rc1 and efl 1.8.2 but I can't see anything that broke this. Also its building fine for me and on jenkins. At any rate I guess I'll try just disabling physics then. Please do. The physics module was not really maintained and Mike just removed it so it will be gone in the next rc and the final release anyway. Having it disabled manually for the rc1 should be ok for the people encountering this problem. Does that sound good for you guys? To avoid any more confusion on this Mike and I decided that I will prepare a new rc1 tarball with the removal commit and upload it. Will send a mail once its up. how about.. rc2? :) I don't want to drag this process out unnecessarily. there are still bugs being filed on phab... and i was more making the point that re-spinning a tarball with the same name/version is not a good thing. which rc1 do you have? i don't know. rc1!. :) if there is a re-spin.. at least call it rc2... :) i could have done a re spin for 1.8.1 (another 1.8.0) as no code changed - it was a m4 macro doing the totally unexpected. but i had to do 1.8.1 :( there was no re spin as you call it. the tarballs sent to the list were PREVIEW tarballs, and it was explicitly stated that they may or may not have been the final release tarballs for those versions. you absolutely could not have done the same thing, as you did not send your prepared tarballs to any lists prior to doing the release. so i downloaded rc1. is mine fixed? :) you didn't answer that. how do i know if its the respin or not before i download it? even for rc's if there is a re-generate at sall it should get a new name for the archive. rc2, rc3, rc4 etc. imho -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Enlightenment support for iMX6
Hello, Iam a newbee to enlightenment project. I wish to know certain things about enlightenment. I am working on Freescale iMX6 board. I built the image with Xterm profile for this board (which includes Enlightenment packages). But, what I wanted to know is which EFL libraries, header files, config files etc are generated out of the build? If I pick those libraries and header files, and dump it in the platform tree for some other platform (say pandaboard), will I be able to run Enlightenment-driven apps on that platform?? Thanks and regards, Prathamesh ~~Disclaimer~~~ Information contained and transmitted by this e-mail is confidential and proprietary to iGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailad...@igate.com mailto:mailad...@igate.com. iGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE. iGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of softwar e viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE please visit www.igate.com http://www.igate.com. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Enlightenment support for iMX6
On Tue, 10 Dec 2013 06:17:39 + Prathamesh P Ghanekar prathamesh.ghane...@igate.com said: Hello, Iam a newbee to enlightenment project. I wish to know certain things about enlightenment. I am working on Freescale iMX6 board. I built the image with Xterm profile for this board (which includes Enlightenment packages). But, what I wanted to know is which EFL libraries, header files, config files etc are generated out of the build? If I pick those libraries and header files, and dump it in the platform tree for some other platform (say pandaboard), will I be able to run Enlightenment-driven apps on that platform?? you don't explain what you used to build the image or even what it contains... and that all depends on dependencies - would the pandaboard os image contain the same dependency libraries? headers are only needed at compile time btw. :) so runtime you care about libraries, modules in lib and some data files in share, and depending what you run - some things in bin (PREFIX/lib, PREFIX/share, PREFIX/.bin where PREFIX is the install PREFIX). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Enlightenment support for iMX6
Ok, you don't explain what you used to build the image or even what it contains... I wish to build TIZEN-IVI for Freescale board. :) As a starting point, I use prebuilt image to run on imx6 board. Surely, it won't run as is on new hardware. But, I wanted to figure out what difference it makes when it runs on the hardware it's not meant for. So, during initialization, it faces issues with enlightenment. Hence, the question. :)! Do you have any suggestions on how should I go about this task? Thanks and regards, Prathamesh -Original Message- From: Carsten Haitzler [mailto:ras...@rasterman.com] Sent: 10 December 2013 11:58 To: Prathamesh P Ghanekar Cc: enlightenment-devel@lists.sourceforge.net Subject: Re: Enlightenment support for iMX6 On Tue, 10 Dec 2013 06:17:39 + Prathamesh P Ghanekar prathamesh.ghane...@igate.com said: Hello, Iam a newbee to enlightenment project. I wish to know certain things about enlightenment. I am working on Freescale iMX6 board. I built the image with Xterm profile for this board (which includes Enlightenment packages). But, what I wanted to know is which EFL libraries, header files, config files etc are generated out of the build? If I pick those libraries and header files, and dump it in the platform tree for some other platform (say pandaboard), will I be able to run Enlightenment-driven apps on that platform?? you don't explain what you used to build the image or even what it contains... and that all depends on dependencies - would the pandaboard os image contain the same dependency libraries? headers are only needed at compile time btw. :) so runtime you care about libraries, modules in lib and some data files in share, and depending what you run - some things in bin (PREFIX/lib, PREFIX/share, PREFIX/.bin where PREFIX is the install PREFIX). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ~~Disclaimer~~~ Information contained and transmitted by this e-mail is confidential and proprietary to iGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailad...@igate.com mailto:mailad...@igate.com. iGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE. iGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of softwar e viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE please visit www.igate.com http://www.igate.com. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: ecore_x: remove double free
englebass pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=4a24b8418503c9cdd20138194e4efced24c95f5c
commit 4a24b8418503c9cdd20138194e4efced24c95f5c
Author: Sebastian Dransfeld s...@tango.flipp.net
Date: Tue Dec 10 08:28:21 2013 +0100
ecore_x: remove double free
We first free'd the data in the else, then at the end.
Now we free old_data just before return, and at the end.
Fixes CID 1135637
---
src/lib/ecore_x/xlib/ecore_x_icccm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/lib/ecore_x/xlib/ecore_x_icccm.c
b/src/lib/ecore_x/xlib/ecore_x_icccm.c
index 9de2dda..b5e4069 100644
--- a/src/lib/ecore_x/xlib/ecore_x_icccm.c
+++ b/src/lib/ecore_x/xlib/ecore_x_icccm.c
@@ -1036,8 +1036,6 @@ ecore_x_icccm_colormap_window_set(Ecore_X_Window win,
if (oldset[i] == subwin)
{
free(old_data);
-
- old_data = NULL;
free(newset);
return;
}
@@ -1046,9 +1044,6 @@ ecore_x_icccm_colormap_window_set(Ecore_X_Window win,
}
newset[num++] = subwin;
-if (old_data)
- free(old_data);
-
data = (unsigned char *)newset;
}
--
[EGIT] [core/efl] efl-1.8 01/01: evas - fix gif loader cpu overuse - used too much cpu to decode anims
raster pushed a commit to branch efl-1.8.
http://git.enlightenment.org/core/efl.git/commit/?id=0a6d2b9d17a89b7c9803b8efd1ffef4623a784b8
commit 0a6d2b9d17a89b7c9803b8efd1ffef4623a784b8
Author: Carsten Haitzler (Rasterman) ras...@rasterman.com
Date: Tue Dec 10 16:27:19 2013 +0900
evas - fix gif loader cpu overuse - used too much cpu to decode anims
stable release - cherry-pick me!
the evas gif loader used way too much cpu to decode animated gifs
because in the rewrite that made it correct, it did not store the
current gif file handle and state, thus each frame it would have to
decode all frames before that one before finally decoding the final
one. that means to decode frame 200, it decoded frame 1, 2, 3, 4 etc.
all the way up to 199 THEN decoded 200 on top, so decode cost became
progressively more then further through the animation you were.
this fixes that by storing state and file handle and allowing you to
iterate through.
---
src/modules/evas/loaders/gif/evas_image_load_gif.c | 94 --
1 file changed, 69 insertions(+), 25 deletions(-)
diff --git a/src/modules/evas/loaders/gif/evas_image_load_gif.c
b/src/modules/evas/loaders/gif/evas_image_load_gif.c
index 6a4d59b..c9c7d7a 100644
--- a/src/modules/evas/loaders/gif/evas_image_load_gif.c
+++ b/src/modules/evas/loaders/gif/evas_image_load_gif.c
@@ -10,12 +10,22 @@
typedef struct _Frame_Info Frame_Info;
typedef struct _Loader_Info Loader_Info;
+typedef struct _File_Info File_Info;
+
+struct _File_Info
+{
+ unsigned char *map;
+ int pos, len; // yes - gif uses ints for file sizes.
+};
struct _Loader_Info
{
Eina_File *f;
Evas_Image_Load_Opts *opts;
Evas_Image_Animated *animated;
+ GifFileType *gif;
+ int imgnum;
+ File_Info fi;
};
struct _Frame_Info
@@ -345,15 +355,6 @@ _flush_older_frames(Evas_Image_Animated *animated,
}
}
-
-// file access info/funcs
-typedef struct _File_Info File_Info;
-struct _File_Info
-{
- unsigned char *map;
- int pos, len; // yes - gif uses ints for file sizes.
-};
-
static int
_file_read(GifFileType *gft, GifByteType *buf, int len)
{
@@ -542,7 +543,6 @@ evas_image_load_file_data_gif2(void *loader_data,
Evas_Image_Animated *animated = loader-animated;
Eina_File *f = loader-f;
Eina_Bool ret = EINA_FALSE;
- File_Info fi = { NULL, 0, 0 };
GifRecordType rec;
GifFileType *gif = NULL;
Image_Entry_Frame *frame;
@@ -573,21 +573,51 @@ evas_image_load_file_data_gif2(void *loader_data,
else
LOADERR(EVAS_LOAD_ERROR_CORRUPT_FILE);
- // map the file and store/track info
- fi.map = eina_file_map_all(f, EINA_FILE_RANDOM);
- if (!fi.map) LOADERR(EVAS_LOAD_ERROR_CORRUPT_FILE);
- fi.len = eina_file_size_get(f);
- fi.pos = 0;
-
+open_file:
// actually ask libgif to open the file
+ gif = loader-gif;
+ if (!gif)
+ {
+// there was no file previously opened
+// map the file and store/track info
+loader-fi.map = eina_file_map_all(f, EINA_FILE_RANDOM);
+if (!loader-fi.map) LOADERR(EVAS_LOAD_ERROR_CORRUPT_FILE);
+loader-fi.len = eina_file_size_get(f);
+loader-fi.pos = 0;
+
#if GIFLIB_MAJOR = 5
- gif = DGifOpen(fi, _file_read, NULL);
+gif = DGifOpen((loader-fi), _file_read, NULL);
#else
- gif = DGifOpen(fi, _file_read);
+gif = DGifOpen((loader-fi), _file_read);
#endif
- if (!gif) LOADERR(EVAS_LOAD_ERROR_UNKNOWN_FORMAT);
+// if gif open failed... get out of here
+if (!gif)
+ {
+ if ((loader-fi.map) (loader-f))
+ eina_file_map_free(loader-f, loader-fi.map);
+ loader-fi.map = NULL;
+ LOADERR(EVAS_LOAD_ERROR_UNKNOWN_FORMAT);
+ }
+loader-gif = gif;
+loader-imgnum = 1;
+ }
+
+ // if we want to go backwards, we likely need/want to re-decode from the
+ // start as we have nothnig to build on
+ if ((index 0) (index loader-imgnum) (loader-animated))
+ {
+if (loader-gif) DGifCloseFile(loader-gif);
+if ((loader-fi.map) (loader-f))
+ eina_file_map_free(loader-f, loader-fi.map);
+loader-gif = NULL;
+loader-fi.map = NULL;
+loader-imgnum = 0;
+goto open_file;
+ }
+
+ // our current position is the previous frame we decoded from the file
+ imgnum = loader-imgnum;
- imgnum = 1;
// walk through gif records in file to figure out info
do
{
@@ -625,7 +655,7 @@ evas_image_load_file_data_gif2(void *loader_data,
if ((thisframe) (!thisframe-data) (animated-animated))
{
Eina_Bool first = EINA_FALSE;
-
+
// allocate it
thisframe-data =
malloc(prop-w * prop-h * sizeof(DATA32));
@@ -723,12 +753,25 @@ evas_image_load_file_data_gif2(void *loader_data,
[EGIT] [core/efl] master 01/01: evas - fix gif loader cpu overuse - used too much cpu to decode anims
raster pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=3047ec4d91227d1b7bdab64f15e6ca9ab45f623d
commit 3047ec4d91227d1b7bdab64f15e6ca9ab45f623d
Author: Carsten Haitzler (Rasterman) ras...@rasterman.com
Date: Tue Dec 10 16:27:19 2013 +0900
evas - fix gif loader cpu overuse - used too much cpu to decode anims
stable release - cherry-pick me!
the evas gif loader used way too much cpu to decode animated gifs
because in the rewrite that made it correct, it did not store the
current gif file handle and state, thus each frame it would have to
decode all frames before that one before finally decoding the final
one. that means to decode frame 200, it decoded frame 1, 2, 3, 4 etc.
all the way up to 199 THEN decoded 200 on top, so decode cost became
progressively more then further through the animation you were.
this fixes that by storing state and file handle and allowing you to
iterate through.
---
src/modules/evas/loaders/gif/evas_image_load_gif.c | 94 --
1 file changed, 69 insertions(+), 25 deletions(-)
diff --git a/src/modules/evas/loaders/gif/evas_image_load_gif.c
b/src/modules/evas/loaders/gif/evas_image_load_gif.c
index 6a4d59b..c9c7d7a 100644
--- a/src/modules/evas/loaders/gif/evas_image_load_gif.c
+++ b/src/modules/evas/loaders/gif/evas_image_load_gif.c
@@ -10,12 +10,22 @@
typedef struct _Frame_Info Frame_Info;
typedef struct _Loader_Info Loader_Info;
+typedef struct _File_Info File_Info;
+
+struct _File_Info
+{
+ unsigned char *map;
+ int pos, len; // yes - gif uses ints for file sizes.
+};
struct _Loader_Info
{
Eina_File *f;
Evas_Image_Load_Opts *opts;
Evas_Image_Animated *animated;
+ GifFileType *gif;
+ int imgnum;
+ File_Info fi;
};
struct _Frame_Info
@@ -345,15 +355,6 @@ _flush_older_frames(Evas_Image_Animated *animated,
}
}
-
-// file access info/funcs
-typedef struct _File_Info File_Info;
-struct _File_Info
-{
- unsigned char *map;
- int pos, len; // yes - gif uses ints for file sizes.
-};
-
static int
_file_read(GifFileType *gft, GifByteType *buf, int len)
{
@@ -542,7 +543,6 @@ evas_image_load_file_data_gif2(void *loader_data,
Evas_Image_Animated *animated = loader-animated;
Eina_File *f = loader-f;
Eina_Bool ret = EINA_FALSE;
- File_Info fi = { NULL, 0, 0 };
GifRecordType rec;
GifFileType *gif = NULL;
Image_Entry_Frame *frame;
@@ -573,21 +573,51 @@ evas_image_load_file_data_gif2(void *loader_data,
else
LOADERR(EVAS_LOAD_ERROR_CORRUPT_FILE);
- // map the file and store/track info
- fi.map = eina_file_map_all(f, EINA_FILE_RANDOM);
- if (!fi.map) LOADERR(EVAS_LOAD_ERROR_CORRUPT_FILE);
- fi.len = eina_file_size_get(f);
- fi.pos = 0;
-
+open_file:
// actually ask libgif to open the file
+ gif = loader-gif;
+ if (!gif)
+ {
+// there was no file previously opened
+// map the file and store/track info
+loader-fi.map = eina_file_map_all(f, EINA_FILE_RANDOM);
+if (!loader-fi.map) LOADERR(EVAS_LOAD_ERROR_CORRUPT_FILE);
+loader-fi.len = eina_file_size_get(f);
+loader-fi.pos = 0;
+
#if GIFLIB_MAJOR = 5
- gif = DGifOpen(fi, _file_read, NULL);
+gif = DGifOpen((loader-fi), _file_read, NULL);
#else
- gif = DGifOpen(fi, _file_read);
+gif = DGifOpen((loader-fi), _file_read);
#endif
- if (!gif) LOADERR(EVAS_LOAD_ERROR_UNKNOWN_FORMAT);
+// if gif open failed... get out of here
+if (!gif)
+ {
+ if ((loader-fi.map) (loader-f))
+ eina_file_map_free(loader-f, loader-fi.map);
+ loader-fi.map = NULL;
+ LOADERR(EVAS_LOAD_ERROR_UNKNOWN_FORMAT);
+ }
+loader-gif = gif;
+loader-imgnum = 1;
+ }
+
+ // if we want to go backwards, we likely need/want to re-decode from the
+ // start as we have nothnig to build on
+ if ((index 0) (index loader-imgnum) (loader-animated))
+ {
+if (loader-gif) DGifCloseFile(loader-gif);
+if ((loader-fi.map) (loader-f))
+ eina_file_map_free(loader-f, loader-fi.map);
+loader-gif = NULL;
+loader-fi.map = NULL;
+loader-imgnum = 0;
+goto open_file;
+ }
+
+ // our current position is the previous frame we decoded from the file
+ imgnum = loader-imgnum;
- imgnum = 1;
// walk through gif records in file to figure out info
do
{
@@ -625,7 +655,7 @@ evas_image_load_file_data_gif2(void *loader_data,
if ((thisframe) (!thisframe-data) (animated-animated))
{
Eina_Bool first = EINA_FALSE;
-
+
// allocate it
thisframe-data =
malloc(prop-w * prop-h * sizeof(DATA32));
@@ -723,12 +753,25 @@ evas_image_load_file_data_gif2(void *loader_data,
