Re: [E-devel] Eet struct serialization woes
On Sun, 16 Aug 2009 01:48:26 -0300 Raphael Kubo da Costa k...@profusion.mobi
said:
argh! cornercase. if the parent struct would have anything else it it other
than a single empty list pointer - this would work (an int, - anything). here's
the problem.
eet looks at the data struct and goes ooh list! let me encode this when eet
stores data it looks a bit like this
DATAname1data1...
DATAname2data2...
etc.
so what u have is normally
data struct { name x
list { for list x
item {
xxx;
}
}
list { for list x
item {
yyy;
}
}
list { for list x
item {
zzz;
}
}
};
that's 3 list items. every time it finds an item node it sees its for member of
list x and appends it. you have an empty list - thus
data struct { name x
}
which is an empty struct.. no data in it.., which encodes to 0 bytes - nothing.
thus the write is returning 0...
the problem only appears because your example is so simple/trivial. anything
m,ore complex works just fine. :) now.. how do i fix this.
Hi there,
I've been struggling to properly serialize a struct which only has an
Eina_List of another struct as a member when this member is NULL (ie
the list is empty).
When the list is empty, if the Eet file is already present and valid,
it simply isn't updated, while if it still doesn't exist it isn't
created at all.
I've attached a simple test case which prints the return value of
eet_data_write - if the program is run with any number as its first
parameter, it adds an entry to the Eina_List before writing it to
disk; if no parameter is passed, it attempts to write the struct with
the empty Eina_List, but fails.
(As a sidenote, the documentation for eet_data_write,
eet_data_write_cipher and eet_write_cipher mention that their return
value is either 0 or 1, but it's actually the number of bytes
serialized for a given section).
--
Raphael Kubo da Costa
ProFUSION embedded systems
http://profusion.mobi
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eet struct serialization woes
On Sun, 16 Aug 2009 01:48:26 -0300 Raphael Kubo da Costa k...@profusion.mobi said: fixed in svn. Committed revision 41810. Hi there, I've been struggling to properly serialize a struct which only has an Eina_List of another struct as a member when this member is NULL (ie the list is empty). When the list is empty, if the Eet file is already present and valid, it simply isn't updated, while if it still doesn't exist it isn't created at all. I've attached a simple test case which prints the return value of eet_data_write - if the program is run with any number as its first parameter, it adds an entry to the Eina_List before writing it to disk; if no parameter is passed, it attempts to write the struct with the empty Eina_List, but fails. (As a sidenote, the documentation for eet_data_write, eet_data_write_cipher and eet_write_cipher mention that their return value is either 0 or 1, but it's actually the number of bytes serialized for a given section). -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eet struct serialization woes
On Sun, 16 Aug 2009, Carsten Haitzler (The Rasterman) wrote: On Sun, 16 Aug 2009 01:48:26 -0300 Raphael Kubo da Costa k...@profusion.mobi said: fixed in svn. Committed revision 41810. and don't forget to update ChangeLog ;-) Vincent -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Eina logging domains
Sorry for the HTML! :)
On Sat, Aug 15, 2009 at 10:39 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Sat, Aug 15, 2009 at 5:55 PM, Andre Diebandre.mart...@ee.ufcg.edu.br
wrote:
Changes:
Module name is now eina_log (but I didn't delete eina_error yet, as we
should delete it only when the transition is completed)
Docs on header and basic doc on .c file, but there's a lot of room for
doc
improvement
Save name on domains
Clean realloc code
Keep parsing EINA_LOG_LEVELS even when user types wrong (e.g.
domain1:level1,domain2:,domain3,domain:5)
Migrate old global logger code to global logger (i.e. remove old
deprecated
functions)
arghh... HTML MAIL!
now to the points
- _DOM is not a suffix, rather a prefix namespace... like
EINA_LOG_ERR and EINA_LOG_DOM_ERR...
- I remember Sun compiler barfing at ##__VA_ARGS__, maybe we need to
avoid that? Vincent?? (avoid that is define just as (...) and user is
obligated to give at least one parameter, fmt. That makes things
uglier IMHO)
That == define as ... ? Should it be done with ... ?
I'm sorry, I didn't follow.
- _Eina_Log_Level define a value 0 (EINA_LOG_LEVEL_MIN =
INT32_MIN) so compilers don't optimize that enum as an unsigned
integer, causing problems for users trying to specify something like
-1 for more critical
- +typedef int Eina_Log; too much, I'd use it as integer, no need
to typedef.
This typedef was already on the code, it was for Eina_Error (a handle for
registered errors). Just remove it ?
- keep these as eina_error, you're fixing error-log, but having
error codes as log codes is too much, like broking and not fixing =)
This holds true for eina_log_msg_register and friends...
+/**
+ * @var EINA_LOG_OUT_OF_MEMORY
+ * Log identifier corresponding to a lack of memory.
+ */
+EAPI extern Eina_Log EINA_LOG_MSG_OUT_OF_MEMORY;
- colors should be improved, for example (even the old code is not good)
+static const char *_colors[EINA_LOG_LEVELS] = {
+ EINA_COLOR_YELLOW, // EINA_LOG_LEVEL_CRITICAL
+ EINA_COLOR_RED, // EINA_LOG_LEVEL_ERR
+ EINA_COLOR_YELLOW, // EINA_LOG_LEVEL_WARN
+ EINA_COLOR_NOTHING, // EINA_LOG_LEVEL_INFO
+ EINA_COLOR_GREEN, // EINA_LOG_LEVEL_DBG
+};
for me, the more red, more dangerous... more green better... So I
usually use as rule in my debugs:
- light (\033[1m) red = critical
- regular (dark) red = error
- yellow = warning
- green = info
- light blue = debug
- regular blue = more than debug
things I told you in previous mails:
- trailing whitespaces!!!
I couldn't find any trailing whitespaces, could you please point them?
- have you tested the parse of broken EINA_LOG_LEVELS? Note this
+ level = strtol((char *)(end + 1), tmp, 10);
+ if (tmp == (end + 1)) continue;
you do not change start, what happens? infinite loops... you need to
have start = next pair, so need to search for , and update start to
that or add an end label right after appending to pending list
and goto end instead of continue.
- eina_log_shutdown() should ignore already deleted entries.
- eina_log_domain_register() should not free domains, they should be
freed in eina_log_domain_unregister()
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
Thanks a lot for the patience, I hope I can learn with these mistakes :-).
Cheers,
--
André Dieb Martins
Embedded Systems and Pervasive Computing Lab (Embedded)
Electrical Engineering Department (DEE)
Center of Electrical Engineering and Informatics (CEEI)
Federal University of Campina Grande (UFCG)
Blog: http://genuinepulse.blogspot.com/
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Eina logging domains
One more thing,
On Sun, Aug 16, 2009 at 5:26 AM, Andre Dieb andre.mart...@ee.ufcg.edu.brwrote:
Sorry for the HTML! :)
On Sat, Aug 15, 2009 at 10:39 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Sat, Aug 15, 2009 at 5:55 PM, Andre Diebandre.mart...@ee.ufcg.edu.br
wrote:
Changes:
Module name is now eina_log (but I didn't delete eina_error yet, as we
should delete it only when the transition is completed)
Docs on header and basic doc on .c file, but there's a lot of room for
doc
improvement
Save name on domains
Clean realloc code
Keep parsing EINA_LOG_LEVELS even when user types wrong (e.g.
domain1:level1,domain2:,domain3,domain:5)
Migrate old global logger code to global logger (i.e. remove old
deprecated
functions)
arghh... HTML MAIL!
now to the points
- _DOM is not a suffix, rather a prefix namespace... like
EINA_LOG_ERR and EINA_LOG_DOM_ERR...
- I remember Sun compiler barfing at ##__VA_ARGS__, maybe we need to
avoid that? Vincent?? (avoid that is define just as (...) and user is
obligated to give at least one parameter, fmt. That makes things
uglier IMHO)
That == define as ... ? Should it be done with ... ?
I'm sorry, I didn't follow.
- _Eina_Log_Level define a value 0 (EINA_LOG_LEVEL_MIN =
INT32_MIN) so compilers don't optimize that enum as an unsigned
integer, causing problems for users trying to specify something like
-1 for more critical
- +typedef int Eina_Log; too much, I'd use it as integer, no need
to typedef.
This typedef was already on the code, it was for Eina_Error (a handle for
registered errors). Just remove it ?
- keep these as eina_error, you're fixing error-log, but having
error codes as log codes is too much, like broking and not fixing =)
This holds true for eina_log_msg_register and friends...
Put these eina_error_msg_* functions into eina_log or keep eina_error only
for that?
+/**
+ * @var EINA_LOG_OUT_OF_MEMORY
+ * Log identifier corresponding to a lack of memory.
+ */
+EAPI extern Eina_Log EINA_LOG_MSG_OUT_OF_MEMORY;
- colors should be improved, for example (even the old code is not good)
+static const char *_colors[EINA_LOG_LEVELS] = {
+ EINA_COLOR_YELLOW, // EINA_LOG_LEVEL_CRITICAL
+ EINA_COLOR_RED, // EINA_LOG_LEVEL_ERR
+ EINA_COLOR_YELLOW, // EINA_LOG_LEVEL_WARN
+ EINA_COLOR_NOTHING, // EINA_LOG_LEVEL_INFO
+ EINA_COLOR_GREEN, // EINA_LOG_LEVEL_DBG
+};
for me, the more red, more dangerous... more green better... So I
usually use as rule in my debugs:
- light (\033[1m) red = critical
- regular (dark) red = error
- yellow = warning
- green = info
- light blue = debug
- regular blue = more than debug
things I told you in previous mails:
- trailing whitespaces!!!
I couldn't find any trailing whitespaces, could you please point them?
- have you tested the parse of broken EINA_LOG_LEVELS? Note this
+ level = strtol((char *)(end + 1), tmp, 10);
+ if (tmp == (end + 1)) continue;
you do not change start, what happens? infinite loops... you need to
have start = next pair, so need to search for , and update start to
that or add an end label right after appending to pending list
and goto end instead of continue.
- eina_log_shutdown() should ignore already deleted entries.
- eina_log_domain_register() should not free domains, they should be
freed in eina_log_domain_unregister()
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
Thanks a lot for the patience, I hope I can learn with these mistakes :-).
Cheers,
--
André Dieb Martins
Embedded Systems and Pervasive Computing Lab (Embedded)
Electrical Engineering Department (DEE)
Center of Electrical Engineering and Informatics (CEEI)
Federal University of Campina Grande (UFCG)
Blog: http://genuinepulse.blogspot.com/
--
André Dieb Martins
Embedded Systems and Pervasive Computing Lab (Embedded)
Electrical Engineering Department (DEE)
Center of Electrical Engineering and Informatics (CEEI)
Federal University of Campina Grande (UFCG)
Blog: http://genuinepulse.blogspot.com/
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Fwd: E SVN: raster IN trunk/edje: . data src/bin src/lib
-- Forwarded message -- From: Enlightenment SVN no-re...@enlightenment.org Date: 2009/8/16 Subject: E SVN: raster IN trunk/edje: . data src/bin src/lib To: enlightenment-...@lists.sourceforge.net Log: From: Hanspeter Portner vento...@airpost.net This concerns Ticket #109: Add Lua support for Edje 1st: Hello Raster, i'm happy to see you here :) 2nd: is Lua required by Edje now? Building Edje without Lua is not possible, the configure script falis after four checks Thanks Massimiliano -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: E SVN: raster IN trunk/edje: . data src/bin src/lib
On Sun, 16 Aug 2009 13:58:58 +0200 Massimiliano Calamelli mcalame...@gmail.com said: -- Forwarded message -- From: Enlightenment SVN no-re...@enlightenment.org Date: 2009/8/16 Subject: E SVN: raster IN trunk/edje: . data src/bin src/lib To: enlightenment-...@lists.sourceforge.net Log: From: Hanspeter Portner vento...@airpost.net This concerns Ticket #109: Add Lua support for Edje 1st: Hello Raster, i'm happy to see you here :) tnx. i'm back and... smelly! :) 2nd: is Lua required by Edje now? Building Edje without Lua is not possible, the configure script falis after four checks correct. required now. :) edje doesnt have optional features. this'd be bad for theme/edje design. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: E SVN: raster IN trunk/edje: . data src/bin src/lib
2009/8/16 Carsten Haitzler ras...@rasterman.com: On Sun, 16 Aug 2009 13:58:58 +0200 Massimiliano Calamelli mcalame...@gmail.com said: -- Forwarded message -- From: Enlightenment SVN no-re...@enlightenment.org Date: 2009/8/16 Subject: E SVN: raster IN trunk/edje: . data src/bin src/lib To: enlightenment-...@lists.sourceforge.net Log: From: Hanspeter Portner vento...@airpost.net This concerns Ticket #109: Add Lua support for Edje 1st: Hello Raster, i'm happy to see you here :) tnx. i'm back and... smelly! :) 2nd: is Lua required by Edje now? Building Edje without Lua is not possible, the configure script falis after four checks correct. required now. :) edje doesnt have optional features. this'd be bad for theme/edje design. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com K, thanks, i'll ask to apt-get :) Massimiliano -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [ecore 0/3] ecore XCB patches
This is a set of patches required to compile/run ecore on Xlib-less X11 system with relatively recent libxcb/xcb-utils. Fortunately the rest of stack does not need patching. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [ecore 2/3] Unbreak ecore_xcb_region.c
Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net
---
src/lib/ecore_x/xcb/ecore_xcb_region.c | 20 ++--
1 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/src/lib/ecore_x/xcb/ecore_xcb_region.c
b/src/lib/ecore_x/xcb/ecore_xcb_region.c
index ec2847c..5642332 100644
--- a/src/lib/ecore_x/xcb/ecore_xcb_region.c
+++ b/src/lib/ecore_x/xcb/ecore_xcb_region.c
@@ -6,8 +6,8 @@
# include config.h
#endif
-#include ecore_x_private.h
-
+#include ecore_xcb_private.h
+#include pixman.h
/*
* [x] XCreateRegion
@@ -62,6 +62,7 @@ ecore_x_xregion_set(Ecore_X_XRegion *region, Ecore_X_GC gc)
xcb_rectangle_t *rects;
pixman_box16_t *boxes;
int num;
+ int i;
if (!region)
return 0;
@@ -83,7 +84,7 @@ ecore_x_xregion_set(Ecore_X_XRegion *region, Ecore_X_GC gc)
rects[i].height = boxes[i].y2 - boxes[i].y1 + 1;
}
- xcb_set_clip_rectangles(_ecore_x_connection,
+ xcb_set_clip_rectangles(_ecore_xcb_conn,
XCB_CLIP_ORDERING_YX_BANDED,
gc,
0, 0,
@@ -123,7 +124,7 @@ ecore_x_xregion_union_rect(Ecore_X_XRegion *dst,
Ecore_X_XRegion *src, Ecore_X_R
EAPI int
ecore_x_xregion_subtract(Ecore_X_XRegion *dst, Ecore_X_XRegion *r1,
Ecore_X_XRegion *r2)
{
- return pixman_region_subtract((pixman_region16_t *)dst, (pixman_region16_t
*)rm, (pixman_region16_t *)rs);
+ return pixman_region_subtract((pixman_region16_t *)dst, (pixman_region16_t
*)r1, (pixman_region16_t *)r2);
}
EAPI int
@@ -136,21 +137,12 @@ ecore_x_xregion_is_empty(Ecore_X_XRegion *region)
}
EAPI int
-ecore_x_xregion_is_empty(Ecore_X_XRegion *r1, Ecore_X_XRegion *r2)
-{
- if (!r1 || !r2)
- return 0;
-
- return pixman_region_equal((pixman_region16_t *)r1, (pixman_region16_t
*)r2);
-}
-
-EAPI int
ecore_x_xregion_point_contain(Ecore_X_XRegion *region, int x, int y)
{
if (!region)
return 0;
- return pixman_region_contains_point((pixman_region16_t *)region, x, y);
+ return pixman_region_contains_point((pixman_region16_t *)region, x, y,
NULL);
}
EAPI int
--
1.6.3.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [ecore 1/3] Stop using XCB iterators removed from libxcb
XCB used to provide iterators for requests returning
list of values. Recent versions dropped it and return
arrays instead. Adapt code to use arrays unconditionally
(arrays were present in earlier libxcb versions).
Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net
---
src/lib/ecore_x/xcb/ecore_xcb.c| 20
src/lib/ecore_x/xcb/ecore_xcb_window.c | 11 +++
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/src/lib/ecore_x/xcb/ecore_xcb.c b/src/lib/ecore_x/xcb/ecore_xcb.c
index ecf72a3..2eddca8 100644
--- a/src/lib/ecore_x/xcb/ecore_xcb.c
+++ b/src/lib/ecore_x/xcb/ecore_xcb.c
@@ -878,11 +878,13 @@ ecore_x_killall(Ecore_X_Window root)
reply = xcb_query_tree_reply(_ecore_xcb_conn, cookie, NULL);
if (reply)
{
-xcb_window_iterator_t iter;
+xcb_window_t *wins = NULL;
+int i, tree_c_len;
-iter = xcb_query_tree_children_iterator(reply);
-for (; iter.rem; xcb_window_next(iter))
- xcb_kill_client(_ecore_xcb_conn, *iter.data);
+wins = xcb_query_tree_children(reply);
+tree_c_len = xcb_query_tree_children_length(reply);
+for (i = 0; i tree_c_len; i++)
+ xcb_kill_client(_ecore_xcb_conn, wins[i]);
free(reply);
}
}
@@ -973,6 +975,8 @@ _ecore_xcb_key_mask_get(xcb_keysym_t sym)
xcb_key_symbols_t*symbols;
xcb_keysym_t sym2;
int i, j;
+ xcb_keycode_t*keycodes = NULL;
+ int mod_keys_len;
const int masks[8] =
{
XCB_MOD_MASK_SHIFT,
@@ -996,13 +1000,13 @@ _ecore_xcb_key_mask_get(xcb_keysym_t sym)
return 0;
}
- iter = xcb_get_modifier_mapping_keycodes_iterator(reply);
-
- for (i = 0; iter.rem; xcb_keycode_next(iter), i++)
+ keycodes = xcb_get_modifier_mapping_keycodes(reply);
+ mod_keys_len = xcb_get_modifier_mapping_keycodes_length(reply);
+ for (i = 0; i mod_keys_len; i++)
{
for (j = 0; j 8; j++)
{
-sym2 = xcb_key_symbols_get_keysym(symbols, *iter.data, j);
+sym2 = xcb_key_symbols_get_keysym(symbols, keycodes[i], j);
if (sym2 != 0) break;
}
if (sym2 == sym)
diff --git a/src/lib/ecore_x/xcb/ecore_xcb_window.c
b/src/lib/ecore_x/xcb/ecore_xcb_window.c
index a9eabb3..5f1f00f 100644
--- a/src/lib/ecore_x/xcb/ecore_xcb_window.c
+++ b/src/lib/ecore_x/xcb/ecore_xcb_window.c
@@ -1453,6 +1453,8 @@ _ecore_x_window_at_xy_get(Ecore_X_Window base,
int16_twin_y;
uint16_t win_width;
uint16_t win_height;
+ xcb_window_t *wins = NULL;
+ inti, tree_c_len;
cookie_get_window_attributes =
xcb_get_window_attributes_unchecked(_ecore_xcb_conn, base);
cookie_get_geometry = xcb_get_geometry_unchecked(_ecore_xcb_conn, base);
@@ -1522,18 +1524,19 @@ _ecore_x_window_at_xy_get(Ecore_X_Window base,
return base;
}
- iter_children = xcb_query_tree_children_iterator(reply_query_tree);
- for (; iter_children.rem; xcb_window_next(iter_children))
+ wins = xcb_query_tree_children(reply_query_tree);
+ tree_c_len = xcb_query_tree_children_length(reply_query_tree);
+ for(i = 0; i tree_c_len; i++)
{
if (skip)
{
int j;
for (j = 0; j skip_num; j++)
- if (*iter_children.data == skip[j])
+ if (wins[i] == skip[j])
continue;
}
-child = _ecore_x_window_at_xy_get(*iter_children.data, win_x, win_y,
x, y, skip, skip_num);
+child = _ecore_x_window_at_xy_get(wins[i], win_x, win_y, x, y, skip,
skip_num);
if (child)
{
free(reply_query_tree);
--
1.6.3.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [ecore 3/3] Support xcb-icccm = 0.3 in ecore XCB backend
xcb-utils break compatibility sometimes. xcb-icccm API
was disruptively changed in 0.3, while xcb-icccm 0.2 is still
common. Adjust code to use 0.3 versions of constants and
files while providing compatibility layer for 0.2
(to be removed ASAP).
Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net
---
configure.ac|4 +
src/lib/ecore_x/xcb/ecore_xcb_events.c |2 +-
src/lib/ecore_x/xcb/ecore_xcb_icccm.c | 139 ++-
src/lib/ecore_x/xcb/ecore_xcb_private.h | 29 ++
src/lib/ecore_x/xcb/ecore_xcb_window_prop.c | 62 +++-
5 files changed, 188 insertions(+), 48 deletions(-)
diff --git a/configure.ac b/configure.ac
index e04a999..b8cef38 100644
--- a/configure.ac
+++ b/configure.ac
@@ -465,6 +465,10 @@ if test x$want_ecore_x_xcb = xyes ; then
[ have_ecore_x_xcb=no ])
if test x$have_ecore_x_xcb = xyes ; then
+PKG_CHECK_EXISTS([xcb-icccm = 0.3],
+ [],
+ [ AC_DEFINE(ECORE_XCB_ICCCM02, 1, [xcb-icccm 0.2]) ])
+
PKG_CHECK_MODULES(XCB_COMPOSITE, xcb-composite,
[ have_ecore_x_xcb_composite=yes
AC_DEFINE(ECORE_XCB_COMPOSITE, 1, [Build support for XCB composite]) ],
diff --git a/src/lib/ecore_x/xcb/ecore_xcb_events.c
b/src/lib/ecore_x/xcb/ecore_xcb_events.c
index da8a14a..dcc8a8c 100644
--- a/src/lib/ecore_x/xcb/ecore_xcb_events.c
+++ b/src/lib/ecore_x/xcb/ecore_xcb_events.c
@@ -1913,7 +1913,7 @@ _ecore_x_event_handle_client_message(xcb_generic_event_t
*event)
}
else if ((ev-type == ECORE_X_ATOM_WM_CHANGE_STATE)
(ev-format == 32)
-(ev-data.data32[0] == XCB_WM_ICONIC_STATE))
+(ev-data.data32[0] == XCB_WM_STATE_ICONIC))
{
Ecore_X_Event_Window_State_Request *e;
diff --git a/src/lib/ecore_x/xcb/ecore_xcb_icccm.c
b/src/lib/ecore_x/xcb/ecore_xcb_icccm.c
index 8a498de..c8819f1 100644
--- a/src/lib/ecore_x/xcb/ecore_xcb_icccm.c
+++ b/src/lib/ecore_x/xcb/ecore_xcb_icccm.c
@@ -44,13 +44,13 @@ static int _ecore_x_icccm_size_hints_get (const void
*reply,
xcb_get_property_value((xcb_get_property_reply_t *)reply),
((xcb_get_property_reply_t *)reply)-value_len);
- s = (XCB_SIZE_US_POSITION_HINT | XCB_SIZE_US_SIZE_HINT |
-XCB_SIZE_P_POSITION_HINT | XCB_SIZE_P_SIZE_HINT|
-XCB_SIZE_P_MIN_SIZE_HINT | XCB_SIZE_P_MAX_SIZE_HINT |
-XCB_SIZE_P_RESIZE_INC_HINT | XCB_SIZE_P_ASPECT_HINT);
+ s = (XCB_SIZE_HINT_US_POSITION | XCB_SIZE_HINT_US_SIZE |
+XCB_SIZE_HINT_P_POSITION | XCB_SIZE_HINT_P_SIZE|
+XCB_SIZE_HINT_P_MIN_SIZE | XCB_SIZE_HINT_P_MAX_SIZE |
+XCB_SIZE_HINT_P_RESIZE_INC | XCB_SIZE_HINT_P_ASPECT);
if (((xcb_get_property_reply_t *)reply)-value_len = 18) /*
NumPropSizeElements = 18 (ICCCM version 1) */
- s |= (XCB_SIZE_BASE_SIZE_HINT | XCB_SIZE_P_WIN_GRAVITY_HINT);
+ s |= (XCB_SIZE_HINT_BASE_SIZE | XCB_SIZE_HINT_P_WIN_GRAVITY);
else
{
xcb_size_hints_set_base_size(hints, 0, 0);
@@ -76,11 +76,11 @@ ecore_x_icccm_state_set(Ecore_X_Windowwindow,
uint32_t c[2];
if (state == ECORE_X_WINDOW_STATE_HINT_WITHDRAWN)
- c[0] = XCB_WM_WITHDRAWN_STATE;
+ c[0] = XCB_WM_STATE_WITHDRAWN;
else if (state == ECORE_X_WINDOW_STATE_HINT_NORMAL)
- c[0] = XCB_WM_NORMAL_STATE;
+ c[0] = XCB_WM_STATE_NORMAL;
else if (state == ECORE_X_WINDOW_STATE_HINT_ICONIC)
- c[0] = XCB_WM_ICONIC_STATE;
+ c[0] = XCB_WM_STATE_ICONIC;
c[1] = 0;
xcb_change_property(_ecore_xcb_conn, XCB_PROP_MODE_REPLACE, window,
ECORE_X_ATOM_WM_STATE, ECORE_X_ATOM_WM_STATE, 32,
@@ -146,13 +146,13 @@ ecore_x_icccm_state_get(Ecore_X_Window window __UNUSED__)
prop = (uint8_t *)xcb_get_property_value(reply);
switch (prop[0]) {
- case XCB_WM_WITHDRAWN_STATE:
+ case XCB_WM_STATE_WITHDRAWN:
hint = ECORE_X_WINDOW_STATE_HINT_WITHDRAWN;
break;
- case XCB_WM_NORMAL_STATE:
+ case XCB_WM_STATE_NORMAL:
hint = ECORE_X_WINDOW_STATE_HINT_NORMAL;
break;
- case XCB_WM_ICONIC_STATE:
+ case XCB_WM_STATE_ICONIC:
hint = ECORE_X_WINDOW_STATE_HINT_ICONIC;
break;
default:
@@ -352,9 +352,19 @@ ecore_x_icccm_hints_get(Ecore_X_Window window
__UNUSED__,
Ecore_X_Window*window_group,
int *is_urgent)
{
+#ifdef ECORE_XCB_ICCCM02
xcb_wm_hints_t *hints;
+#else
+ xcb_wm_hints_thints;
+#endif
xcb_get_property_reply_t *reply;
- uint32_t flags;
+ int32_t hints_flags;
+ uint32_t hints_input;
+ int32_t hints_initial_state;
+ xcb_pixmap_t hints_icon_pixmap;
+ xcb_pixmap_t hints_icon_mask;
+ xcb_window_t hints_icon_window;
+ xcb_window_t hints_window_group;
if (accepts_focus)
[E-devel] [evas] Add RGBA - grayscale 64 entries palette conversion
This is needed for E-Ink devices outta there. Names of new files,
configure.ac variables and macros are awful, suggestions are welcome.
Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net
---
configure.ac | 22
src/lib/engines/common/Makefile.am |2 +
src/lib/engines/common/evas_convert_grypal_6.c | 26
src/lib/engines/common/evas_convert_grypal_6.h | 10 +
src/lib/engines/common/evas_convert_main.c |5
5 files changed, 65 insertions(+), 0 deletions(-)
create mode 100644 src/lib/engines/common/evas_convert_grypal_6.c
create mode 100644 src/lib/engines/common/evas_convert_grypal_6.h
diff --git a/configure.ac b/configure.ac
index 287ec98..4be17e9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1072,6 +1072,27 @@ EVAS_CONVERT_ROT(32, RGB, 270)
## Convert to 32bpp RGB with rotation of 90
EVAS_CONVERT_ROT(32, RGB, 90)
+###
+## Convert to 8bpp grayscale, 64-palette
+conv_8_grayscale_64=yes
+AC_MSG_CHECKING(whether to build 8bpp grayscale 64-palette converter code)
+AC_ARG_ENABLE(convert-8-grayscale-64,
+ AC_HELP_STRING([--disable-convert-8-grayscale-64], [disable 8bpp grayscale
64-palette converter code]),
+ [
+ if test $enableval = xyes; then
+ AC_DEFINE(BUILD_CONVERT_8_GRAYSCALE_64, 1, [8bpp Grayscale 64-palette
Converter Support])
+ conv_8_grayscale_64=yes
+ else
+ conv_8_grayscale_64=no
+ fi
+ ], [
+ if test x$conv_8_grayscale_64 = xyes; then
+ AC_DEFINE(BUILD_CONVERT_8_GRAYSCALE_64, 1, [32bpp Grayscale 64-palette
Converter Support])
+ fi
+ ]
+)
+AC_MSG_RESULT($conv_8_grayscale_64)
+
## valgrind
want_valgrind=no
have_valgrind=no
@@ -1286,6 +1307,7 @@ echo 8bpp RGB 222: $conv_8_rgb_222
echo 8bpp RGB 221: $conv_8_rgb_221
echo 8bpp RGB 121: $conv_8_rgb_121
echo 8bpp RGB 111: $conv_8_rgb_111
+echo 8bpp Grayscale 64-pal...: $conv_8_grayscale_64
# FIXME: add grayscale and BW support
echo 16bpp RGB 565...: $conv_16_rgb_565
echo 16bpp BGR 565...: $conv_16_bgr_565
diff --git a/src/lib/engines/common/Makefile.am
b/src/lib/engines/common/Makefile.am
index 4b998bc..75a358c 100644
--- a/src/lib/engines/common/Makefile.am
+++ b/src/lib/engines/common/Makefile.am
@@ -35,6 +35,7 @@ evas_convert_rgb_16.c \
evas_convert_rgb_24.c \
evas_convert_rgb_32.c \
evas_convert_rgb_8.c \
+evas_convert_grypal_6.c \
evas_convert_yuv.c \
evas_cpu.c \
evas_draw_main.c \
@@ -78,6 +79,7 @@ evas_convert_colorspace.h \
evas_convert_gry_1.h \
evas_convert_gry_4.h \
evas_convert_gry_8.h \
+evas_convert_grypal_6.h \
evas_convert_main.h \
evas_convert_rgb_16.h \
evas_convert_rgb_24.h \
diff --git a/src/lib/engines/common/evas_convert_grypal_6.c
b/src/lib/engines/common/evas_convert_grypal_6.c
new file mode 100644
index 000..786abe2
--- /dev/null
+++ b/src/lib/engines/common/evas_convert_grypal_6.c
@@ -0,0 +1,26 @@
+/*
+ * vim:ts=8:sw=3:sts=8:noexpandtab:cino=5n-3f0^-2{2
+ */
+
+#include evas_common.h
+#include evas_convert_grypal_6.h
+
+#ifdef BUILD_CONVERT_8_GRAYSCALE_64
+void evas_common_convert_rgba_to_8bpp_pal_gray64 (DATA32 *src, DATA8
*dst, int src_jump, int dst_jump, int w, int h, int dith_x, int dith_y, DATA8
*pal)
+{
+DATA32 *src_ptr;
+DATA8 *dst_ptr;
+int x, y;
+DATA8 Y;
+
+dst_ptr = dst;
+CONVERT_LOOP_START_ROT_0();
+
+/* RGB - YUV conversion */
+Y = (R_VAL(src_ptr) * 76 + G_VAL(src_ptr) * 151 + B_VAL(src_ptr) * 29) /
1024;
+
+*dst_ptr = pal[Y];
+
+CONVERT_LOOP_END_ROT_0();
+}
+#endif
diff --git a/src/lib/engines/common/evas_convert_grypal_6.h
b/src/lib/engines/common/evas_convert_grypal_6.h
new file mode 100644
index 000..38ccda8
--- /dev/null
+++ b/src/lib/engines/common/evas_convert_grypal_6.h
@@ -0,0 +1,10 @@
+/*
+ * vim:ts=8:sw=3:sts=8:noexpandtab:cino=5n-3f0^-2{2
+ */
+
+#ifndef _EVAS_CONVERT_GRY_4_H
+#define _EVAS_CONVERT_GRY_4_H
+
+void evas_common_convert_rgba_to_8bpp_pal_gray64 (DATA32 *src,
DATA8 *dst, int src_jump, int dst_jump, int w, int h, int dith_x, int dith_y,
DATA8 *pal);
+
+#endif /* _EVAS_CONVERT_GRY_4_H */
diff --git a/src/lib/engines/common/evas_convert_main.c
b/src/lib/engines/common/evas_convert_main.c
index 6271464..6182667 100644
--- a/src/lib/engines/common/evas_convert_main.c
+++ b/src/lib/engines/common/evas_convert_main.c
@@ -7,6 +7,7 @@
#include evas_convert_rgb_16.h
#include evas_convert_rgb_24.h
#include evas_convert_rgb_32.h
+#include evas_convert_grypal_6.h
#include evas_convert_yuv.h
#ifdef USE_DITHER_44
@@ -193,6 +194,10 @@ evas_common_convert_func_get(DATA8 *dest, int w, int h,
int depth, DATA32 rmask,
if (pal_mode == PAL_MODE_RGB111)
return evas_common_convert_rgba_to_8bpp_rgb_111_dith;
#endif
+#ifdef BUILD_CONVERT_8_GRAYSCALE_64
+ if (pal_mode ==
[E-devel] [eet] Update libeet1.symbols file
Those symbols appeared earlier than in 1.2.2, but debian/libeet1.symbols was not updated, so there is no point to look at the actual minimal versions of symbols. Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net --- debian/libeet1.symbols | 42 ++ 1 files changed, 42 insertions(+), 0 deletions(-) diff --git a/debian/libeet1.symbols b/debian/libeet1.symbols index 8f3fc09..9a96c7c 100644 --- a/debian/libeet1.symbols +++ b/debian/libeet1.symbols @@ -4,24 +4,42 @@ libeet.so.1 libeet1 #MINVER# eet_data_descriptor2_...@base 1.0.0 eet_data_descriptor3_...@base 1.0.0 eet_data_descriptor_dec...@base 1.0.0 + eet_data_descriptor_decode_cip...@base 1.2.2 eet_data_descriptor_element_...@base 1.0.0 eet_data_descriptor_enc...@base 1.0.0 + eet_data_descriptor_encode_cip...@base 1.2.2 eet_data_descriptor_f...@base 1.0.0 eet_data_descriptor_...@base 1.0.0 eet_data_d...@base 1.0.0 + eet_data_dump_cip...@base 1.2.2 eet_data_image_dec...@base 1.0.0 + eet_data_image_decode_cip...@base 1.2.2 eet_data_image_decode_to_surf...@base 1.1.0 + eet_data_image_decode_to_surface_cip...@base 1.2.2 eet_data_image_enc...@base 1.0.0 + eet_data_image_encode_cip...@base 1.2.2 eet_data_image_header_dec...@base 1.0.0 + eet_data_image_header_decode_cip...@base 1.2.2 eet_data_image_header_r...@base 1.0.0 + eet_data_image_header_read_cip...@base 1.2.2 eet_data_image_r...@base 1.0.0 + eet_data_image_read_cip...@base 1.2.2 eet_data_image_read_to_surf...@base 1.1.0 + eet_data_image_read_to_surface_cip...@base 1.2.2 eet_data_image_wr...@base 1.0.0 + eet_data_image_write_cip...@base 1.2.2 + eet_data_node_encode_cip...@base 1.2.2 + eet_data_node_write_cip...@base 1.2.2 eet_data_r...@base 1.0.0 + eet_data_read_cip...@base 1.2.2 eet_data_text_d...@base 1.0.0 + eet_data_text_dump_cip...@base 1.2.2 eet_data_text_und...@base 1.0.0 + eet_data_text_undump_cip...@base 1.2.2 eet_data_und...@base 1.0.0 + eet_data_undump_cip...@base 1.2.2 eet_data_wr...@base 1.0.0 + eet_data_write_cip...@base 1.2.2 eet_del...@base 1.0.0 eet_dictionary_...@base 1.0.0 eet_dictionary_string_ch...@base 1.0.0 @@ -30,14 +48,38 @@ libeet.so.1 libeet1 #MINVER# eet_identity_o...@base 1.1.0 eet_identity_pr...@base 1.1.0 eet_identity_...@base 1.1.0 + eet_identity_s...@base 1.2.2 + eet_identity_signat...@base 1.2.2 eet_identity_x...@base 1.1.0 eet_i...@base 1.0.0 eet_l...@base 1.0.0 eet_memopen_r...@base 1.1.0 eet_mode_...@base 1.0.0 + eet_node_array_...@base 1.2.2 + eet_node_char_...@base 1.2.2 + eet_node_...@base 1.2.2 + eet_node_double_...@base 1.2.2 + eet_node_float_...@base 1.2.2 + eet_node_hash_...@base 1.2.2 + eet_node_inlined_string_...@base 1.2.2 + eet_node_int_...@base 1.2.2 + eet_node_list_...@base 1.2.2 + eet_node_long_long_...@base 1.2.2 + eet_node_null_...@base 1.2.2 + eet_node_short_...@base 1.2.2 + eet_node_string_...@base 1.2.2 + eet_node_struct_child_...@base 1.2.2 + eet_node_struct_...@base 1.2.2 + eet_node_unsigned_char_...@base 1.2.2 + eet_node_unsigned_int_...@base 1.2.2 + eet_node_unsigned_long_long_...@base 1.2.2 + eet_node_unsigned_short_...@base 1.2.2 + eet_node_var_array_...@base 1.2.2 eet_num_entr...@base 1.0.0 eet_o...@base 1.0.0 eet_r...@base 1.0.0 + eet_read_cip...@base 1.2.2 eet_read_dir...@base 1.0.0 eet_shutd...@base 1.0.0 eet_wr...@base 1.0.0 + eet_write_cip...@base 1.2.2 -- 1.6.3.3 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [eet] Update libeet1.symbols file
On Sun, Aug 16, 2009 at 09:10:38PM +0700, Mikhail Gusarov wrote : Those symbols appeared earlier than in 1.2.2, but debian/libeet1.symbols was not updated, so there is no point to look at the actual minimal versions of symbols. Actually, it did get updated, SVN just didn't follow: see http://git.debian.org/?p=pkg-e/libs/eet.git;a=history;f=debian/libeet1.symbols;h=deb0e65f90dbb9aa49afb20feb2e0626970aa138;hb=master Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [eet] Update libeet1.symbols file
Twas brillig at 16:37:14 16.08.2009 UTC+02 when albin.tonne...@gmail.com did gyre and gimble: Those symbols appeared earlier than in 1.2.2, but debian/libeet1.symbols was not updated, so there is no point to look at the actual minimal versions of symbols. AT Actually, it did get updated, SVN just didn't follow: see AT http://git.debian.org/?p=pkg-e/libs/eet.git;a=history;f=debian/libeet1.symbols;h=deb0e65f90dbb9aa49afb20feb2e0626970aa138;hb=master Okay. Maybe it's better then to remove debian/* from SVN to avoid confusion? -- http://fossarchy.blogspot.com/ pgpUR0cY0YU6C.pgp Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Eina logging domains
On Sun, Aug 16, 2009 at 5:45 AM, Andre Diebandre.mart...@ee.ufcg.edu.br wrote:
One more thing,
On Sun, Aug 16, 2009 at 5:26 AM, Andre Dieb andre.mart...@ee.ufcg.edu.br
wrote:
Sorry for the HTML! :)
On Sat, Aug 15, 2009 at 10:39 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Sat, Aug 15, 2009 at 5:55 PM, Andre Diebandre.mart...@ee.ufcg.edu.br
wrote:
Changes:
Module name is now eina_log (but I didn't delete eina_error yet, as we
should delete it only when the transition is completed)
Docs on header and basic doc on .c file, but there's a lot of room for
doc
improvement
Save name on domains
Clean realloc code
Keep parsing EINA_LOG_LEVELS even when user types wrong (e.g.
domain1:level1,domain2:,domain3,domain:5)
Migrate old global logger code to global logger (i.e. remove old
deprecated
functions)
arghh... HTML MAIL!
now to the points
- _DOM is not a suffix, rather a prefix namespace... like
EINA_LOG_ERR and EINA_LOG_DOM_ERR...
- I remember Sun compiler barfing at ##__VA_ARGS__, maybe we need to
avoid that? Vincent?? (avoid that is define just as (...) and user is
obligated to give at least one parameter, fmt. That makes things
uglier IMHO)
That == define as ... ? Should it be done with ... ?
I'm sorry, I didn't follow.
## is a hack to remove the last , if no arguments are provided.
So these would work similarly
X(a, ...) bla(a, ##__VA_ARGS__)
X(...) bla(__VA_ARGS__)
tests
X(1, 2, 4) bla(1, 2, 4)
X(1) bla(1)
- _Eina_Log_Level define a value 0 (EINA_LOG_LEVEL_MIN =
INT32_MIN) so compilers don't optimize that enum as an unsigned
integer, causing problems for users trying to specify something like
-1 for more critical
- +typedef int Eina_Log; too much, I'd use it as integer, no need
to typedef.
This typedef was already on the code, it was for Eina_Error (a handle for
registered errors). Just remove it ?
argh... if it was there, keep it.
- keep these as eina_error, you're fixing error-log, but having
error codes as log codes is too much, like broking and not fixing =)
This holds true for eina_log_msg_register and friends...
Put these eina_error_msg_* functions into eina_log or keep eina_error only
for that?
keep it for these things
+/**
+ * @var EINA_LOG_OUT_OF_MEMORY
+ * Log identifier corresponding to a lack of memory.
+ */
+EAPI extern Eina_Log EINA_LOG_MSG_OUT_OF_MEMORY;
- colors should be improved, for example (even the old code is not good)
+static const char *_colors[EINA_LOG_LEVELS] = {
+ EINA_COLOR_YELLOW, // EINA_LOG_LEVEL_CRITICAL
+ EINA_COLOR_RED, // EINA_LOG_LEVEL_ERR
+ EINA_COLOR_YELLOW, // EINA_LOG_LEVEL_WARN
+ EINA_COLOR_NOTHING, // EINA_LOG_LEVEL_INFO
+ EINA_COLOR_GREEN, // EINA_LOG_LEVEL_DBG
+};
for me, the more red, more dangerous... more green better... So I
usually use as rule in my debugs:
- light (\033[1m) red = critical
- regular (dark) red = error
- yellow = warning
- green = info
- light blue = debug
- regular blue = more than debug
things I told you in previous mails:
- trailing whitespaces!!!
I couldn't find any trailing whitespaces, could you please point them?
grep -n '[ ]\+$' eina_logging_domains5.diff | cut -d: -f1 | tr '\n' ','
10,26,450,1314
- have you tested the parse of broken EINA_LOG_LEVELS? Note this
+ level = strtol((char *)(end + 1), tmp, 10);
+ if (tmp == (end + 1)) continue;
you do not change start, what happens? infinite loops... you need to
have start = next pair, so need to search for , and update start to
that or add an end label right after appending to pending list
and goto end instead of continue.
- eina_log_shutdown() should ignore already deleted entries.
- eina_log_domain_register() should not free domains, they should be
freed in eina_log_domain_unregister()
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
Thanks a lot for the patience, I hope I can learn with these mistakes :-).
=)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [EFM] an idea
hey, About the name of each icon, I think we can add in theme to text part : - one textblock with the complete name - one text which cut the name By default efm should use the simple text and then when the mouse is moved on an icon or when we select the icon efm should use the textblock and overlap the others icons (do not increase the space between 2 icons to display the complete name). Currently if you have a icon with a long name you will have a big space between 2 icons :/ -- Regards. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [ecore 0/3] ecore XCB patches
Hey, I'll review them next week thanks for the patches :-) Vincent PS: so no problem with evas on a Xlib-less OS ? On Sun, 16 Aug 2009, Mikhail Gusarov wrote: This is a set of patches required to compile/run ecore on Xlib-less X11 system with relatively recent libxcb/xcb-utils. Fortunately the rest of stack does not need patching. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Ce message a été vérifié par MailScanner pour des virus ou des polluriels et rien de suspect n'a été trouvé. Message délivré par le serveur de messagerie de l'Université d'Evry. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [ecore 0/3] ecore XCB patches
Twas brillig at 19:39:07 16.08.2009 UTC+02 when vto...@univ-evry.fr did gyre and gimble: VT PS: so no problem with evas on a Xlib-less OS ? Not enough info yet :) I've just rebased packages to svn-03 snapshot From some ancient state. -- http://fossarchy.blogspot.com/ pgpDmuZflsgms.pgp Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [ecore-xcb 0/2] Assorted ecore XCB patches
Another set of ecore XCB patches, which I forgot to send last time. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [ecore-xcb 2/2] Do not segfault if unable to connect to display
There is xcb_connection_has_error to check connection errors, and return value of xcb_connect is always non-NULL. Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net --- src/lib/ecore_x/xcb/ecore_xcb.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/lib/ecore_x/xcb/ecore_xcb.c b/src/lib/ecore_x/xcb/ecore_xcb.c index 2eddca8..1404b17 100644 --- a/src/lib/ecore_x/xcb/ecore_xcb.c +++ b/src/lib/ecore_x/xcb/ecore_xcb.c @@ -199,7 +199,8 @@ ecore_x_init(const char *name) return _ecore_xcb_init_count; } _ecore_xcb_conn = xcb_connect(name, screen); - if (!_ecore_xcb_conn) return 0; + if (xcb_connection_has_error(_ecore_xcb_conn)) + return 0; /* FIXME: no error code right now */ /* _ecore_xcb_error_handler_init(); */ -- 1.6.3.3 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [ecore-xcb 1/2] Unbreak _ecore_xcb_cookie_cache
Ecore_List - Eina_List transition broke _ecore_xcb_cookie_cache:
due to leftover condition no cookies were added to cache at all,
making havoc and despair.
This patch removes offending check.
Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net
---
src/lib/ecore_x/xcb/ecore_xcb_reply.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/src/lib/ecore_x/xcb/ecore_xcb_reply.c
b/src/lib/ecore_x/xcb/ecore_xcb_reply.c
index 13402b6..1c94823 100644
--- a/src/lib/ecore_x/xcb/ecore_xcb_reply.c
+++ b/src/lib/ecore_x/xcb/ecore_xcb_reply.c
@@ -56,9 +56,6 @@ _ecore_xcb_cookie_cache (unsigned int cookie)
{
Ecore_Xcb_Data *data;
- if (!_ecore_xcb_cookies)
- return;
-
data = (Ecore_Xcb_Data *)malloc(sizeof(Ecore_Xcb_Data));
if (!data)
return;
--
1.6.3.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] ecore_evas_title_set/ecore_evas_name_class_set NULL parameters
Hello. Is it ok to pass NULL parameters to ecore_evas_title_set / ecore_evas_name_class_set? If yes, what's the expected reaction of backend? Should it treat NULL parameters as empty strings or somehow else? -- http://fossarchy.blogspot.com/ pgpLZ1wRZzgIp.pgp Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Eina logging domains
Another attempt attached, see modifications list and inline comments below.
- DOM is now a prefix: EINA_LOG_DOM_(level)
- renamed EINA_COLOR_NOTHING to EINA_COLOR_RESET
- fixed loop problem at pending domains parse
- removed eina_log_msg_* funcs, they're kept on eina_error
- removed trailing whitespaces
- changed colors
- domain free happens now on unregister()
- shutdown ignores deleted entries
- added a test case for level color normalization (if negative, show it with
the lowest color possible - crit. If higher than debug, show it with light
blue)
I couldn't avoid ##__VA_ARGS__ on macros, help would be good.
On Sun, Aug 16, 2009 at 11:50 AM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Sun, Aug 16, 2009 at 5:45 AM, Andre Diebandre.mart...@ee.ufcg.edu.br
wrote:
One more thing,
On Sun, Aug 16, 2009 at 5:26 AM, Andre Dieb
andre.mart...@ee.ufcg.edu.br
wrote:
Sorry for the HTML! :)
On Sat, Aug 15, 2009 at 10:39 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Sat, Aug 15, 2009 at 5:55 PM, Andre Dieb
andre.mart...@ee.ufcg.edu.br
wrote:
Changes:
Module name is now eina_log (but I didn't delete eina_error yet, as
we
should delete it only when the transition is completed)
Docs on header and basic doc on .c file, but there's a lot of room
for
doc
improvement
Save name on domains
Clean realloc code
Keep parsing EINA_LOG_LEVELS even when user types wrong (e.g.
domain1:level1,domain2:,domain3,domain:5)
Migrate old global logger code to global logger (i.e. remove old
deprecated
functions)
arghh... HTML MAIL!
now to the points
- _DOM is not a suffix, rather a prefix namespace... like
EINA_LOG_ERR and EINA_LOG_DOM_ERR...
- I remember Sun compiler barfing at ##__VA_ARGS__, maybe we need to
avoid that? Vincent?? (avoid that is define just as (...) and user is
obligated to give at least one parameter, fmt. That makes things
uglier IMHO)
That == define as ... ? Should it be done with ... ?
I'm sorry, I didn't follow.
## is a hack to remove the last , if no arguments are provided.
So these would work similarly
X(a, ...) bla(a, ##__VA_ARGS__)
X(...) bla(__VA_ARGS__)
tests
X(1, 2, 4) bla(1, 2, 4)
X(1) bla(1)
Here's how it is now. Could you please point how to avoid ## ?
#define EINA_LOG(DOM, LEVEL, fmt, ...) \
eina_log_print(DOM, LEVEL, __FILE__, __FUNCTION__, __LINE__, fmt,
##__VA_ARGS__)
#define EINA_LOG_DOM_CRIT(DOM, fmt, ...) \
EINA_LOG(DOM, EINA_LOG_LEVEL_CRITICAL, fmt, ##__VA_ARGS__)
- _Eina_Log_Level define a value 0 (EINA_LOG_LEVEL_MIN =
INT32_MIN) so compilers don't optimize that enum as an unsigned
integer, causing problems for users trying to specify something like
-1 for more critical
- +typedef int Eina_Log; too much, I'd use it as integer, no need
to typedef.
This typedef was already on the code, it was for Eina_Error (a handle
for
registered errors). Just remove it ?
argh... if it was there, keep it.
- keep these as eina_error, you're fixing error-log, but having
error codes as log codes is too much, like broking and not fixing =)
This holds true for eina_log_msg_register and friends...
Put these eina_error_msg_* functions into eina_log or keep eina_error
only
for that?
keep it for these things
+/**
+ * @var EINA_LOG_OUT_OF_MEMORY
+ * Log identifier corresponding to a lack of memory.
+ */
+EAPI extern Eina_Log EINA_LOG_MSG_OUT_OF_MEMORY;
- colors should be improved, for example (even the old code is not
good)
+static const char *_colors[EINA_LOG_LEVELS] = {
+ EINA_COLOR_YELLOW, // EINA_LOG_LEVEL_CRITICAL
+ EINA_COLOR_RED, // EINA_LOG_LEVEL_ERR
+ EINA_COLOR_YELLOW, // EINA_LOG_LEVEL_WARN
+ EINA_COLOR_NOTHING, // EINA_LOG_LEVEL_INFO
+ EINA_COLOR_GREEN, // EINA_LOG_LEVEL_DBG
+};
for me, the more red, more dangerous... more green better... So I
usually use as rule in my debugs:
- light (\033[1m) red = critical
- regular (dark) red = error
- yellow = warning
- green = info
- light blue = debug
- regular blue = more than debug
things I told you in previous mails:
- trailing whitespaces!!!
I couldn't find any trailing whitespaces, could you please point them?
grep -n '[ ]\+$' eina_logging_domains5.diff | cut -d: -f1 | tr '\n' ','
10,26,450,1314
neat!
- have you tested the parse of broken EINA_LOG_LEVELS? Note this
+ level = strtol((char *)(end + 1), tmp, 10);
+ if (tmp == (end + 1)) continue;
you do not change start, what happens? infinite loops... you need to
have start = next pair, so need to search for , and update start to
that or add an end label right after appending to pending list
and goto end instead of continue.
- eina_log_shutdown() should ignore already deleted entries.
- eina_log_domain_register() should not free domains, they should be
freed in
Re: [E-devel] [EFM] an idea
On Sun, Aug 16, 2009 at 12:16 PM, Atton Jonathanjonathan.at...@gmail.com wrote: hey, About the name of each icon, I think we can add in theme to text part : - one textblock with the complete name - one text which cut the name By default efm should use the simple text and then when the mouse is moved on an icon or when we select the icon efm should use the textblock and overlap the others icons (do not increase the space between 2 icons to display the complete name). Currently if you have a icon with a long name you will have a big space between 2 icons :/ this is up to the theme. Last time I checked I found that this is already in, but the group name is not being used. I guess you can look at default.edc and spot those. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Eina logging domains
- Added eina_log to Eina.h
- Removed debug fprintf, do not use eina_safety for (level d-level)
check, it floods the screen
On Sun, Aug 16, 2009 at 8:54 PM, Andre Dieb andre.mart...@ee.ufcg.edu.brwrote:
Another attempt attached, see modifications list and inline comments below.
- DOM is now a prefix: EINA_LOG_DOM_(level)
- renamed EINA_COLOR_NOTHING to EINA_COLOR_RESET
- fixed loop problem at pending domains parse
- removed eina_log_msg_* funcs, they're kept on eina_error
- removed trailing whitespaces
- changed colors
- domain free happens now on unregister()
- shutdown ignores deleted entries
- added a test case for level color normalization (if negative, show it
with the lowest color possible - crit. If higher than debug, show it with
light blue)
I couldn't avoid ##__VA_ARGS__ on macros, help would be good.
On Sun, Aug 16, 2009 at 11:50 AM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Sun, Aug 16, 2009 at 5:45 AM, Andre Diebandre.mart...@ee.ufcg.edu.br
wrote:
One more thing,
On Sun, Aug 16, 2009 at 5:26 AM, Andre Dieb
andre.mart...@ee.ufcg.edu.br
wrote:
Sorry for the HTML! :)
On Sat, Aug 15, 2009 at 10:39 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Sat, Aug 15, 2009 at 5:55 PM, Andre Dieb
andre.mart...@ee.ufcg.edu.br
wrote:
Changes:
Module name is now eina_log (but I didn't delete eina_error yet, as
we
should delete it only when the transition is completed)
Docs on header and basic doc on .c file, but there's a lot of room
for
doc
improvement
Save name on domains
Clean realloc code
Keep parsing EINA_LOG_LEVELS even when user types wrong (e.g.
domain1:level1,domain2:,domain3,domain:5)
Migrate old global logger code to global logger (i.e. remove old
deprecated
functions)
arghh... HTML MAIL!
now to the points
- _DOM is not a suffix, rather a prefix namespace... like
EINA_LOG_ERR and EINA_LOG_DOM_ERR...
- I remember Sun compiler barfing at ##__VA_ARGS__, maybe we need to
avoid that? Vincent?? (avoid that is define just as (...) and user is
obligated to give at least one parameter, fmt. That makes things
uglier IMHO)
That == define as ... ? Should it be done with ... ?
I'm sorry, I didn't follow.
## is a hack to remove the last , if no arguments are provided.
So these would work similarly
X(a, ...) bla(a, ##__VA_ARGS__)
X(...) bla(__VA_ARGS__)
tests
X(1, 2, 4) bla(1, 2, 4)
X(1) bla(1)
Here's how it is now. Could you please point how to avoid ## ?
#define EINA_LOG(DOM, LEVEL, fmt, ...) \
eina_log_print(DOM, LEVEL, __FILE__, __FUNCTION__, __LINE__, fmt,
##__VA_ARGS__)
#define EINA_LOG_DOM_CRIT(DOM, fmt, ...) \
EINA_LOG(DOM, EINA_LOG_LEVEL_CRITICAL, fmt, ##__VA_ARGS__)
- _Eina_Log_Level define a value 0 (EINA_LOG_LEVEL_MIN =
INT32_MIN) so compilers don't optimize that enum as an unsigned
integer, causing problems for users trying to specify something like
-1 for more critical
- +typedef int Eina_Log; too much, I'd use it as integer, no need
to typedef.
This typedef was already on the code, it was for Eina_Error (a handle
for
registered errors). Just remove it ?
argh... if it was there, keep it.
- keep these as eina_error, you're fixing error-log, but having
error codes as log codes is too much, like broking and not fixing =)
This holds true for eina_log_msg_register and friends...
Put these eina_error_msg_* functions into eina_log or keep eina_error
only
for that?
keep it for these things
+/**
+ * @var EINA_LOG_OUT_OF_MEMORY
+ * Log identifier corresponding to a lack of memory.
+ */
+EAPI extern Eina_Log EINA_LOG_MSG_OUT_OF_MEMORY;
- colors should be improved, for example (even the old code is not
good)
+static const char *_colors[EINA_LOG_LEVELS] = {
+ EINA_COLOR_YELLOW, // EINA_LOG_LEVEL_CRITICAL
+ EINA_COLOR_RED, // EINA_LOG_LEVEL_ERR
+ EINA_COLOR_YELLOW, // EINA_LOG_LEVEL_WARN
+ EINA_COLOR_NOTHING, // EINA_LOG_LEVEL_INFO
+ EINA_COLOR_GREEN, // EINA_LOG_LEVEL_DBG
+};
for me, the more red, more dangerous... more green better... So I
usually use as rule in my debugs:
- light (\033[1m) red = critical
- regular (dark) red = error
- yellow = warning
- green = info
- light blue = debug
- regular blue = more than debug
things I told you in previous mails:
- trailing whitespaces!!!
I couldn't find any trailing whitespaces, could you please point them?
grep -n '[ ]\+$' eina_logging_domains5.diff | cut -d: -f1 | tr '\n' ','
10,26,450,1314
neat!
- have you tested the parse of broken EINA_LOG_LEVELS? Note this
+ level = strtol((char *)(end + 1), tmp, 10);
+ if (tmp == (end + 1)) continue;
you do not change start, what happens? infinite loops... you need to
have start = next pair, so need to search for , and update start to
that or add an end label right after
Re: [E-devel] [PATCH] Eina logging domains
On Sun, Aug 16, 2009 at 8:54 PM, Andre Diebandre.mart...@ee.ufcg.edu.br wrote: Another attempt attached, see modifications list and inline comments below. - DOM is now a prefix: EINA_LOG_DOM_(level) - renamed EINA_COLOR_NOTHING to EINA_COLOR_RESET - fixed loop problem at pending domains parse - removed eina_log_msg_* funcs, they're kept on eina_error - removed trailing whitespaces - changed colors - domain free happens now on unregister() - shutdown ignores deleted entries - added a test case for level color normalization (if negative, show it with the lowest color possible - crit. If higher than debug, show it with light blue) will look. I couldn't avoid ##__VA_ARGS__ on macros, help would be good. On Sun, Aug 16, 2009 at 11:50 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sun, Aug 16, 2009 at 5:45 AM, Andre Diebandre.mart...@ee.ufcg.edu.br wrote: One more thing, On Sun, Aug 16, 2009 at 5:26 AM, Andre Dieb andre.mart...@ee.ufcg.edu.br wrote: Sorry for the HTML! :) On Sat, Aug 15, 2009 at 10:39 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sat, Aug 15, 2009 at 5:55 PM, Andre Diebandre.mart...@ee.ufcg.edu.br wrote: Changes: Module name is now eina_log (but I didn't delete eina_error yet, as we should delete it only when the transition is completed) Docs on header and basic doc on .c file, but there's a lot of room for doc improvement Save name on domains Clean realloc code Keep parsing EINA_LOG_LEVELS even when user types wrong (e.g. domain1:level1,domain2:,domain3,domain:5) Migrate old global logger code to global logger (i.e. remove old deprecated functions) arghh... HTML MAIL! now to the points - _DOM is not a suffix, rather a prefix namespace... like EINA_LOG_ERR and EINA_LOG_DOM_ERR... - I remember Sun compiler barfing at ##__VA_ARGS__, maybe we need to avoid that? Vincent?? (avoid that is define just as (...) and user is obligated to give at least one parameter, fmt. That makes things uglier IMHO) That == define as ... ? Should it be done with ... ? I'm sorry, I didn't follow. ## is a hack to remove the last , if no arguments are provided. So these would work similarly X(a, ...) bla(a, ##__VA_ARGS__) X(...) bla(__VA_ARGS__) tests X(1, 2, 4) bla(1, 2, 4) X(1) bla(1) Here's how it is now. Could you please point how to avoid ## ? #define EINA_LOG(DOM, LEVEL, fmt, ...) \ eina_log_print(DOM, LEVEL, __FILE__, __FUNCTION__, __LINE__, fmt, ##__VA_ARGS__) #define EINA_LOG_DOM_CRIT(DOM, fmt, ...) \ EINA_LOG(DOM, EINA_LOG_LEVEL_CRITICAL, fmt, ##__VA_ARGS__) EINA_LOG_DOM_CRIT(DOM, ...) \ EINA_LOG(DOM, EINA_LOG_LEVEL_CRITICAL, __VA_ARGS__) but I said already, it's uglier =/ -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [ecore 1/3] Stop using XCB iterators removed from libxcb
Twas brillig at 20:14:44 16.08.2009 UTC+07 when dotted...@dottedmag.net did gyre and gimble: MG XCB used to provide iterators for requests returning MG list of values. Recent versions dropped it And from the recent discussion in x...@lists.fd.o it became apparent that it was a bug, so it is possible to either completely ignore this patch (and be incompatible with libxcb 1.1.93-1.4), apply it conditionally or apply unconditionally for better compatibility. -- http://fossarchy.blogspot.com/ pgpLHJgvppk0f.pgp Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [evas] Add RGBA - grayscale 64 entries palette conversion
On Sun, 16 Aug 2009 20:25:10 +0700 Mikhail Gusarov dotted...@dottedmag.net
said:
This is needed for E-Ink devices outta there. Names of new files,
configure.ac variables and macros are awful, suggestions are welcome.
greayscale64? i thought they were 16 levels of grey (4bit)? well the ones i
saw? or is the 64 mapped to 16 with dithering?
Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net
---
configure.ac | 22
src/lib/engines/common/Makefile.am |2 +
src/lib/engines/common/evas_convert_grypal_6.c | 26 +++
+ src/lib/engines/common/evas_convert_grypal_6.h | 10 +
src/lib/engines/common/evas_convert_main.c |5
5 files changed, 65 insertions(+), 0 deletions(-)
create mode 100644 src/lib/engines/common/evas_convert_grypal_6.c
create mode 100644 src/lib/engines/common/evas_convert_grypal_6.h
diff --git a/configure.ac b/configure.ac
index 287ec98..4be17e9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1072,6 +1072,27 @@ EVAS_CONVERT_ROT(32, RGB, 270)
## Convert to 32bpp RGB with rotation of 90
EVAS_CONVERT_ROT(32, RGB, 90)
+###
+## Convert to 8bpp grayscale, 64-palette
+conv_8_grayscale_64=yes
+AC_MSG_CHECKING(whether to build 8bpp grayscale 64-palette converter code)
+AC_ARG_ENABLE(convert-8-grayscale-64,
+ AC_HELP_STRING([--disable-convert-8-grayscale-64], [disable 8bpp grayscale
64-palette converter code]),
+ [
+ if test $enableval = xyes; then
+ AC_DEFINE(BUILD_CONVERT_8_GRAYSCALE_64, 1, [8bpp Grayscale 64-palette
Converter Support])
+ conv_8_grayscale_64=yes
+ else
+ conv_8_grayscale_64=no
+ fi
+ ], [
+ if test x$conv_8_grayscale_64 = xyes; then
+ AC_DEFINE(BUILD_CONVERT_8_GRAYSCALE_64, 1, [32bpp Grayscale
64-palette Converter Support])
+ fi
+ ]
+)
+AC_MSG_RESULT($conv_8_grayscale_64)
+
## valgrind
want_valgrind=no
have_valgrind=no
@@ -1286,6 +1307,7 @@ echo 8bpp RGB 222: $conv_8_rgb_222
echo 8bpp RGB 221: $conv_8_rgb_221
echo 8bpp RGB 121: $conv_8_rgb_121
echo 8bpp RGB 111: $conv_8_rgb_111
+echo 8bpp Grayscale 64-pal...: $conv_8_grayscale_64
# FIXME: add grayscale and BW support
echo 16bpp RGB 565...: $conv_16_rgb_565
echo 16bpp BGR 565...: $conv_16_bgr_565
diff --git a/src/lib/engines/common/Makefile.am
b/src/lib/engines/common/Makefile.am index 4b998bc..75a358c 100644
--- a/src/lib/engines/common/Makefile.am
+++ b/src/lib/engines/common/Makefile.am
@@ -35,6 +35,7 @@ evas_convert_rgb_16.c \
evas_convert_rgb_24.c \
evas_convert_rgb_32.c \
evas_convert_rgb_8.c \
+evas_convert_grypal_6.c \
evas_convert_yuv.c \
evas_cpu.c \
evas_draw_main.c \
@@ -78,6 +79,7 @@ evas_convert_colorspace.h \
evas_convert_gry_1.h \
evas_convert_gry_4.h \
evas_convert_gry_8.h \
+evas_convert_grypal_6.h \
evas_convert_main.h \
evas_convert_rgb_16.h \
evas_convert_rgb_24.h \
diff --git a/src/lib/engines/common/evas_convert_grypal_6.c
b/src/lib/engines/common/evas_convert_grypal_6.c new file mode 100644
index 000..786abe2
--- /dev/null
+++ b/src/lib/engines/common/evas_convert_grypal_6.c
@@ -0,0 +1,26 @@
+/*
+ * vim:ts=8:sw=3:sts=8:noexpandtab:cino=5n-3f0^-2{2
+ */
+
+#include evas_common.h
+#include evas_convert_grypal_6.h
+
+#ifdef BUILD_CONVERT_8_GRAYSCALE_64
+void evas_common_convert_rgba_to_8bpp_pal_gray64 (DATA32 *src, DATA8
*dst, int src_jump, int dst_jump, int w, int h, int dith_x, int dith_y, DATA8
*pal) +{
+DATA32 *src_ptr;
+DATA8 *dst_ptr;
+int x, y;
+DATA8 Y;
+
+dst_ptr = dst;
+CONVERT_LOOP_START_ROT_0();
+
+/* RGB - YUV conversion */
+Y = (R_VAL(src_ptr) * 76 + G_VAL(src_ptr) * 151 + B_VAL(src_ptr) * 29) /
1024; +
+*dst_ptr = pal[Y];
+
+CONVERT_LOOP_END_ROT_0();
+}
+#endif
diff --git a/src/lib/engines/common/evas_convert_grypal_6.h
b/src/lib/engines/common/evas_convert_grypal_6.h new file mode 100644
index 000..38ccda8
--- /dev/null
+++ b/src/lib/engines/common/evas_convert_grypal_6.h
@@ -0,0 +1,10 @@
+/*
+ * vim:ts=8:sw=3:sts=8:noexpandtab:cino=5n-3f0^-2{2
+ */
+
+#ifndef _EVAS_CONVERT_GRY_4_H
+#define _EVAS_CONVERT_GRY_4_H
+
+void evas_common_convert_rgba_to_8bpp_pal_gray64 (DATA32 *src,
DATA8 *dst, int src_jump, int dst_jump, int w, int h, int dith_x, int dith_y,
DATA8 *pal); + +#endif /* _EVAS_CONVERT_GRY_4_H */
diff --git a/src/lib/engines/common/evas_convert_main.c
b/src/lib/engines/common/evas_convert_main.c index 6271464..6182667 100644
--- a/src/lib/engines/common/evas_convert_main.c
+++ b/src/lib/engines/common/evas_convert_main.c
@@ -7,6 +7,7 @@
#include evas_convert_rgb_16.h
#include evas_convert_rgb_24.h
#include evas_convert_rgb_32.h
+#include evas_convert_grypal_6.h
#include
Re: [E-devel] ecore_evas_title_set/ecore_evas_name_class_set NULL parameters
Twas brillig at 11:30:24 17.08.2009 UTC+10 when ras...@rasterman.com did gyre and gimble: CHR On Mon, 17 Aug 2009 04:44:51 +0700 Mikhail Gusarov CHR dotted...@dottedmag.net said: Is it ok to pass NULL parameters to ecore_evas_title_set / ecore_evas_name_class_set? If yes, what's the expected reaction of backend? Should it treat NULL parameters as empty strings or somehow else? CHR NULL. bad. use - empty title string. == segfault if someone passes NULL accidentally. Is it acceptable? -- http://fossarchy.blogspot.com/ pgpwi1422jstQ.pgp Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [evas] Add RGBA - grayscale 64 entries palette conversion
Twas brillig at 11:23:15 17.08.2009 UTC+10 when ras...@rasterman.com did gyre and gimble: CHR greayscale64? i thought they were 16 levels of grey (4bit)? well CHR the ones i saw? or is the 64 mapped to 16 with dithering? Actually 4-16, depending on the controller. 64 is just due to the some bug in X backend, which I did not yet found, something related to hardcoded 216 in ecore_x, though this bug does not harm functionality in any way - adjacent entries in palette become initialized with the same pixel values, reducing range to the one screen can display. -- http://fossarchy.blogspot.com/ pgpeNaLDT7SIx.pgp Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [evas] Add RGBA - grayscale 64 entries palette conversion
On Mon, 17 Aug 2009 09:02:31 +0700 Mikhail Gusarov dotted...@dottedmag.net said: Twas brillig at 11:42:20 17.08.2009 UTC+10 when ras...@rasterman.com did gyre and gimble: CH(R On Sun, 16 Aug 2009 20:25:10 +0700 Mikhail Gusarov dotted...@dottedmag.net CH(R said: This is needed for E-Ink devices outta there. Names of new files, configure.ac variables and macros are awful, suggestions are welcome. CHR strange that u use a palette table lookup and you like to use rgb CHR weighting on conversion to grayscale :) Well, I would ask X server for RGB values available in palette (is there approprite X request for this?), sort them and build Voronoi's diagram you can query palettes in x - yes. XGetRGBColormaps() to read colormaps. but i don't quite know how your x is set up? is it set up that its default visual is a greyscale one? or indexed color? truecolor? for optimal RGB-values mapping, but I felt it is kind of overkill :) Though it can be useful as a super-generic super-slow high-quality fallback. So I relied on the fact palette filler in EFL provides uniform filling, and hence the grayscale palette is a linear approximation of full-range 0..255 grayscale, so index in palette corresponds to the luminance picewise-linearily. /pretension to know math -- http://fossarchy.blogspot.com/ -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [evas] Add RGBA - grayscale 64 entries palette conversion
On Mon, 17 Aug 2009 08:56:09 +0700 Mikhail Gusarov dotted...@dottedmag.net said: Twas brillig at 11:23:15 17.08.2009 UTC+10 when ras...@rasterman.com did gyre and gimble: CHR greayscale64? i thought they were 16 levels of grey (4bit)? well CHR the ones i saw? or is the 64 mapped to 16 with dithering? Actually 4-16, depending on the controller. 64 is just due to the some bug in X backend, which I did not yet found, something related to hardcoded 216 in ecore_x, though this bug does not harm functionality in any way - adjacent entries in palette become initialized with the same pixel values, reducing range to the one screen can display. hmm. this doesn't sound good to me - but then again you have no dithering. if you dithered you would need to compress down to the exact range. eg 4, 8, 16 etc. levels. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_evas_title_set/ecore_evas_name_class_set NULL parameters
On Mon, 17 Aug 2009 08:46:58 +0700 Mikhail Gusarov dotted...@dottedmag.net said: Twas brillig at 11:30:24 17.08.2009 UTC+10 when ras...@rasterman.com did gyre and gimble: CHR On Mon, 17 Aug 2009 04:44:51 +0700 Mikhail Gusarov CHR dotted...@dottedmag.net said: Is it ok to pass NULL parameters to ecore_evas_title_set / ecore_evas_name_class_set? If yes, what's the expected reaction of backend? Should it treat NULL parameters as empty strings or somehow else? CHR NULL. bad. use - empty title string. == segfault if someone passes NULL accidentally. Is it acceptable? strcpy will segv if u pass a NULL string in. :) as will pretty much every str* call. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [evas] Add RGBA - grayscale 64 entries palette conversion
On Sun, 16 Aug 2009 20:25:10 +0700 Mikhail Gusarov dotted...@dottedmag.net said: This is needed for E-Ink devices outta there. Names of new files, configure.ac variables and macros are awful, suggestions are welcome. in svn. name isnt too bad really. strange that u use a palette table lookup and you like to use rgb weighting on conversion to grayscale :) i changed the code a little to use a bitshift :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_evas_title_set/ecore_evas_name_class_set NULL parameters
On Mon, 17 Aug 2009 04:44:51 +0700 Mikhail Gusarov dotted...@dottedmag.net said: Hello. Is it ok to pass NULL parameters to ecore_evas_title_set / ecore_evas_name_class_set? If yes, what's the expected reaction of backend? Should it treat NULL parameters as empty strings or somehow else? NULL. bad. use - empty title string. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [evas] Add RGBA - grayscale 64 entries palette conversion
Twas brillig at 11:42:20 17.08.2009 UTC+10 when ras...@rasterman.com did gyre and gimble: CH(R On Sun, 16 Aug 2009 20:25:10 +0700 Mikhail Gusarov dotted...@dottedmag.net CH(R said: This is needed for E-Ink devices outta there. Names of new files, configure.ac variables and macros are awful, suggestions are welcome. CHR strange that u use a palette table lookup and you like to use rgb CHR weighting on conversion to grayscale :) Well, I would ask X server for RGB values available in palette (is there approprite X request for this?), sort them and build Voronoi's diagram for optimal RGB-values mapping, but I felt it is kind of overkill :) Though it can be useful as a super-generic super-slow high-quality fallback. So I relied on the fact palette filler in EFL provides uniform filling, and hence the grayscale palette is a linear approximation of full-range 0..255 grayscale, so index in palette corresponds to the luminance picewise-linearily. /pretension to know math -- http://fossarchy.blogspot.com/ pgpE8g4ocE1kZ.pgp Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [eet] Update libeet1.symbols file
On Sun, 16 Aug 2009 21:39:23 +0700 Mikhail Gusarov dotted...@dottedmag.net said: Twas brillig at 16:37:14 16.08.2009 UTC+02 when albin.tonne...@gmail.com did gyre and gimble: Those symbols appeared earlier than in 1.2.2, but debian/libeet1.symbols was not updated, so there is no point to look at the actual minimal versions of symbols. AT Actually, it did get updated, SVN just didn't follow: see AT http://git.debian.org/?p=pkg-e/libs/eet.git;a=history;f=debian/libeet1.symbols;h=deb0e65f90dbb9aa49afb20feb2e0626970aa138;hb=master Okay. Maybe it's better then to remove debian/* from SVN to avoid confusion? hmm. no. debian has this policy of all packages must have their own package files done by debian developers. the problem is there are users out there wanting to make their own packages and don't want to start from scratch. in addition it is an example of how to package the libs - an intended packaging setup from upstream (which bits are modular, which bits are for development, etc. etc.) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
