[E-devel] Exchange content
Hi all, Exchange content is now basically outdated due to the edje changes. Also, gradient has been knocked out, so that changes a lot of things. Im going to run edje_convert on all the site contents, to bring all that up to the recent API. Im guessing this will cause a wave of problems with people using packages and old versions (which we dont support). My question: Is it a good time to do this? If it is, ill put out an announce on the mailing list and a disclaimer on the landing page (if I can figure that out) Also, due to gradient being removed, Im planning on disapproving all content that has a gradient in it. Maybe not now, but eventually once the gradients have been completely removed. So if you have content on there, please update it if it has a gradient. Toma -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Exchange content
On Mon, Aug 23, 2010 at 9:25 AM, Tom Haste tomha...@gmail.com wrote: Exchange content is now basically outdated due to the edje changes. Also, gradient has been knocked out, so that changes a lot of things. Im going to run edje_convert on all the site contents, to bring all that up to the recent API. Im guessing this will cause a wave of problems with people using packages and old versions (which we dont support). My question: Is it a good time to do this? If it is, ill put out an announce on the mailing list and a disclaimer on the landing page (if I can figure that out) edje_convert preserve the edje data needed for old edje loader. So when you call edje_convert on an old edj file, it basically make it loadable with both old and new loader code. It should not impact old user at all (it doesn't remove gradient part in old format). Thing should be just fine for your use case as this is the intended usage. Also, due to gradient being removed, Im planning on disapproving all content that has a gradient in it. Maybe not now, but eventually once the gradients have been completely removed. So if you have content on there, please update it if it has a gradient. gradient has been completely removed from edje and evas code. Did I miss some ? Where ? Where ? Will kill that one too ! :-) -- Cedric BAIL -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Exchange content
On 23 August 2010 15:39, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Aug 23, 2010 at 9:25 AM, Tom Haste tomha...@gmail.com wrote: Exchange content is now basically outdated due to the edje changes. Also, gradient has been knocked out, so that changes a lot of things. Im going to run edje_convert on all the site contents, to bring all that up to the recent API. Im guessing this will cause a wave of problems with people using packages and old versions (which we dont support). My question: Is it a good time to do this? If it is, ill put out an announce on the mailing list and a disclaimer on the landing page (if I can figure that out) edje_convert preserve the edje data needed for old edje loader. So when you call edje_convert on an old edj file, it basically make it loadable with both old and new loader code. It should not impact old user at all (it doesn't remove gradient part in old format). Thing should be just fine for your use case as this is the intended usage. Perfect. Ill get cracking on it then. Also, due to gradient being removed, Im planning on disapproving all content that has a gradient in it. Maybe not now, but eventually once the gradients have been completely removed. So if you have content on there, please update it if it has a gradient. gradient has been completely removed from edje and evas code. Did I miss some ? Where ? Where ? Will kill that one too ! :-) I would imagine the build/rebuild would fail with an 'unrecognised' part type... (eg. type: GRADIENT;) Its AWESOME that it doesnt, but I thought that would be the final nail in the coffin. -- Cedric BAIL -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Sun, Aug 22, 2010 at 06:08:38AM +0200, Vincent Torri wrote: -#if defined (__MacOSX__) || defined (__FreeBSD__) || (defined (__MACH__) \ - defined (__APPLE__)) -# include sys/syslimits.h -#endif +#include limits.h Did Joerg try that on all the platforms that were in the #define ? If no, revert this. I did ask people where the nedded constant were located, and it was not in limits.h The original version before my change clearly doesn't work on POSIX compliant systems. For FreeBSD, sys/limits.h has been included by limits.h for at least 7 years and they did some header reorg at the time. I can't say for Darwin, but I would strongly surprised as I have enough code using PATH_MAX and co without ever including sys/limits.h. So can you demonstrate any breakage or is this just a theoretical remark? Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Powered by EFL Logo ?
Hello everyone Here's an attempt at a powered by EFL logo and a signature for small use. Both the images and svg sources for them are attached. Please fell free to replay with suggestions. PS. Antognolli and Luis Felipe inspired me with their logo =P -- Marina pulsoideias.com.br attachment: efl_logo.svgattachment: efl_signature.svg-- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Powered by EFL Logo ?
I like it! On Mon, Aug 23, 2010 at 9:03 AM, Marina Proni marina.des...@gmail.comwrote: Hello everyone Here's an attempt at a powered by EFL logo and a signature for small use. Both the images and svg sources for them are attached. Please fell free to replay with suggestions. PS. Antognolli and Luis Felipe inspired me with their logo =P -- Marina pulsoideias.com.br -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Powered by EFL Logo ?
Stephen Houston, il 23/08/2010 17:35, scrisse: I like it! me too :) -- Massimo Maiurana massimoatragusa.linux.it http://massimo.solira.orgGPG keyID #7044D601 Creare l'uomo fu un'idea bizzarra e originale, ma aggiungere la pecora fu una tautologia. [Mark Twain] signature.asc Description: OpenPGP digital signature -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Powered by EFL Logo ?
On Mon, Aug 23, 2010 at 5:55 PM, Massimo Maiurana maiur...@gmail.com wrote: Stephen Houston, il 23/08/2010 17:35, scrisse: I like it! me too :) Definitly so much better ! I vote for it too ! -- Cedric BAIL -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mej IN trunk/eterm: Eterm/src Eterm/utils libast/src libast/test spite
On Mon, Aug 23, 2010 at 3:28 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: On Mon, Aug 23, 2010 at 2:55 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Revert coccinelle changes. Using !! instead of != NULL results in significantly and unacceptably less readable code, and I refuse to accept those changes. Unfortunately, since they were all done at once, I have to revert the whole thing. Oh well. :( Did you revert the whole thing? Why do you have to do so? At least for EFL, it should be like this as agreed on mailing list / irc Ahn... you are talking about the other changes. I can disable those and apply for you if you want. But it's well automated/understandable by SCRIPTS/coccinelle/spatchall.sh, if you want to apply by yourself. Lucas De Marchi -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mej IN trunk/eterm: Eterm/src Eterm/utils libast/src libast/test spite
On Mon, 23 Aug 2010 15:28 -0300, Lucas De Marchi wrote : On Mon, Aug 23, 2010 at 2:55 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Revert coccinelle changes. Using !! instead of != NULL results in significantly and unacceptably less readable code, and I refuse to accept those changes. Unfortunately, since they were all done at once, I have to revert the whole thing. Oh well. :( Did you revert the whole thing? Why do you have to do so? At least for EFL, it should be like this as agreed on mailing list / irc The particular change Michael is unhappy with is != NULL = !!, and he did express his disagreement about it (and so did I, FWIW). That being said, I'm not going to fight over it if the general opinion is that it's fine. Cheers, -- Albin Tonnerre -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Evas directfb include.
Hi folks, this is a tiny patch that fixes evas include of header directfb.h. The current include makes it hard for people with multiple versions of DirectFB installed to compile the code. This is the correct way to include that header, and it's the way ecore_directfb does it. Cheers, Eduardo. diff --git a/evas/src/modules/engines/directfb/Evas_Engine_DirectFB.h b/evas/src/modules/engines/directfb/Evas_Engine_DirectFB.h index a2e9d3a..53352b7 100644 --- evas/src/modules/engines/directfb/Evas_Engine_DirectFB.h +++ evas/src/modules/engines/directfb/Evas_Engine_DirectFB.h @@ -2,7 +2,7 @@ #define _EVAS_ENGINE_DIRECTFB_H #include Evas.h -#include directfb/directfb.h +#include directfb.h typedef struct _Evas_Engine_Info_DirectFB Evas_Engine_Info_DirectFB; -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Powered by EFL Logo ?
On Mon, 23 Aug 2010 18:04:02 +0200 Cedric BAIL cedric.b...@free.fr said: On Mon, Aug 23, 2010 at 5:55 PM, Massimo Maiurana maiur...@gmail.com wrote: Stephen Houston, il 23/08/2010 17:35, scrisse: I like it! me too :) Definitly so much better ! I vote for it too ! what? don't we need some more primary colors and crudely mouse-squiggled bits? :) only comment here - looks nice. actually very much unique in the powered by world that normally is just some boring badge with the standard project/product/company logo on it. the e has a solid middle bit. f and l are nice line-art (so to speak). almost a bit inconsistent. not sure what to do there. making the F or L have thick bits or remove the tick middle of the e (less desirable as it then is no longer like the e logo). one thing? what grid and units do you use? seems the thickness of the lines is not a nice whole unit :) it's just visually roughly done. normally with things like logos and stuff i tend to get things going to a nice regular grid to ensure lines and bits are all the right consistent dimensions - so i'm trying to match up with yours but can't seem to find the right setup. also the efl bit in the circle logo is cut out but the powered by is layers white on top. (can't you tell i'm a programmery-type and i code review even your illustrations noting that tho it looks good.. things dont quite line up etc. right) :) not sure if you intended it to be all cut out or a circle clipping a white efl and powered by .. or you actually intended the mix and match look. :) important though if the thing is to become a logo and possible used over various backgrounds. i'd make it a chicle clipping white efl + powered by for that. attached is a cleanup of the round one as described. so thumbs up to your design idea. just needed cleaning :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com attachment: pby-a2.svg-- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/ecore/src/lib/ecore
On Mon, 23 Aug 2010 06:05:57 -0700 Enlightenment SVN
no-re...@enlightenment.org said:
Log:
* ecore: struct a b = { 0 }; doesn't mean memset.
Author: cedric
Date: 2010-08-23 06:05:57 -0700 (Mon, 23 Aug 2010)
New Revision: 51571
Modified:
trunk/ecore/src/lib/ecore/ecore_main.c
actually interestingly enough... struct a b = { 0 } does mean memset it all to
0. :)
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Powered by EFL Logo ?
On Mon, 23 Aug 2010 11:03:02 -0300 Marina Proni marina.des...@gmail.com wrote: Here's an attempt at a powered by EFL logo and a signature for small use. My first impression is that it's not efl, but eh. Powered by Canadians? The signature one looks more like fl following a circular graphic, so you can't win. They do look good though. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mej IN trunk/eterm: Eterm/src Eterm/utils libast/src libast/test spite
On Tuesday, 24 August 2010, at 13:32:06 (+1000), David Seikel wrote: I'm going to agree that !! is unreadable. Um, does that mean negate the negation, hence do nothing, or is their an obscure !! operator I have somehow missed in my decades of C programming? Don't think I have ever seen it before, so would not count is as well known C practice. No doubt for the same reason that double negatives are discouraged in English. Not being equal to NULL says something, negating the negation is just noise. Double negation insures that whatever the compiler's default boolean value is (sometimes 1, sometimes -1, but theoretically could be whatever non-zero value it wants, so long as it's consistent) gets assigned/tested. The double negation insures that any true value gets negated to false then negated again to the compiler's inate true value. Unfortunately raster thinks anyone who prefers the original notation over !! simply doesn't know the above and thus needs to learn something. So we're all just morons who don't know anything, and raster is always right. Again. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- Come stand a little bit closer. Breathe in and get a bit higher. You'll never know what hit you when I get to you. -- Savage Garden, I Want You -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mej IN trunk/eterm: Eterm/src Eterm/utils libast/src libast/test spite
On Mon, 23 Aug 2010 20:59:54 -0700 Michael Jennings m...@kainx.org wrote: On Tuesday, 24 August 2010, at 13:32:06 (+1000), David Seikel wrote: I'm going to agree that !! is unreadable. Um, does that mean negate the negation, hence do nothing, or is their an obscure !! operator I have somehow missed in my decades of C programming? Don't think I have ever seen it before, so would not count is as well known C practice. No doubt for the same reason that double negatives are discouraged in English. Not being equal to NULL says something, negating the negation is just noise. Double negation insures that whatever the compiler's default boolean value is (sometimes 1, sometimes -1, but theoretically could be whatever non-zero value it wants, so long as it's consistent) gets assigned/tested. The double negation insures that any true value gets negated to false then negated again to the compiler's inate true value. Um, so it's just a cast to boolean really? Though still it's not the same thing as checking for equality with NULL. In the case of pointers, it's the equivalence or lack of equivalence with NULL that is the important thing. NULL pointers meaning this pointer does not currently point to anything. We don't really care if the pointer, when cast to a proper boolean value, is true or false, that is completely unrelated to it's identity as a pointer. It may actually work, but it's not what we are interested in. We want to know if the pointer points to something. In C, that means if it is NULL. I understand that on some obscure platforms that we likely don't care about, NULL is not zero, so !! might not actually be portable for pointer NULL testing. Yes, I'm fully aware that far to often I just do if (pointer) or if (!pointer). I don't see if (!!pointer) as being any more readable or correct than if (pointer), while grudgingly admitting that if (NULL != pointer) is likely more correct. It says what is meant, and the boolean operator produces a boolean result to be used by the boolean statement, no odd casting mishaps possible on obscure platforms. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mej IN trunk/eterm: Eterm/src Eterm/utils libast/src libast/test spite
On Tuesday, 24 August 2010, at 14:38:17 (+1000), David Seikel wrote: Um, so it's just a cast to boolean really? Though still it's not the same thing as checking for equality with NULL. In the case of pointers, it's the equivalence or lack of equivalence with NULL that is the important thing. NULL pointers meaning this pointer does not currently point to anything. We don't really care if the pointer, when cast to a proper boolean value, is true or false, that is completely unrelated to it's identity as a pointer. It may actually work, but it's not what we are interested in. We want to know if the pointer points to something. In C, that means if it is NULL. This is specifically for cases where a boolean value (i.e., Eina_Bool, which is by definition either 0 or !0) is either being assigned to a variable or passed to a function. if (ptr) is still used, but boolvar = (a != NULL) becomes boolvar = !!a. I understand that on some obscure platforms that we likely don't care about, NULL is not zero, so !! might not actually be portable for pointer NULL testing. It's not the NULL value that matters here, but rather the true value. !0 may or may not be 1 (~0 is also used). Yes, I'm fully aware that far to often I just do if (pointer) or if (!pointer). I don't see if (!!pointer) as being any more readable or correct than if (pointer), while grudgingly admitting that if (NULL != pointer) is likely more correct. It says what is meant, and the boolean operator produces a boolean result to be used by the boolean statement, no odd casting mishaps possible on obscure platforms. I find if (ptr) and if (!ptr) perfectly readable because my brain recognizes if pointer and if not pointer semantics. BTW, after further discussions with raster, it turns out we actually agree for the most part on the usage of !!. It just happens that the coccinelle script misinterpreted some of my stuff and was too overzealous. I don't mind b = !!a but I do mind ASSERT(!!a) which coccinelle mistakes for a function. I think this was all one big misunderstanding. :( Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- Feel your breath on my shoulder, and I know we couldn't get any closer. I don't want to act tough; I just want to fall in love as we move into the night.-- Peter Cetera and Crystal Bernard, (I Wanna Take) Forever Tonight -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/ecore/src/lib/ecore
On Tue, 24 Aug 2010, Carsten Haitzler (The Rasterman) wrote:
On Mon, 23 Aug 2010 06:05:57 -0700 Enlightenment SVN
no-re...@enlightenment.org said:
Log:
* ecore: struct a b = { 0 }; doesn't mean memset.
Author: cedric
Date: 2010-08-23 06:05:57 -0700 (Mon, 23 Aug 2010)
New Revision: 51571
Modified:
trunk/ecore/src/lib/ecore/ecore_main.c
actually interestingly enough... struct a b = { 0 } does mean memset it all
to
0. :)
I'm not sure vc++ likes it, though. I prefer memset :)
Vincent
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: titan trunk/PROTO/emote/src/lib/protocols/irc
On Mon, 23 Aug 2010, Enlightenment SVN wrote:
Log:
Wrong use of EMAPI... dang search and replace.
the make them static ?
Vincent
Author: titan
Date: 2010-08-23 19:47:21 -0700 (Mon, 23 Aug 2010)
New Revision: 51594
Modified:
trunk/PROTO/emote/src/lib/protocols/irc/irc.c
trunk/PROTO/emote/src/lib/protocols/irc/irc.h
Modified: trunk/PROTO/emote/src/lib/protocols/irc/irc.c
===
--- trunk/PROTO/emote/src/lib/protocols/irc/irc.c 2010-08-24 02:27:44 UTC
(rev 51593)
+++ trunk/PROTO/emote/src/lib/protocols/irc/irc.c 2010-08-24 02:47:21 UTC
(rev 51594)
@@ -78,7 +78,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_pass(const char *server, const char *pass)
{
Ecore_Con_Server *serv = NULL;
@@ -93,7 +93,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_nick(const char *server, const char *nick)
{
Ecore_Con_Server *serv = NULL;
@@ -108,7 +108,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_user(const char *server, const char *nick)
{
Ecore_Con_Server *serv = NULL;
@@ -125,7 +125,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_join(const char *server, const char *chan)
{
Ecore_Con_Server *serv = NULL;
@@ -140,7 +140,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_message(const char *server, const char *chan, const char
*message)
{
Ecore_Con_Server *serv = NULL;
@@ -155,7 +155,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_identify(const char *server, const char *pass)
{
Ecore_Con_Server *serv = NULL;
@@ -170,7 +170,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_ghost(const char *server, const char *nick, const char *pass)
{
Ecore_Con_Server *serv = NULL;
@@ -185,7 +185,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_part(const char *server, const char *channel, const char *reason)
{
Ecore_Con_Server *serv = NULL;
@@ -203,7 +203,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_back(const char *server)
{
Ecore_Con_Server *serv = NULL;
@@ -218,7 +218,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_away(const char *server, const char *reason)
{
Ecore_Con_Server *serv = NULL;
@@ -239,7 +239,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_away_status(const char *server, const char *channel)
{
Ecore_Con_Server *serv = NULL;
@@ -254,7 +254,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_kick(const char *server, const char *channel, const char *nick,
const char *reason)
{
Ecore_Con_Server *serv = NULL;
@@ -273,7 +273,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_invite(const char *server, const char *channel, const char *nick)
{
Ecore_Con_Server *serv = NULL;
@@ -288,7 +288,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_mode(const char *server, const char *channel, const char *mode)
{
Ecore_Con_Server *serv = NULL;
@@ -303,7 +303,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_user_list(const char *server, const char *channel)
{
Ecore_Con_Server *serv = NULL;
@@ -318,7 +318,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_user_host(const char *server, const char *nick)
{
Ecore_Con_Server *serv = NULL;
@@ -333,7 +333,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_user_whois(const char *server, const char *nick)
{
Ecore_Con_Server *serv = NULL;
@@ -348,7 +348,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_action(const char *server, const char *channel, const char
*action)
{
Ecore_Con_Server *serv = NULL;
@@ -364,7 +364,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_notice(const char *server, const char *channel, const char
*notice)
{
Ecore_Con_Server *serv = NULL;
@@ -379,7 +379,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_topic(const char *server, const char *channel, const char *topic)
{
Ecore_Con_Server *serv = NULL;
@@ -399,7 +399,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_channels_list(const char *server, const char *arg)
{
Ecore_Con_Server *serv = NULL;
@@ -417,7 +417,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_names(const char *server, const char *channel)
{
Ecore_Con_Server *serv = NULL;
@@ -432,7 +432,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_ping(const char *server, const char *to, const char *timestring)
{
Ecore_Con_Server *serv = NULL;
@@ -451,7 +451,7 @@
return 1;
}
-EMAPI int
+int
protocol_irc_pong(const char *server, const char *msg)
{
Ecore_Con_Server *serv = NULL;
Modified: trunk/PROTO/emote/src/lib/protocols/irc/irc.h
===
--- trunk/PROTO/emote/src/lib/protocols/irc/irc.h 2010-08-24 02:27:44 UTC
(rev 51593)
+++ trunk/PROTO/emote/src/lib/protocols/irc/irc.h 2010-08-24 02:47:21 UTC
(rev 51594)
@@ -9,29 +9,29 @@
EMAPI int protocol__shutdown(void);
EMAPI int protocol__connect(const char
