Re: [E-devel] E CVS: libs/ecore pfritz
Hi! 1) Why ecore_str_vector_free was removed ? 2) Do you think 2/3 optionals string's functions could be good to have in ecore ? - ecore_str_strdup_printf(format, ...) - ecore_str_memcpy(void *, size) see you Peter Wehrfritz wrote: Long and messy. Find better version attached. And as a bonus, you only have to free the array pointer and its first element. Quickie test program supplied also. Michael Thanks committed. It is indeed much faster. I changed it slightly, because your version had some problems with empty strings. Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
On Tue, 13 Mar 2007, Stéphane Bauland wrote: Hi! 1) Why ecore_str_vector_free was removed ? now, you only need to free the returned pointer. There's no need for a function to do that :) I let the others comment the 2nd question :) Vincent- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
Vincent Torri wrote: On Tue, 13 Mar 2007, Stéphane Bauland wrote: Hi! 1) Why ecore_str_vector_free was removed ? now, you only need to free the returned pointer. There's no need for a function to do that :) I let the others comment the 2nd question :) Vincent Hehe ! I got a memory leak here : ligne 165 (ecore_str.c) :s = strdup(str); looks like it isn't freed. ==9844== ==9844== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 109 from 1) ==9844== malloc/free: in use at exit: 60 bytes in 1 blocks. ==9844== malloc/free: 3 allocs, 2 frees, 328 bytes allocated. ==9844== For counts of detected errors, rerun with: -v ==9844== searching for pointers to 1 not-freed blocks. ==9844== checked 558,804 bytes. ==9844== ==9844== 60 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==9844==at 0x401D4B0: malloc (vg_replace_malloc.c:149) ==9844==by 0x468A53F: strdup (in /lib/tls/libc-2.3.6.so) ==9844==by 0x404A51B: ecore_str_split (ecore_str.c:165) ==9844==by 0x8048732: str_split (test.c:12) ==9844==by 0x80487A4: main (test.c:23) ==9844== ==9844== LEAK SUMMARY: ==9844==definitely lost: 60 bytes in 1 blocks. ==9844== possibly lost: 0 bytes in 0 blocks. ==9844==still reachable: 0 bytes in 0 blocks. ==9844== suppressed: 0 bytes in 0 blocks. See you - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore devilhorns
Vincent Torri wrote: I don't think that all the tests on _dpms_available are necessary. Your program has to test it once, then do the necessary to not use the dpms functions. Vincent On Tue, 13 Mar 2007, Enlightenment CVS wrote: Log Message: Fix up ecore_x_dpms...formatting, removed the static int's for dpms version as they are not used anywhere other than the init function. Added traps for dpms_available before calling any dpms functions. And if the calling program does not make those tests??? Segfault !!.. These are just simple int checks which are very fast todo and not expensive at all, plus give added safety to insure that dpms can be used before trying to make calls to it. I don't see the problem here.. dh - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz || LEAK PATCH
Vincent Torri wrote:
On Tue, 13 Mar 2007, Stéphane Bauland wrote:
Hi!
1) Why ecore_str_vector_free was removed ?
now, you only need to free the returned pointer. There's no need for a
function to do that :)
I let the others comment the 2nd question :)
Vincent
Ok ok i solve memory leak... I don't know if it's a correct way to
remove it but apparently it's ok.
? ecorestr.patch
cvs diff: Diffing .
Index: ecore_str.c
===
RCS file: /var/cvs/e/e17/libs/ecore/src/lib/ecore/ecore_str.c,v
retrieving revision 1.7
diff -u -r1.7 ecore_str.c
--- ecore_str.c 13 Mar 2007 06:46:14 - 1.7
+++ ecore_str.c 13 Mar 2007 10:07:48 -
@@ -164,9 +164,10 @@
dlen = strlen(delim);
s = strdup(str);
str_array = malloc(sizeof(char *) * (len + 1));
- for (i = 0; (i max_tokens) (sep = strstr(s, delim)); i++)
+ for (i = 0; (i max_tokens) (sep = strstr(s, delim)); i++)
{
str_array[i] = s;
+ if ( i == 0 ) FREE(s);
s = sep + dlen;
*sep = 0;
}
@@ -174,7 +175,6 @@
str_array[i++] = s;
str_array = realloc(str_array, sizeof(char *) * (i + 1));
str_array[i] = NULL;
-
return str_array;
}
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
Stéphane Bauland schrieb:
Vincent Torri wrote:
On Tue, 13 Mar 2007, Stéphane Bauland wrote:
Hi!
1) Why ecore_str_vector_free was removed ?
now, you only need to free the returned pointer. There's no need for a
function to do that :)
I let the others comment the 2nd question :)
Vincent
Hehe ! I got a memory leak here :
Don't believe caro, read the doxy :).
i. e. if (vec) {free(*vec); free(vec);}
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore devilhorns
Vincent Torri wrote: On Tue, 13 Mar 2007, Christopher Michael wrote: Vincent Torri wrote: I don't think that all the tests on _dpms_available are necessary. Your program has to test it once, then do the necessary to not use the dpms functions. And if the calling program does not make those tests??? Segfault !!.. These are just simple int checks which are very fast todo and not expensive at all, plus give added safety to insure that dpms can be used before trying to make calls to it. I don't see the problem here.. It's not really a problem. Maybe just not the correct location for that fix. For me you use the ecore_x_dpms_query as all the _init function you can find in the efl. Also, it's the only location where such tests are done (see ecore_x_(damage, fixes, etc...). So for me, the fix should be done in e17, not in ecore_x_dpms Vincent Perhaps...my thoughts were for use outside of E where someone may not make those checks...at least this way ecore (and potentially outside app) doesn't die a horrid death :) dh - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
On Tue, 13 Mar 2007, Peter Wehrfritz wrote:
Stéphane Bauland schrieb:
Vincent Torri wrote:
On Tue, 13 Mar 2007, Stéphane Bauland wrote:
Hi!
1) Why ecore_str_vector_free was removed ?
now, you only need to free the returned pointer. There's no need for a
function to do that :)
I let the others comment the 2nd question :)
Vincent
Hehe ! I got a memory leak here :
Don't believe caro, read the doxy :).
i. e. if (vec) {free(*vec); free(vec);}
yes, you're right. I based my comment on what mej said.
Why not only returning str, instread of str_array, which is allocated for
nothing, imho ?
Vincent-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore devilhorns
On Tue, 13 Mar 2007, Christopher Michael wrote: Vincent Torri wrote: I don't think that all the tests on _dpms_available are necessary. Your program has to test it once, then do the necessary to not use the dpms functions. And if the calling program does not make those tests??? Segfault !!.. These are just simple int checks which are very fast todo and not expensive at all, plus give added safety to insure that dpms can be used before trying to make calls to it. I don't see the problem here.. I thought that the #ifedf werethere. Seb added them, those tests should not be necessary Vincent - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
On Tuesday, 13 March 2007, at 01:53:57 (+0100), Peter Wehrfritz wrote: Thanks committed. It is indeed much faster. I changed it slightly, because your version had some problems with empty strings. I intentionally left out the sanity checks at the beginning so I could test it without having too much macro overhead in the way. :) And I never really thought about how an empty delim string should be handled; your choice seems logical. On Tuesday, 13 March 2007, at 09:26:08 (+0100), St?phane Bauland wrote: 1) Why ecore_str_vector_free was removed ? It's unnecessary. 2) Do you think 2/3 optionals string's functions could be good to have in ecore ? - ecore_str_strdup_printf(format, ...) - ecore_str_memcpy(void *, size) No. Completely unnecessary. Hehe ! I got a memory leak here : ligne 165 (ecore_str.c) :s = strdup(str); looks like it isn't freed. Did you not read the code? or at least my mailing list message? And as a bonus, you only have to free the array pointer and its first element. Thank you for dining at the Clueburger; please drive through. Ok ok i solve memory leak... I don't know if it's a correct way to remove it but apparently it's ok. No, this is completely wrong and demonstrates no understanding whatsoever of the underlying code. Ridiculous. On Tuesday, 13 March 2007, at 10:59:21 (+0100), Sebastian Dransfeld wrote: Wrong fix! The user must free ret[0] ret. No other possibility. The question is whether this function should do a destructive split or not. I take it you missed the s = strdup(str) at the beginning Did ANYBODY actually bother to see how the code works besides Peter? On Tuesday, 13 March 2007, at 11:38:27 (+0100), Vincent Torri wrote: yes, you're right. I based my comment on what mej said. You misunderstood what mej said. See above. Why not only returning str, instread of str_array, which is allocated for nothing, imho ? YHO is wrong. :) str_array holds the pointers to the tokens just like before. The difference is that I save a crapload of unnecessary malloc()/memcpy() calls by reusing memory I've already allocated. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- Windows 95: 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. -- Unknown - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
Michael Jennings wrote: On Tuesday, 13 March 2007, at 01:53:57 (+0100), Peter Wehrfritz wrote: Thanks committed. It is indeed much faster. I changed it slightly, because your version had some problems with empty strings. I intentionally left out the sanity checks at the beginning so I could test it without having too much macro overhead in the way. :) And I never really thought about how an empty delim string should be handled; your choice seems logical. On Tuesday, 13 March 2007, at 09:26:08 (+0100), St?phane Bauland wrote: 1) Why ecore_str_vector_free was removed ? It's unnecessary. 2) Do you think 2/3 optionals string's functions could be good to have in ecore ? - ecore_str_strdup_printf(format, ...) - ecore_str_memcpy(void *, size) No. Completely unnecessary. Hehe ! I got a memory leak here : ligne 165 (ecore_str.c) :s = strdup(str); looks like it isn't freed. Did you not read the code? or at least my mailing list message? And as a bonus, you only have to free the array pointer and its first element. Thank you for dining at the Clueburger; please drive through. Ok ok i solve memory leak... I don't know if it's a correct way to remove it but apparently it's ok. No, this is completely wrong and demonstrates no understanding whatsoever of the underlying code. Ridiculous. On Tuesday, 13 March 2007, at 10:59:21 (+0100), Sebastian Dransfeld wrote: Wrong fix! The user must free ret[0] ret. No other possibility. The question is whether this function should do a destructive split or not. I take it you missed the s = strdup(str) at the beginning Did ANYBODY actually bother to see how the code works besides Peter? On Tuesday, 13 March 2007, at 11:38:27 (+0100), Vincent Torri wrote: yes, you're right. I based my comment on what mej said. You misunderstood what mej said. See above. Why not only returning str, instread of str_array, which is allocated for nothing, imho ? YHO is wrong. :) str_array holds the pointers to the tokens just like before. The difference is that I save a crapload of unnecessary malloc()/memcpy() calls by reusing memory I've already allocated. Michael Hi Michael, i didnt read the doxy changements. But no it's ok. It's faster and it allocates less memory as before! good job! thanks too :) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Client list to show all clients across all screens....
Ravenlock wrote: Hello, Attached is a patch to allow users with multiple screens to optionally view the full list of clients across those screens. In cvs :) Cheers, dh - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Patch for disabling confirmation dialogs
Brian 'morlenxus' Miculcy wrote: Hi guys, the attached patch allows to disable confirmation dialogs. For example you want to shutdown or hibernate your computer, you first need to accept the warning. This patch adds an option to the config panel advanced-dialogs which allows to disable that. People where asking for it, since my kill dialog patch went in. Greets, Brian 'morlenxus' Miculcy Brian, There is a problem with this patch. You never set the e_config file generation for when a new config variable gets added, nor the IFCFG block: Example: e_config.h: #define E_CONFIG_FILE_GENERATION 0x0111 e_config.c: IFCFG(0x0111); e_config-clientlist_include_all_zones = 0; IFCFGEND; dh - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e16: composite menu doesnt come up anymore in cvs
Mike Frysinger wrote: after reporting that Esetroot bug w/composite, i updated to current cvs ... now i cant get back into the composite menu to enable it ;( desktop - Settings menu - select Composite item - nothing it used to pop up the composite settings dialog ... Did you build with all the required -devel stuff (render, composite, damage, fixes) installed? /Kim - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e16: composite menu doesnt come up anymore in cvs
On Tuesday 13 March 2007, Kim Woelders wrote: Mike Frysinger wrote: after reporting that Esetroot bug w/composite, i updated to current cvs ... now i cant get back into the composite menu to enable it ;( desktop - Settings menu - select Composite item - nothing it used to pop up the composite settings dialog ... Did you build with all the required -devel stuff (render, composite, damage, fixes) installed? this is Gentoo, so everything is -devel ... but to answer your question, yes taking your hint i looked through the build and composite support was being forced disabled via --disable-composite ;x ... perhaps the menu entry shouldnt even be shown in this case ? or it should pop up a msgbox saying enlightenment was built with composite support disabled ? -mike pgp0uOjypzy0a.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
Michael Jennings wrote: On Tuesday, 13 March 2007, at 10:59:21 (+0100), Sebastian Dransfeld wrote: Wrong fix! The user must free ret[0] ret. No other possibility. The question is whether this function should do a destructive split or not. I take it you missed the s = strdup(str) at the beginning Did ANYBODY actually bother to see how the code works besides Peter? Of course I read it. My point is that you could drop the strdup and do a destructive split. Sebastian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
On Tuesday, 13 March 2007, at 20:31:46 (+0100), Sebastian Dransfeld wrote: Of course I read it. My point is that you could drop the strdup and do a destructive split. No. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- It is strange to be known so universally and yet be so lonely. -- Albert Einstein - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
On Tuesday, 13 March 2007, at 20:46:20 (+0100), Sebastian Dransfeld wrote: Why do I bother arguing? About making a clean function destructive? Heck if I know... If you wanted to remove the strdup(), the caller would have to accept the destructive nature of the function or remember to pass strdup(str) as the first parameter instead of just str. This would be okay (i.e., no memory leak) since the pointer is reused. But it still makes ugly and non-intuitive code. Better to leave it as is. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- He who hesitates, dies. -- Greg Lippman - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e16: composite menu doesnt come up anymore in cvs
On Tuesday 13 March 2007, Mike Frysinger wrote: taking your hint i looked through the build and composite support was being forced disabled via --disable-composite ;x works great now ;) i really dig the fading and menus ... also, that Esetroot thing is working again, thanks -mike pgpHnHJH1VAoG.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e16: composite menu doesnt come up anymore in cvs
Mike Frysinger wrote: On Tuesday 13 March 2007, Kim Woelders wrote: Mike Frysinger wrote: after reporting that Esetroot bug w/composite, i updated to current cvs ... now i cant get back into the composite menu to enable it ;( desktop - Settings menu - select Composite item - nothing it used to pop up the composite settings dialog ... Did you build with all the required -devel stuff (render, composite, damage, fixes) installed? this is Gentoo, so everything is -devel ... but to answer your question, yes taking your hint i looked through the build and composite support was being forced disabled via --disable-composite ;x ... perhaps the menu entry shouldnt even be shown in this case ? or it should pop up a msgbox saying enlightenment was built with composite support disabled ? Ok, added message box. /Kim - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
Michael Jennings wrote: On Tuesday, 13 March 2007, at 20:46:20 (+0100), Sebastian Dransfeld wrote: Why do I bother arguing? About making a clean function destructive? Heck if I know... If you wanted to remove the strdup(), the caller would have to accept the destructive nature of the function or remember to pass strdup(str) as the first parameter instead of just str. This would be okay (i.e., no memory leak) since the pointer is reused. But it still makes ugly and non-intuitive code. Better to leave it as is. Michael I agree. Only stated that it was an option, not whether it was sane :) Sebastian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore englebass
For all who writes X wrappers. If a user decides to not link against a
library, the functions will not resolve at link time. So we need to wrap
them in cpp #ifdef's.
It's useless : all the functions here do not belong to the X screensaver
extension, but to the core protocol. You can even remove the test on the
Screensaver extension in configure.in.
Vincent
===
RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore_x/ecore_x_screensaver.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -3 -r1.6 -r1.7
--- ecore_x_screensaver.c 13 Feb 2007 16:24:37 - 1.6
+++ ecore_x_screensaver.c 14 Mar 2007 01:40:16 - 1.7
@@ -14,90 +14,117 @@
{
#ifdef ECORE_XSS
return 1;
-#endif
+#else
return 0;
+#endif
}
EAPI void
ecore_x_screensaver_set(int timeout, int interval, int blank, int expose)
{
+#ifdef ECORE_XSS
XSetScreenSaver(_ecore_x_disp, timeout, interval, blank, expose);
+#endif
}
EAPI void
ecore_x_screensaver_timeout_set(double timeout)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
XSetScreenSaver(_ecore_x_disp, (int)timeout,
pint, pblank, pexpo);
+#endif
}
EAPI double
ecore_x_screensaver_timeout_get(void)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
return (double)pto;
+#else
+ return 0;
+#endif
}
EAPI void
ecore_x_screensaver_blank_set(double blank)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
XSetScreenSaver(_ecore_x_disp, pto,
pint, (int)blank, pexpo);
+#endif
}
EAPI double
ecore_x_screensaver_blank_get(void)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
return (double)pblank;
+#else
+ return 0;
+#endif
}
EAPI void
ecore_x_screensaver_expose_set(double expose)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
XSetScreenSaver(_ecore_x_disp, pto,
pint, pblank, (int)expose);
+#endif
}
EAPI double
ecore_x_screensaver_expose_get(void)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
return (double)pexpo;
+#else
+ return 0;
+#endif
}
EAPI void
ecore_x_screensaver_interval_set(double interval)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
XSetScreenSaver(_ecore_x_disp, pto,
(int)interval, pblank, pexpo);
+#endif
}
EAPI double
ecore_x_screensaver_interval_get(void)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
return (double)pint;
+#else
+ return 0;
+#endif
}
EAPI void
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
enlightenment-cvs mailing list
enlightenment-cvs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
--
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.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore englebass
On Tue, 13 Mar 2007, Vincent Torri wrote:
For all who writes X wrappers. If a user decides to not link against a
library, the functions will not resolve at link time. So we need to wrap
them in cpp #ifdef's.
It's useless : all the functions here do not belong to the X screensaver
extension, but to the core protocol. You can even remove the test on the
Screensaver extension in configure.in.
Correction : XScreenSaverSelectInput only belongs to the X Screensaver
extension. XSetScreenSaver and XGetScreenSaver belong to the X core
protocol. The ifdef are only needed for the last function
Also, a function must be added to know if the Screensaver extension is
available in the X server (XScreenSaverQueryVersion).
Vincent
===
RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore_x/ecore_x_screensaver.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -3 -r1.6 -r1.7
--- ecore_x_screensaver.c 13 Feb 2007 16:24:37 - 1.6
+++ ecore_x_screensaver.c 14 Mar 2007 01:40:16 - 1.7
@@ -14,90 +14,117 @@
{
#ifdef ECORE_XSS
return 1;
-#endif
+#else
return 0;
+#endif
}
EAPI void
ecore_x_screensaver_set(int timeout, int interval, int blank, int expose)
{
+#ifdef ECORE_XSS
XSetScreenSaver(_ecore_x_disp, timeout, interval, blank, expose);
+#endif
}
EAPI void
ecore_x_screensaver_timeout_set(double timeout)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
XSetScreenSaver(_ecore_x_disp, (int)timeout,
pint, pblank, pexpo);
+#endif
}
EAPI double
ecore_x_screensaver_timeout_get(void)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
return (double)pto;
+#else
+ return 0;
+#endif
}
EAPI void
ecore_x_screensaver_blank_set(double blank)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
XSetScreenSaver(_ecore_x_disp, pto,
pint, (int)blank, pexpo);
+#endif
}
EAPI double
ecore_x_screensaver_blank_get(void)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
return (double)pblank;
+#else
+ return 0;
+#endif
}
EAPI void
ecore_x_screensaver_expose_set(double expose)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
XSetScreenSaver(_ecore_x_disp, pto,
pint, pblank, (int)expose);
+#endif
}
EAPI double
ecore_x_screensaver_expose_get(void)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
return (double)pexpo;
+#else
+ return 0;
+#endif
}
EAPI void
ecore_x_screensaver_interval_set(double interval)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
XSetScreenSaver(_ecore_x_disp, pto,
(int)interval, pblank, pexpo);
+#endif
}
EAPI double
ecore_x_screensaver_interval_get(void)
{
+#ifdef ECORE_XSS
int pto, pint, pblank, pexpo;
XGetScreenSaver(_ecore_x_disp, pto, pint, pblank, pexpo);
return (double)pint;
+#else
+ return 0;
+#endif
}
EAPI void
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
enlightenment-cvs mailing list
enlightenment-cvs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
--
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.
--
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.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
