Re: [E-devel] EET and EDJE improvements
On Jan 7, 2008 5:13 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Jan 4, 2008 8:43 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Jan 4, 2008 4:02 PM, Cedric BAIL [EMAIL PROTECTED] wrote: I am looking for a way to improve edje file load time. Right now a large amount of time is logically lost in _eet_data_descriptor_decode. So looking at its profile, most of the time is lost in manipulating string. Before getting into the details of your change ideas, could you explain the use case that you are profiling and the motivation behind it? For instance, are you seeing a slow load time when initially starting an application, or is this a case where various edje files are decoded over time, or accessing multiple data fields, etc? Sorry Nathan, I did reply directly to you and not to the mailing, it was a mistake. So I am profiling the time needed by an edje object to become visible/active to the end user after the edje_object_file_set. I was only testing with some quite complex edje file with many swallowed object. I just did test with multiple edje file at the same time and the profile result look the same. Nathan points are valid, of course, but I'm really interested in this kind of stuff, because it's mostly for free if you can mmap it, also it will help on high memory pressure situations, since these regions would be file-based and can be evicted and reloaded when app is used again (not a situation I'd like, but would help on embedded systems a bit). Yes, it should help and reduce memory presure on embedded systems. Cedric, something else related is trying to group these strings near, so when they're loaded they'd be on the same memory page, this would help disk seeks and the issue I pointed before. Any knowledge of this area? Right now, string are repeated a lot in the eet file and they are at many different place. If you want to see this, just change the call to eet_data_write inside edje_cc_out.c to not compress data. So packing them together in one section and reducing them to only one occurence inside the eet file could be another improvement. But the way I see it (adding a new kind of section at the end of the eet file and refering to it) will break backward compatibility (eet file using this will not be loadable with previous libeet). It could solve some of the issue you are pointing. A side effect of this solution, we will not need to tell the application anything about the char* we are giving to it. Because all of them will be in a uncompressed section available as long as the eet file is referenced somewhere. This solution break eet file representation but not eet application. -- Cedric BAIL - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e jeffdameth
On 01/06/2008 20:31, Enlightenment CVS wrote:
Enlightenment CVS committal
Author : jeffdameth
Project : e17
Module : apps/e
Dir : e17/apps/e/src/modules/pager
Modified Files:
e_mod_main.c
Log Message:
better naming for actions
replace whitespaces with tabs
I could be mistaken here but.
I beleive tabs are less than desirable. In fact I am about to go
through and replace all the vim cino directives in the code so that all
tabs are replaced by spaces. (after getting comments from the ML)
===
RCS file: /cvs/e/e17/apps/e/src/modules/pager/e_mod_main.c,v
retrieving revision 1.224
retrieving revision 1.225
diff -u -3 -r1.224 -r1.225
--- e_mod_main.c 7 Jan 2008 01:46:53 - 1.224
+++ e_mod_main.c 7 Jan 2008 02:31:52 - 1.225
@@ -701,7 +701,7 @@
pp-pager-popup = pp;
pp-urgent = 0;
-
+
e_zone_desk_count_get(zone, x, y);
if (keyaction)
@@ -735,11 +735,11 @@
((zone-h - h) / 2), w, h);
e_bindings_mouse_grab(E_BINDING_CONTEXT_POPUP, pp-popup-evas_win);
e_bindings_wheel_grab(E_BINDING_CONTEXT_POPUP, pp-popup-evas_win);
-
+
e_popup_show(pp-popup);
-
+
pp-timer = NULL;
-
+
return pp;
}
@@ -844,7 +844,7 @@
if (!pager_config) return;
if (pager_config-config_dialog) return;
/* FIXME: pass zone config item */
- _config_pager_module(NULL);
+ _config_pager_module(NULL);
return pager_config-config_dialog;
}
@@ -926,9 +926,9 @@
pd = l-data;
pw = _pager_desk_window_find(pd, ev-border);
if (pw) _pager_window_move(pw);
- }
+ }
}
-
+
return 1;
}
@@ -1099,7 +1099,7 @@
return 1;
}
-static void
+static void
_pager_window_desk_change(Pager *pager, E_Border *bd)
{
Evas_List *l;
@@ -1224,14 +1224,14 @@
E_Event_Border_Desk_Set *ev;
Evas_List *l;
Pager *p;
-
+
ev = event;
for (l = pagers; l; l = l-next)
{
p = l-data;
_pager_window_desk_change(p, ev-border);
}
-
+
return 1;
}
@@ -1544,7 +1544,7 @@
Pager *p;
Pager_Desk *pd;
Pager_Popup *pp;
-
+
ev = event;
for (l = pagers; l; l = l-next)
{
@@ -1562,7 +1562,7 @@
if (pager_config-popup !act_popup)
{
if (pp = _pager_popup_find(ev-desk-zone))
- {
+ {
ecore_timer_del(pp-timer);
}
else
@@ -1635,7 +1635,7 @@
{
Evas_Event_Mouse_In *ev;
Pager_Win *pw;
-
+
ev = event_info;
pw = data;
/* FIXME: display window title in some tooltip thing */
@@ -1660,7 +1660,7 @@
ev = event_info;
pw = data;
-
+
if (!pw) return;
if (pw-desk-pager-popup !act_popup) return;
if (pw-border-lock_user_location) return;
@@ -1689,13 +1689,13 @@
Evas_Event_Mouse_Up *ev;
Pager_Win *pw;
Pager *p;
-
+
ev = event_info;
pw = data;
if (!pw) return;
p = pw-desk-pager;
-
+
if (pw-desk-pager-popup !act_popup) return;
if (ev-button == pager_config-btn_desk) return;
if ((ev-button == pager_config-btn_drag) ||
@@ -1725,7 +1725,7 @@
unsigned int resist = 0;
Evas_Coord mx, my, vx, vy;
Pager_Desk *pd;
-
+
ev = event_info;
pw = data;
@@ -1769,7 +1769,7 @@
{
evas_object_geometry_get(pw-o_window, x, y, w, h);
evas_object_hide(pw-o_window);
-
+
drag = e_drag_new(pw-desk-pager-zone-container,
x, y, drag_types, 2, pw, -1,
_pager_window_cb_drag_convert,
@@ -1858,13 +1858,13 @@
}
else y = 0;
e_border_move(pw-border, x, y);
-
+
if (!(pw-border-lock_user_stacking))
e_border_raise(pw-border);
}
if (pw pw-drag.from_pager) pw-drag.from_pager-dragging = 0;
pw-drag.from_pager = NULL;
-
+
if (act_popup)
{
e_grabinput_get(input_window, 0, input_window);
@@ -1918,11 +1918,11 @@
p = data;
/* FIXME this fixes a segv, but the case is not easy
-* reproduceable. this makes no sense either since
-* the same 'pager' is passed to e_drop_handler_add
+* reproduceable. this makes no sense either since
+* the same 'pager' is passed to e_drop_handler_add
* and it works without this almost all the time.
* so this must be an issue with e_dnd code... i guess */
- if (act_popup) p = act_popup-pager;
+ if (act_popup) p = act_popup-pager;
_pager_update_drop_position(p, ev-x, ev-y);
@@ -1942,7 +1942,7 @@
ev = event_info;
p = data;
- if (act_popup) p = act_popup-pager;
+ if (act_popup) p = act_popup-pager;
_pager_update_drop_position(p, ev-x, ev-y);
@@ -1962,7 +1962,7 @@
Re: [E-devel] EET and EDJE improvements
On Jan 7, 2008 10:43 AM, Cedric BAIL [EMAIL PROTECTED] wrote: On Jan 7, 2008 5:13 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Jan 4, 2008 8:43 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Jan 4, 2008 4:02 PM, Cedric BAIL [EMAIL PROTECTED] wrote: I am looking for a way to improve edje file load time. Right now a large amount of time is logically lost in _eet_data_descriptor_decode. So looking at its profile, most of the time is lost in manipulating string. Before getting into the details of your change ideas, could you explain the use case that you are profiling and the motivation behind it? For instance, are you seeing a slow load time when initially starting an application, or is this a case where various edje files are decoded over time, or accessing multiple data fields, etc? Sorry Nathan, I did reply directly to you and not to the mailing, it was a mistake. So I am profiling the time needed by an edje object to become visible/active to the end user after the edje_object_file_set. I was only testing with some quite complex edje file with many swallowed object. I just did test with multiple edje file at the same time and the profile result look the same. Nathan points are valid, of course, but I'm really interested in this kind of stuff, because it's mostly for free if you can mmap it, also it will help on high memory pressure situations, since these regions would be file-based and can be evicted and reloaded when app is used again (not a situation I'd like, but would help on embedded systems a bit). Yes, it should help and reduce memory presure on embedded systems. Cedric, something else related is trying to group these strings near, so when they're loaded they'd be on the same memory page, this would help disk seeks and the issue I pointed before. Any knowledge of this area? Right now, string are repeated a lot in the eet file and they are at many different place. If you want to see this, just change the call to eet_data_write inside edje_cc_out.c to not compress data. So packing them together in one section and reducing them to only one occurence inside the eet file could be another improvement. But the way I see it (adding a new kind of section at the end of the eet file and refering to it) will break backward compatibility (eet file using this will not be loadable with previous libeet). It could solve some of the issue you are pointing. A side effect of this solution, we will not need to tell the application anything about the char* we are giving to it. Because all of them will be in a uncompressed section available as long as the eet file is referenced somewhere. This solution break eet file representation but not eet application. I'm not sure others will like, but I do like this idea, and given raster's word that after E is marked stable, it will have to be stable, so break things before it's released, I really think we should fix this now (and break compat) rather than staying with this for some years more. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e jeffdameth
On Jan 7, 2008 11:35 AM, Ravenlock [EMAIL PROTECTED] wrote: On 01/06/2008 20:31, Enlightenment CVS wrote: Enlightenment CVS committal Author : jeffdameth Project : e17 Module : apps/e Dir : e17/apps/e/src/modules/pager Modified Files: e_mod_main.c Log Message: better naming for actions replace whitespaces with tabs I could be mistaken here but. I beleive tabs are less than desirable. In fact I am about to go through and replace all the vim cino directives in the code so that all tabs are replaced by spaces. (after getting comments from the ML) raster's coding style (joe default?) is 1 tab to replace 8 spaces, weird I know... :-/ -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] e17 and (Open/Net)BSD
Hey, in the wiki (http://wiki.enlightenment.org/index.php/E17_User_Guide/Installing_on_BSD_systems), it is said that NetBSD and OpenBSD OS can't install eet (hence e17) because printf can not support %a conversion specifier. Hopefully we have fixed that as we have our own double - hexa conversion methods in eet. So: 1) I think that people who have those OS should test e17 (cvs), now. 2) If there's no problem, then we should modify the wiki accordingly. is there some volunteer to test e17 on those platform ? Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 and (Open/Net)BSD
On Jan 7, 2008 9:03 AM, Vincent Torri [EMAIL PROTECTED] wrote: Hey, in the wiki (http://wiki.enlightenment.org/index.php/E17_User_Guide/Installing_on_BSD_systems), it is said that NetBSD and OpenBSD OS can't install eet (hence e17) because printf can not support %a conversion specifier. Hopefully we have fixed that as we have our own double - hexa conversion methods in eet. So: 1) I think that people who have those OS should test e17 (cvs), now. 2) If there's no problem, then we should modify the wiki accordingly. is there some volunteer to test e17 on those platform ? One of the OpenBSD guys (nervox on freenode) has confirmed it works on OpenBSD (all the way up to e17, perhaps with minor autofoo patches) -- Hisham Mardam Bey http://hisham.cc/ +1-514-713-9312 Codito Ergo Sum (I Code Therefore I Am) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 and (Open/Net)BSD
Hi On Jan 7, 2008 4:03 PM, Vincent Torri [EMAIL PROTECTED] wrote: Hey, in the wiki (http://wiki.enlightenment.org/index.php/E17_User_Guide/Installing_on_BSD_systems), it is said that NetBSD and OpenBSD OS can't install eet (hence e17) because printf can not support %a conversion specifier. That should be fixed. It works under OpenBSD (it worked with libtrio with some hacks) thanks to the changes in the source to remove the %a specific (1 cookie for the dev that made that change). Hopefully we have fixed that as we have our own double - hexa conversion methods in eet. So: 1) I think that people who have those OS should test e17 (cvs), now. 2) If there's no problem, then we should modify the wiki accordingly. is there some volunteer to test e17 on those platform ? E17 is now in the port system for OpenBSD (-current), it is not linked into the main build yet (no compiled packages)so you have to compile them by hand by downloading the port tree and installing them(http://www.openbsd.org/ports.html). There are still some rough edges but it is usable and i am working on improving it. I will send the openbsd specific patches as soon as i get some free time. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel The list of people to thank that helped in that effort is too big, but in all cases THANK YOU (you know who you are). Kind regards, Laurent. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e jeffdameth
On 01/07/2008 07:48, Gustavo Sverzut Barbieri wrote: On Jan 7, 2008 11:35 AM, Ravenlock [EMAIL PROTECTED] wrote: On 01/06/2008 20:31, Enlightenment CVS wrote: Enlightenment CVS committal Author : jeffdameth Project : e17 Module : apps/e Dir : e17/apps/e/src/modules/pager Modified Files: e_mod_main.c Log Message: better naming for actions replace whitespaces with tabs I could be mistaken here but. I beleive tabs are less than desirable. In fact I am about to go through and replace all the vim cino directives in the code so that all tabs are replaced by spaces. (after getting comments from the ML) raster's coding style (joe default?) is 1 tab to replace 8 spaces, weird I know... :-/ I thought it was the other way around. It was my understanding that raster replaced the tabs with 8 spaces. I must be mistaken. Either way... the sources are a hodgepodge of formatting. I wonder what folks would think of a document formalizing the style of the sources. And possible a set of scripts to sweep through and correct them. Any thoughts? -- Regards, Ravenlock signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e jeffdameth
On Monday, 07 January 2008, at 09:21:25 (-0600), Ravenlock wrote: raster's coding style (joe default?) is 1 tab to replace 8 spaces, weird I know... :-/ I thought it was the other way around. It was my understanding that raster replaced the tabs with 8 spaces. I must be mistaken. No, Gustavo is. raster's style is contained in e17/libs/imlib2/.indent.pro: -i3 -nut -brs -bl -bad -nbap -sob -ncdb -di20 -nbc -lp -nce -npcs -sc -ncs -l80 Note the -nut which means use spaces, not tabs. Either way... the sources are a hodgepodge of formatting. I wonder what folks would think of a document formalizing the style of the sources. And possible a set of scripts to sweep through and correct them. Any thoughts? No script is needed. Just run indent on the sources with the options shown above. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- Follow me; everything is alright. I'll be the one to tuck you in at night. And if you want to leave, I can guarantee you won't find nobody else like me. -- Uncle Kracker, Follow Me - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e jeffdameth
On 01/07/2008 09:26, Michael Jennings wrote: On Monday, 07 January 2008, at 09:21:25 (-0600), Ravenlock wrote: raster's coding style (joe default?) is 1 tab to replace 8 spaces, weird I know... :-/ I thought it was the other way around. It was my understanding that raster replaced the tabs with 8 spaces. I must be mistaken. No, Gustavo is. raster's style is contained in e17/libs/imlib2/.indent.pro: -i3 -nut -brs -bl -bad -nbap -sob -ncdb -di20 -nbc -lp -nce -npcs -sc -ncs -l80 Excellent. I had not seen this in cvs. This is exactly what is needed. Thanks. Note the -nut which means use spaces, not tabs. Either way... the sources are a hodgepodge of formatting. I wonder what folks would think of a document formalizing the style of the sources. And possible a set of scripts to sweep through and correct them. Any thoughts? No script is needed. Just run indent on the sources with the options shown above. Michael -- Regards, Ravenlock signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e jeffdameth
On 7-Jan-08, at 10:26 AM, Michael Jennings wrote: On Monday, 07 January 2008, at 09:21:25 (-0600), Ravenlock wrote: Either way... the sources are a hodgepodge of formatting. I wonder what folks would think of a document formalizing the style of the sources. And possible a set of scripts to sweep through and correct them. Any thoughts? No script is needed. Just run indent on the sources with the options shown above. Note that it is only Rasters code that is formatted this way. Don't run this against all the source in CVS as I know for a fact it's wrong for Efreet and Ewl. dan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e jeffdameth
On 01/07/2008 09:52, dan sinclair wrote: On 7-Jan-08, at 10:26 AM, Michael Jennings wrote: On Monday, 07 January 2008, at 09:21:25 (-0600), Ravenlock wrote: Either way... the sources are a hodgepodge of formatting. I wonder what folks would think of a document formalizing the style of the sources. And possible a set of scripts to sweep through and correct them. Any thoughts? No script is needed. Just run indent on the sources with the options shown above. Note that it is only Rasters code that is formatted this way. Don't run this against all the source in CVS as I know for a fact it's wrong for Efreet and Ewl. I will definitely not go off and run indent on everyones code. Additionally, I will not go off and run it on *anyones* code until it has been discussed on the ML. I think it would be helpful across the board, for all devs involved if we had proper indent specifications so that all code could be kept consistent in this fashion. Meaning if each app/lib had its own indent spec, thats fine, as long as it exists and can be found and used by folks. This way you could happily write code in your own style, then indent it and ci. Just a thought. I will propose something along these lines in a separate thread as soon as I can, for comments. dan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Regards, Ravenlock signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e jeffdameth
On 01/07/2008 10:50, Michael Jennings wrote: On Monday, 07 January 2008, at 10:52:57 (-0500), dan sinclair wrote: Note that it is only Rasters code that is formatted this way. Don't run this against all the source in CVS as I know for a fact it's wrong for Efreet and Ewl. Each project is responsible for keeping a .indent.pro at the top level (see e_modules for an example). Any project not doing so is subject to the default style. This makes it easy for both project maintainers and the cleanup crew. I've run the .indent.pro you point out on several files in e/src/bin... and the difference is quite alarming! I'd say the cleanup crew has not been around in some time. Michael -- Regards, Ravenlock signature.asc Description: OpenPGP digital signature - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e jeffdameth
On Jan 7, 2008 1:26 PM, Michael Jennings [EMAIL PROTECTED] wrote: On Monday, 07 January 2008, at 09:21:25 (-0600), Ravenlock wrote: raster's coding style (joe default?) is 1 tab to replace 8 spaces, weird I know... :-/ I thought it was the other way around. It was my understanding that raster replaced the tabs with 8 spaces. I must be mistaken. No, Gustavo is. raster's style is contained in e17/libs/imlib2/.indent.pro: -i3 -nut -brs -bl -bad -nbap -sob -ncdb -di20 -nbc -lp -nce -npcs -sc -ncs -l80 Note the -nut which means use spaces, not tabs. Really? Every time raster touch code I see spaces replaced by tabs, I even had to change my .emacs to reflect this for files under ~/Development/cvs/e17 -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e jeffdameth
Gustavo Sverzut Barbieri wrote: On Jan 7, 2008 1:26 PM, Michael Jennings [EMAIL PROTECTED] wrote: On Monday, 07 January 2008, at 09:21:25 (-0600), Ravenlock wrote: raster's coding style (joe default?) is 1 tab to replace 8 spaces, weird I know... :-/ I thought it was the other way around. It was my understanding that raster replaced the tabs with 8 spaces. I must be mistaken. No, Gustavo is. raster's style is contained in e17/libs/imlib2/.indent.pro: -i3 -nut -brs -bl -bad -nbap -sob -ncdb -di20 -nbc -lp -nce -npcs -sc -ncs -l80 Note the -nut which means use spaces, not tabs. Really? Every time raster touch code I see spaces replaced by tabs, I even had to change my .emacs to reflect this for files under ~/Development/cvs/e17 I put that file there at a point where I got annoyed with the formatting style mess in imlib2. The formatting style details, among other things tabs/spaces, were set up in an attempt to minimize the overall change caused by running indent on src/lib/*.c at that time. IIRC using spaces in stead of tabs resulted in slightly fewer changes. Actually, I think the original raster formatting style is closer to the one in e16/e/.indent.pro, which specifies to use tabs. I think it would be a good thing to specify a recommended/default indent profile, and require that apps/libs explicitly place a .indent.pro at top level if they want to deviate. /Kim - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
On Mon, 7 Jan 2008, Kim Woelders wrote: I put that file there at a point where I got annoyed with the formatting style mess in imlib2. The formatting style details, among other things tabs/spaces, were set up in an attempt to minimize the overall change caused by running indent on src/lib/*.c at that time. IIRC using spaces in stead of tabs resulted in slightly fewer changes. Actually, I think the original raster formatting style is closer to the one in e16/e/.indent.pro, which specifies to use tabs. I think it would be a good thing to specify a recommended/default indent profile, and require that apps/libs explicitly place a .indent.pro at top level if they want to deviate. about tabs vs spaces, I would prefer spaces. We all have different text editors, configured in some ways. Not mentionning all other people that do not develop on e and want to see the sources. That imply that a source code using tabs will look horrible to the reader if the text editor is not configured with the correct number of spaces for a tabulation. other thoughts ? Vincent - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e jeffdameth
On Monday, 07 January 2008, at 19:58:38 (+0100), Kim Woelders wrote: I put that file there at a point where I got annoyed with the formatting style mess in imlib2. The formatting style details, among other things tabs/spaces, were set up in an attempt to minimize the overall change caused by running indent on src/lib/*.c at that time. IIRC using spaces in stead of tabs resulted in slightly fewer changes. Actually, I think the original raster formatting style is closer to the one in e16/e/.indent.pro, which specifies to use tabs. I think it would be a good thing to specify a recommended/default indent profile, and require that apps/libs explicitly place a .indent.pro at top level if they want to deviate. Here are the original indent profiles from back when we first started using indent: alias indent-mej=indent -bap -bbo -br -brs -ce -ci4 -cli2 -cs -di1 -hnl -i4 -l140 -lp -lps -nbc -npcs -nss -nsob -pmt -psl -ts 999 alias indent-raster=indent -i3 -bl -bad -nbap -sob -ncdb -di20 -nbc -lp -nce -npcs -sc -ncs -l80 alias indent-mandrake=indent -i3 -bl -bad -nbap -sob -ncdb -di20 -nbc -lp -nce -npcs -sc -ncs -l80 alias indent-gilbertt=indent -nbad -bap -nbc -bbo -bl -bli2 -bls -ncdb -nce -cp1 -cs -di2 -ndj -nfc1 -nfca -hnl -i2 -ip5 -lp -pcs -psl -nsc -nsob alias indent-ck=indent -i3 -bl -bad -nbap -sob -ncdb -di20 -nbc -lp -nce -npcs -sc -ncs -l80 At this point in time, I'm pretty sure we (or at least I) looked for a way to prevent the use of tabs, and there was no option for it at the time (at least that we found) in the version we were using. You'll notice the -ts 999 in mine -- that did essentially the same thing. This was back in 1999, so things have changed since then, obviously. Bottom line: Spaces make sure everyone sees the same indentation. Tabs do not. Since re-indenting code is very easy these days, using tabs as a way of defining spacing is no longer useful and actually does more harm than good. So use spaces, not tabs. If your version of indent still defaults to using tabs, add -nut. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- And you women try to make us feel better about it. 'It's not the size of the ship that counts; it's the motion of the ocean.' Well, that may be true, but it takes an awfully long time to get to England in a rowboat. -- Jeff Foxworthy - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 and (Open/Net)BSD
On Mon, Jan 07, 2008 at 03:03:30PM +0100, Vincent Torri wrote: Hey, in the wiki (http://wiki.enlightenment.org/index.php/E17_User_Guide/Installing_on_BSD_systems), it is said that NetBSD and OpenBSD OS can't install eet (hence e17) because printf can not support %a conversion specifier. Hopefully we have fixed that as we have our own double - hexa conversion methods in eet. So: 1) I think that people who have those OS should test e17 (cvs), now. 2) If there's no problem, then we should modify the wiki accordingly. is there some volunteer to test e17 on those platform ? I recently successfully build e17 on NetBSD-current. Only a few minor tweaks were needed. Regards, Daniel -- Daniel Sieger Faculty of Technology Bielefeld University wwwhomes.uni-bielefeld.de/dsieger - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
Vincent Torri wrote: On Mon, 7 Jan 2008, Kim Woelders wrote: I put that file there at a point where I got annoyed with the formatting style mess in imlib2. The formatting style details, among other things tabs/spaces, were set up in an attempt to minimize the overall change caused by running indent on src/lib/*.c at that time. IIRC using spaces in stead of tabs resulted in slightly fewer changes. Actually, I think the original raster formatting style is closer to the one in e16/e/.indent.pro, which specifies to use tabs. I think it would be a good thing to specify a recommended/default indent profile, and require that apps/libs explicitly place a .indent.pro at top level if they want to deviate. about tabs vs spaces, I would prefer spaces. We all have different text editors, configured in some ways. Not mentionning all other people that do not develop on e and want to see the sources. That imply that a source code using tabs will look horrible to the reader if the text editor is not configured with the correct number of spaces for a tabulation. other thoughts ? I prefer spaces too, although I don't care much one way or the other, as long as the rules are clear (and the line length is set to 80 of course :) ). /Kim - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] R: Re: Evas_Event propagation
On Dec 20, 2007 12:36 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote:
I think that there was some consensus that the API to feed the objects
events would be a good addition, but I don't think anyone got around
to implementing it.
Last days I've tried to come up with such API, in
src/lib/evas_events.c. I did two
things mainly (1) refactor a little bit the code there; (2) add the
public feeders for mouse_up and mouse_down. Even if we don't get a
consensus about things in patch (2), I think after some review the
patch (1) is benefical. So I can commit patch (1) if it's OK. Please,
if any of you understand about src/lib/evas_events, review this patch
:-)
And now follows a long story (which might be of Dave's interest)... ;-)
My main motivation for giving a try doing this public API to feeding
events directly into Evas_Objects was the same as Dave, quoting him:
Dave wrote:
I have a trasparent evas_object (big as all the container) used
to grab mouse events. When you click drag the mouse I make the
container scroll. The objects of the list also need mouse events
so I used evas_object_repeat_events_set(cont-grabber, TRUE);
to pass the mouse events.
The problem is that I want to 'repeat' the events only when is not
a dragging operation.
In the grabber mouse,down callback I need to stop the propagation
of the event to the object below...
Here's how I solved this once:
Python-etk binding has a List widget implementation (which need a lot
of love yet but works) to serve as example of creating new widgets
directly in Python. The renderers in the list (Edje objects) that
follow a special convention, they must have hit areas but don't use
the mouse events. The List itself (actually the visible row) will
listen to these mouse events and dispatch accordingly.
In the end, an Edje renderer you just have to implement those methods
pressed(), clicked(), unpressed() which pass the hit area (the part)
as argument. So you can use your programs and process them correctly
(e.g.: if its a click in the part button_area, emit the
button_clicked signal).
Notice: I can do things like pressed / unpressed, that behaves
differrently for a non-kinetic-like list. For instance, if my row has
a text and a button, if I press the button [it will call pressed() in
my renderer] and move up up up, it will interpret this not as click,
but as a drag and call unpressed() properly, even if I didn't
unpressed the _mouse_ button. This allows you use sensitive areas to
drag.
But I'm having hard time figuring out something like this behaviour
being implemented with the feeders or an solution like stop the
event processing if we return 0.
So, assuming that we have all the feeders (I can finish the missing
ones if people consider them worthy to have), how to reproduce this
pressed/unpressed/clicked in a kinetic list? Ideas?
We could feed a MOUSE_OUT event to do that unpressed thing, but it's
a little strange since the mouse won't be OUT. And I'm not sure
whether DOWN/UP (in Edje) keep states and stuff like that. So we would
need to call UP too, but this can't trigger a CLICK.
Cheers,
Caio Marcelo
From e008ce0b388e533f08f70f3a7699a114610cbe12 Mon Sep 17 00:00:00 2001
From: Caio Marcelo de Oliveira Filho [EMAIL PROTECTED]
Date: Fri, 4 Jan 2008 18:35:23 -0300
Subject: [PATCH] evas_events cleaning up, part 1
My focus is in the end have a good way to feed specific Evas_Objects with events, as previous
discussed by the folks in the mailing list.
- Extracting the functions that fill Evas_Event structures, this avoided a bit of repetition.
- Separating some functions to make easy creating public API event feeders per object.
---
src/lib/canvas/evas_events.c | 520 +++---
1 files changed, 236 insertions(+), 284 deletions(-)
diff --git a/src/lib/canvas/evas_events.c b/src/lib/canvas/evas_events.c
index af853e2..ba9bceb 100644
--- a/src/lib/canvas/evas_events.c
+++ b/src/lib/canvas/evas_events.c
@@ -10,7 +10,7 @@ evas_event_passes_through(Evas_Object *obj)
if (obj-smart.parent)
{
int par_pass;
-
+
par_pass = evas_event_passes_through(obj-smart.parent);
obj-parent_cache_valid = 1;
obj-parent_pass_events = par_pass;
@@ -20,59 +20,72 @@ evas_event_passes_through(Evas_Object *obj)
}
static Evas_List *
-_evas_event_object_list_in_get(Evas *e, Evas_List *in, Evas_Object_List *list, Evas_Object *stop, int x, int y, int *no_rep)
+_evas_event_object_list_in_get(Evas *e, Evas_List *in, Evas_Object_List *list, Evas_Object *stop, int x, int y, int *no_rep);
+
+static Evas_List *
+_evas_event_object_list_in_get_by_object(Evas *e, Evas_List *in, Evas_Object *obj, Evas_Object *stop, int x, int y, int *no_rep)
{
- Evas_Object_List *l;
+ if (obj == stop)
+ {
+ *no_rep = 1;
+ return in;
+ }
- if (!list) return in;
- for (l = list-last; l; l = l-prev)
+ /* In all this cases an object (and its possible smart children)
+ is not suitable for receiving the event. */
+ if
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
Michael Jennings wrote: On Monday, 07 January 2008, at 21:06:04 (+0100), Kim Woelders wrote: (and the line length is set to 80 of course :) ). I got into the habit of using 132 instead of 80 because 80 columns is all too often not enough for readability, particularly when using lengthier OO-style function naming (namespace_object_action(OBJECT_CAST(object), ...) -- See how ugly that wrapped? Ick!), and the vast majority of terminals (including xterm and Eterm) have 80/132 column toggles built-in, even key-bindable. To me, sticking with an 80-column limit for coding is like using gcc 2.7.2.3 to compile all your software: it was great 10 years ago, but we live in a different world now. Even the Linux console itself can do well beyond 80 columns. :) But tabs vs. spaces is far more likely to result in spaghetti code then setting the column limit. Michael Yeah, I was just trolling (although the 80 is about the only thing I do care about). We are talking personal preferences here and are most likely never going to agree. You say when I write code like this I really need very long lines and to that I will say then don't write code like that. Somebody(?) should just lay down the rules so it's clear what they are. /Kim - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
Kim Woelders schrieb: Michael Jennings wrote: On Monday, 07 January 2008, at 21:06:04 (+0100), Kim Woelders wrote: (and the line length is set to 80 of course :) ). I got into the habit of using 132 instead of 80 because 80 columns is all too often not enough for readability, particularly when using lengthier OO-style function naming (namespace_object_action(OBJECT_CAST(object), ...) -- See how ugly that wrapped? Ick!), and the vast majority of terminals (including xterm and Eterm) have 80/132 column toggles built-in, even key-bindable. To me, sticking with an 80-column limit for coding is like using gcc 2.7.2.3 to compile all your software: it was great 10 years ago, but we live in a different world now. Even the Linux console itself can do well beyond 80 columns. :) But tabs vs. spaces is far more likely to result in spaghetti code then setting the column limit. Michael Yeah, I was just trolling (although the 80 is about the only thing I do care about). We are talking personal preferences here and are most likely never going to agree. You say when I write code like this I really need very long lines and to that I will say then don't write code like that. Somebody(?) should just lay down the rules so it's clear what they are. Full ack. Peter - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ECORE_CALLBACK_KEEP and ECORE_CALLBACK_REMOVE
Peter Wehrfritz schrieb: Hi all, I want to add two aliases (ECORE_CALLBACK_KEEP and ECORE_CALLBACK_REMOVE) to Ecore.h. They can be used as return values for the ecore callbacks like timer, idler etc. Imho that improves code-readability and helps (at least me) to write code, because you don't have to remember if 0 stops the timer or keeps it. I've talked with Nathan about it and he prefers ECORE_CALLBACK_STOP/REPEAT. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ECORE_CALLBACK_KEEP and ECORE_CALLBACK_REMOVE
On Tuesday, 08 January 2008, at 00:59:22 (+0100), Peter Wehrfritz wrote: I want to add two aliases (ECORE_CALLBACK_KEEP and ECORE_CALLBACK_REMOVE) to Ecore.h. They can be used as return values for the ecore callbacks like timer, idler etc. Imho that improves code-readability and helps (at least me) to write code, because you don't have to remember if 0 stops the timer or keeps it. I've talked with Nathan about it and he prefers ECORE_CALLBACK_STOP/REPEAT. _RENEW and _CANCEL would be more intuitive, IMHO. Just a thought. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- It is strange to be known so universally and yet be so lonely. -- Albert Einstein - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-01-05 01:11:07 -0800
Build log for Enlightenment DR 0.17 on 2008-01-05 01:11:07 -0800 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: edvi http://download.enlightenment.org/tests/logs/edvi.log engage http://download.enlightenment.org/tests/logs/engage.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, cpu, deskshow, eclair, ecore, edb, e_dbus, edje_editor, edje, edje_viewer, eet, eflame, eflpp, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emu, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, exhibit, exml, expedite, express, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, net, news, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-01-05 22:01:43 -0800
Build log for Enlightenment DR 0.17 on 2008-01-05 22:01:43 -0800 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: edvi http://download.enlightenment.org/tests/logs/edvi.log engage http://download.enlightenment.org/tests/logs/engage.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, cpu, deskshow, eclair, ecore, edb, e_dbus, edje_editor, edje, edje_viewer, eet, eflame, eflpp, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emu, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, exhibit, exml, expedite, express, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, net, news, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-01-06 07:32:40 -0800
Build log for Enlightenment DR 0.17 on 2008-01-06 07:32:40 -0800 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: edvi http://download.enlightenment.org/tests/logs/edvi.log engage http://download.enlightenment.org/tests/logs/engage.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, cpu, deskshow, eclair, ecore, edb, e_dbus, edje_editor, edje, edje_viewer, eet, eflame, eflpp, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emu, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, exhibit, exml, expedite, express, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, net, news, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ECORE_CALLBACK_KEEP and ECORE_CALLBACK_REMOVE
That would be reasonable as well, as long as it clearly indicates that it prevents or allows the callback from recurring. On Jan 7, 2008 6:12 PM, Michael Jennings [EMAIL PROTECTED] wrote: On Tuesday, 08 January 2008, at 00:59:22 (+0100), Peter Wehrfritz wrote: I want to add two aliases (ECORE_CALLBACK_KEEP and ECORE_CALLBACK_REMOVE) to Ecore.h. They can be used as return values for the ecore callbacks like timer, idler etc. Imho that improves code-readability and helps (at least me) to write code, because you don't have to remember if 0 stops the timer or keeps it. I've talked with Nathan about it and he prefers ECORE_CALLBACK_STOP/REPEAT. _RENEW and _CANCEL would be more intuitive, IMHO. Just a thought. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- It is strange to be known so universally and yet be so lonely. -- Albert Einstein - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: taskbar iamsthitha
Enlightenment CVS wrote:
EAPI int
-e_modapi_save(E_Module *m)
+e_modapi_save (E_Module * m)
Should these spaces be there (before '(' and '*')? The rest of the code
is like the former version.
Sebastian
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
