===
RCS file:
/cvsroot/enlightenment/e17/libs/ecore/src/lib/ecore_evas/ecore_evas_x.c,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -3 -r1.59 -r1.60
--- ecore_evas_x.c4 Oct 2005 18:19:16 - 1.59
forget that mail, i've not seen raster's changes when i wrote it
Vincent
On Sun, 16 Oct 2005, Vincent Torri wrote:
===
RCS file:
/cvsroot/enlightenment/e17/libs/ecore/src/lib/ecore_evas/ecore_evas_x.c,v
retrieving
On Wed, 7 Sep 2005 00:19:14 -0400 Jose O Gonzalez [EMAIL PROTECTED] babbled:
Everyone should obtain at least one such rock :)
In fact, this should be something available in that
e-catalogue of goodies - coffee mugs, t-shirts, mouse pads,
etc.. *and* a handy e-rock to crawl under
enlightenment-cvs@lists.sourceforge.net wrote:
Enlightenment CVS committal
Author : sebastid
Project : e17
Module : libs/ecore
Dir : e17/libs/ecore/src/lib/ecore
Modified Files:
Ecore.h ecore_private.h
Log Message:
Export TRUE/FALSE
On Tue, 06 Sep 2005 21:44:40 +0200 Kim Woelders [EMAIL PROTECTED] wrote:
diff -u -3 -r1.24 -r1.25
--- Ecore.h 5 Sep 2005 10:17:08 - 1.24
+++ Ecore.h 6 Sep 2005 19:26:19 - 1.25
@@ -43,6 +43,14 @@
#include sys/types.h
#include signal.h
+#ifndef TRUE
Nathan Ingersoll wrote:
If it's something people are concerned about, we can namespace them.
That being said, these have been exported in some form for about 5 years
without a single complaint.
On 9/6/05, *Tilman Sauerbeck* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Tue, 06
Tilman Sauerbeck wrote:
On Tue, 06 Sep 2005 21:44:40 +0200 Kim Woelders [EMAIL PROTECTED] wrote:
diff -u -3 -r1.24 -r1.25
--- Ecore.h 5 Sep 2005 10:17:08 - 1.24
+++ Ecore.h 6 Sep 2005 19:26:19 - 1.25
@@ -43,6 +43,14 @@
#include sys/types.h
#include signal.h
Kim Woelders wrote:
Tilman Sauerbeck wrote:
On Tue, 06 Sep 2005 21:44:40 +0200 Kim Woelders [EMAIL PROTECTED] wrote:
diff -u -3 -r1.24 -r1.25
--- Ecore.h5 Sep 2005 10:17:08 -1.24
+++ Ecore.h6 Sep 2005 19:26:19 -1.25
@@ -43,6 +43,14 @@
#include sys/types.h
#include
On gcc 4 bool seems compatible with int, so return an int other then 0
or 1 will convert the return value to 1. So if we just change the return
value from int to bool, people used to 0/1, TRUE/FALSE can still use it.
Does this also mean we would have a minimum of gcc4 as a compiler? Is that
dan sinclair wrote:
On gcc 4 bool seems compatible with int, so return an int other then 0
or 1 will convert the return value to 1. So if we just change the return
value from int to bool, people used to 0/1, TRUE/FALSE can still use it.
Does this also mean we would have a minimum of gcc4 as
Sebastian Dransfeld wrote:
dan sinclair wrote:
On gcc 4 bool seems compatible with int, so return an int other then 0
or 1 will convert the return value to 1. So if we just change the return
value from int to bool, people used to 0/1, TRUE/FALSE can still use
it.
Does this also mean we
On Tue, 06 Sep 2005 23:31:10 +0200 Kim Woelders [EMAIL PROTECTED] babbled:
No. TRUE should definitely not be defined as !FALSE.
Booleans in C are a pain. Personally, I avoid using them entirely, as I
think they are more trouble than helpful, when they are not intrinsic
to the language.
On Wed, 7 Sep 2005 11:43:59 +0900 Carsten Haitzler (The Rasterman)
[EMAIL PROTECTED] writes:
On Tue, 06 Sep 2005 23:31:10 +0200 Kim Woelders [EMAIL PROTECTED]
babbled:
No. TRUE should definitely not be defined as !FALSE.
Booleans in C are a pain. Personally, I avoid using them
What should we use for stepping?
On 6/12/05, enlightenment-cvs@lists.sourceforge.net
enlightenment-cvs@lists.sourceforge.net wrote:
Enlightenment CVS committal
Author : sebastid
Project : e17
Module : libs/ecore
Dir : e17/libs/ecore/src/lib/ecore_x
Modified Files:
Hisham Mardam Bey wrote:
What should we use for stepping?
ecore_x_icccm_size_pos_hints_set()
On 6/12/05, enlightenment-cvs@lists.sourceforge.net
enlightenment-cvs@lists.sourceforge.net wrote:
Enlightenment CVS committal
Author : sebastid
Project : e17
Module : libs/ecore
Dir :
Seb,
shouldn't you check the win id in this function ? :
+void
+ecore_x_netwm_sync_request_send(Ecore_X_Window win, unsigned int serial)
+{
+ XSyncValue value;
+ XEvent xev;
+
+ XSyncIntToValue(value, serial);
+
+ xev.xclient.type = ClientMessage;
+ xev.xclient.display =
Vincent Torri wrote:
Seb,
shouldn't you check the win id in this function ? :
Why? The function is used by a wm, and the wm should keep track of its
windows.
Sebastian
+void
+ecore_x_netwm_sync_request_send(Ecore_X_Window win, unsigned int serial)
+{
+ XSyncValue value;
+ XEvent
17 matches
Mail list logo
