Re: [E-devel] Ecore XCB
On Mon, Aug 1, 2011 at 23:02, Boris Faure bill...@gmail.com wrote: Patch is attached. Tell me if it works fine for you and I'll gladly commit it. I've done a few things other than just use the new API: - removed an unused var in ecore_x_icccm_size_pos_hints_get() and added __UNUSED__ on win, my bad. - changed LONG_MAX into UINT32_MAX in ecore_x_window_prop_property_get(). I think UINT32_MAX should be used instead of hard-coding 0x7fff or 100L when calling xcb_get_property_unchecked(). Why did you discard this patch? -- Boris Faure -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On Mon, Aug 1, 2011 at 01:16, Christopher Michael cpmicha...@comcast.net wrote: On 07/30/2011 06:36 PM, Boris Faure wrote: On Tue, Jul 12, 2011 at 01:10, Christopher Michael cpmicha...@comcast.net wrote: […] 2) It may not build on your system (tho it builds on all boxes I have tried so far). It doesn't build on my boxes (gentoo and arch linux up-to-date). I find that very strange since all of the initial development that I did was on a gentoo box. If I had to guess, I would say you are using ACCEPT_KEYWORDS=~x86 to pull in masked packages...In which case, you are pulling in a development version of XCB and yes it will not build against that. Sorry for keeping the troll fed, but xcb-1.7 is on stable gentoo x86 as you can see on http://packages.gentoo.org/package/x11-libs/libxcb . I'll rewrite the patch to make ecore_xcb work with both xcb 1.7 and xcb = 1.7 so that it's fine for everyone. -- Boris Faure -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On Mon, Aug 1, 2011 at 5:01 AM, Boris Faure bill...@gmail.com wrote: On Mon, Aug 1, 2011 at 01:16, Christopher Michael cpmicha...@comcast.net wrote: On 07/30/2011 06:36 PM, Boris Faure wrote: On Tue, Jul 12, 2011 at 01:10, Christopher Michael cpmicha...@comcast.net wrote: […] 2) It may not build on your system (tho it builds on all boxes I have tried so far). It doesn't build on my boxes (gentoo and arch linux up-to-date). I find that very strange since all of the initial development that I did was on a gentoo box. If I had to guess, I would say you are using ACCEPT_KEYWORDS=~x86 to pull in masked packages...In which case, you are pulling in a development version of XCB and yes it will not build against that. Sorry for keeping the troll fed, but xcb-1.7 is on stable gentoo x86 as you can see on http://packages.gentoo.org/package/x11-libs/libxcb . I'll rewrite the patch to make ecore_xcb work with both xcb 1.7 and xcb = 1.7 so that it's fine for everyone. Thanks Boris... this is very much appreciated. Lucas De Marchi -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On 08/01/2011 03:36 PM, Lucas De Marchi wrote: On Mon, Aug 1, 2011 at 5:01 AM, Boris Faurebill...@gmail.com wrote: On Mon, Aug 1, 2011 at 01:16, Christopher Michael cpmicha...@comcast.net wrote: On 07/30/2011 06:36 PM, Boris Faure wrote: On Tue, Jul 12, 2011 at 01:10, Christopher Michael cpmicha...@comcast.netwrote: […] 2) It may not build on your system (tho it builds on all boxes I have tried so far). It doesn't build on my boxes (gentoo and arch linux up-to-date). I find that very strange since all of the initial development that I did was on a gentoo box. If I had to guess, I would say you are using ACCEPT_KEYWORDS=~x86 to pull in masked packages...In which case, you are pulling in a development version of XCB and yes it will not build against that. Sorry for keeping the troll fed, but xcb-1.7 is on stable gentoo x86 as you can see on http://packages.gentoo.org/package/x11-libs/libxcb . I'll rewrite the patch to make ecore_xcb work with both xcb 1.7 and xcb= 1.7 so that it's fine for everyone. New patch sounds good :) as long as it will build for both .. until such time that distros across the spectrum are all updated to development xcb. When that happens then we can stop supporting current stable xcb (0.3.6) and remove the legacy code :) When you get your new patch(s) ready, send them out to the mailing list and I'll gladly have a look :) Thanks, dh Thanks Boris... this is very much appreciated. Lucas De Marchi -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On Mon, Aug 1, 2011 at 21:59, Christopher Michael
cpmicha...@comcast.net wrote:
On Mon, Aug 1, 2011 at 5:01 AM, Boris Faurebill...@gmail.com wrote:
I'll rewrite the patch to make ecore_xcb work with both xcb 1.7 and
xcb= 1.7 so that it's fine for everyone.
New patch sounds good :) as long as it will build for both .. until such
time that distros across the spectrum are all updated to development
xcb. When that happens then we can stop supporting current stable xcb
(0.3.6) and remove the legacy code :)
When you get your new patch(s) ready, send them out to the mailing list
and I'll gladly have a look :)
Patch is attached. Tell me if it works fine for you and I'll gladly commit it.
I've done a few things other than just use the new API:
- removed an unused var in ecore_x_icccm_size_pos_hints_get() and
added __UNUSED__ on win,
- changed LONG_MAX into UINT32_MAX in ecore_x_window_prop_property_get().
I think UINT32_MAX should be used instead of hard-coding 0x7fff or
100L when calling xcb_get_property_unchecked().
--
Boris Faure
diff --git a/ecore/configure.ac b/ecore/configure.ac
index fa7ab9d..6d3bb13 100644
--- a/ecore/configure.ac
+++ b/ecore/configure.ac
@@ -784,10 +784,22 @@ if test x$want_ecore_x_xcb = xyes ; then
fi
## x11-xcb
+ PKG_CHECK_MODULES(XCB,
+x11-xcb
+xcb
+xcb-shm
+xcb-icccm = 0.3.8
+xcb-util = 0.3.8
+xcb-image
+xcb-keysyms,
+ [ have_ecore_x_xcb=yes
+ requirements_ecore_x=x11-xcb xcb xcb-shm xcb-icccm xcb-image xcb-keysyms ${requirements_ecore_x} ],
+ [
PKG_CHECK_MODULES(XCB, x11-xcb xcb xcb-shm xcb-icccm xcb-image xcb-keysyms,
[ have_ecore_x_xcb=yes
+ AC_DEFINE(OLD_XCB_VERSION, 1, [xcb version])
requirements_ecore_x=x11-xcb xcb xcb-shm xcb-icccm xcb-image xcb-keysyms ${requirements_ecore_x} ],
-[ have_ecore_x_xcb=no ])
+[ have_ecore_x_xcb=no ])])
if test x$have_ecore_x_xcb = xyes ; then
diff --git a/ecore/src/lib/ecore_x/xcb/ecore_xcb_error.c b/ecore/src/lib/ecore_x/xcb/ecore_xcb_error.c
index c58c13c..5c8556f 100644
--- a/ecore/src/lib/ecore_x/xcb/ecore_xcb_error.c
+++ b/ecore/src/lib/ecore_x/xcb/ecore_xcb_error.c
@@ -67,10 +67,17 @@ _ecore_xcb_error_handle(xcb_generic_error_t *err)
WRN(Got Error:);
WRN(\tEvent: %s, xcb_event_get_request_label(err-major_code));
WRN(\tError: %s, xcb_event_get_error_label(err-error_code));
+#ifdef OLD_XCB_VERSION
if (err-error_code == XCB_EVENT_ERROR_BAD_VALUE)
WRN(\tBad Value: %d, ((xcb_value_error_t *)err)-bad_value);
- else if (err-error_code == XCB_EVENT_ERROR_BAD_WINDOW)
+ else if (err-error_code == XCB_EVENT_ERROR_BAD_WINDOW)
WRN(\tBad Window: %d, ((xcb_window_error_t *)err)-bad_value);
+#else
+ if (err-error_code == XCB_VALUE)
+ WRN(\tBad Value: %d, ((xcb_value_error_t *)err)-bad_value);
+ else if (err-error_code == XCB_WINDOW)
+ WRN(\tBad Window: %d, ((xcb_window_error_t *)err)-bad_value);
+#endif
_error_request_code = err-sequence;
_error_code = err-error_code;
diff --git a/ecore/src/lib/ecore_x/xcb/ecore_xcb_events.c b/ecore/src/lib/ecore_x/xcb/ecore_xcb_events.c
index eb2c959..f241e7f 100644
--- a/ecore/src/lib/ecore_x/xcb/ecore_xcb_events.c
+++ b/ecore/src/lib/ecore_x/xcb/ecore_xcb_events.c
@@ -240,6 +240,7 @@ _ecore_xcb_events_handle(xcb_generic_event_t *ev)
* so trap those cases and ignore. We also ignore BadValue from
* xcb_grab/ungrab_button (happens when we are using any_mod)
* and a few others */
+#ifdef OLD_XCB_VERSION
if (err-error_code == XCB_EVENT_ERROR_BAD_WINDOW) return;
else if (err-error_code == XCB_EVENT_ERROR_BAD_MATCH)
{
@@ -254,6 +255,22 @@ _ecore_xcb_events_handle(xcb_generic_event_t *ev)
(err-major_code == XCB_UNGRAB_BUTTON))
return;
}
+#else
+if (err-error_code == XCB_WINDOW) return;
+else if (err-error_code == XCB_MATCH)
+ {
+ if ((err-major_code == XCB_SET_INPUT_FOCUS) ||
+ (err-major_code == XCB_CONFIGURE_WINDOW))
+ return;
+ }
+else if (err-error_code == XCB_VALUE)
+ {
+ if ((err-major_code == XCB_KILL_CLIENT) ||
+ (err-major_code == XCB_GRAB_BUTTON) ||
+ (err-major_code == XCB_UNGRAB_BUTTON))
+ return;
+ }
+#endif
/* WRN(Got Event Error:); */
/* WRN(\tMajor Code: %d, err-major_code); */
@@ -1627,8 +1644,14 @@ _ecore_xcb_event_handle_client_message(xcb_generic_event_t *event)
e-source = ev-data.data32[3];
ecore_event_add(ECORE_X_EVENT_WINDOW_STATE_REQUEST, e, NULL, NULL);
}
+#ifdef OLD_XCB_VERSION
else if ((ev-type == ECORE_X_ATOM_WM_CHANGE_STATE)
(ev-format == 32) (ev-data.data32[0] == XCB_WM_STATE_ICONIC))
+#else
+ else if
Re: [E-devel] Ecore XCB
On 08/01/2011 05:02 PM, Boris Faure wrote: On Mon, Aug 1, 2011 at 21:59, Christopher Michael cpmicha...@comcast.net wrote: On Mon, Aug 1, 2011 at 5:01 AM, Boris Faurebill...@gmail.comwrote: I'll rewrite the patch to make ecore_xcb work with both xcb1.7 and xcb= 1.7 so that it's fine for everyone. New patch sounds good :) as long as it will build for both .. until such time that distros across the spectrum are all updated to development xcb. When that happens then we can stop supporting current stable xcb (0.3.6) and remove the legacy code :) When you get your new patch(s) ready, send them out to the mailing list and I'll gladly have a look :) Patch is attached. Tell me if it works fine for you and I'll gladly commit it. I've done a few things other than just use the new API: - removed an unused var in ecore_x_icccm_size_pos_hints_get() and added __UNUSED__ on win, - changed LONG_MAX into UINT32_MAX in ecore_x_window_prop_property_get(). I think UINT32_MAX should be used instead of hard-coding 0x7fff or 100L when calling xcb_get_property_unchecked(). Ok, that is not correct. 'Win' is used there: xcb_get_wm_normal_hints_unchecked(conn, win); I am seeing some other issues with this patch also, but it is a good start. I'll use this patch, fix some incorrect things and apply. Thanks, dh -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On 08/01/2011 07:23 PM, Christopher Michael wrote: On 08/01/2011 05:02 PM, Boris Faure wrote: On Mon, Aug 1, 2011 at 21:59, Christopher Michael cpmicha...@comcast.net wrote: On Mon, Aug 1, 2011 at 5:01 AM, Boris Faurebill...@gmail.com wrote: I'll rewrite the patch to make ecore_xcb work with both xcb 1.7 and xcb= 1.7 so that it's fine for everyone. New patch sounds good :) as long as it will build for both .. until such time that distros across the spectrum are all updated to development xcb. When that happens then we can stop supporting current stable xcb (0.3.6) and remove the legacy code :) When you get your new patch(s) ready, send them out to the mailing list and I'll gladly have a look :) Patch is attached. Tell me if it works fine for you and I'll gladly commit it. I've done a few things other than just use the new API: - removed an unused var in ecore_x_icccm_size_pos_hints_get() and added __UNUSED__ on win, - changed LONG_MAX into UINT32_MAX in ecore_x_window_prop_property_get(). I think UINT32_MAX should be used instead of hard-coding 0x7fff or 100L when calling xcb_get_property_unchecked(). Ok, that is not correct. 'Win' is used there: xcb_get_wm_normal_hints_unchecked(conn, win); I am seeing some other issues with this patch also, but it is a good start. I'll use this patch, fix some incorrect things and apply. Thanks, dh Yea, I cannot accept this patch as it sits currently. It will not even apply against current ecore from svn :( so I will have to manually cherry pick it. dh -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
In Svn, but had to modify it a bit. Thanks dh On 08/01/2011 05:02 PM, Boris Faure wrote: On Mon, Aug 1, 2011 at 21:59, Christopher Michael cpmicha...@comcast.net wrote: On Mon, Aug 1, 2011 at 5:01 AM, Boris Faurebill...@gmail.comwrote: I'll rewrite the patch to make ecore_xcb work with both xcb1.7 and xcb= 1.7 so that it's fine for everyone. New patch sounds good :) as long as it will build for both .. until such time that distros across the spectrum are all updated to development xcb. When that happens then we can stop supporting current stable xcb (0.3.6) and remove the legacy code :) When you get your new patch(s) ready, send them out to the mailing list and I'll gladly have a look :) Patch is attached. Tell me if it works fine for you and I'll gladly commit it. I've done a few things other than just use the new API: - removed an unused var in ecore_x_icccm_size_pos_hints_get() and added __UNUSED__ on win, - changed LONG_MAX into UINT32_MAX in ecore_x_window_prop_property_get(). I think UINT32_MAX should be used instead of hard-coding 0x7fff or 100L when calling xcb_get_property_unchecked(). -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On 07/30/2011 06:36 PM, Boris Faure wrote: On Tue, Jul 12, 2011 at 01:10, Christopher Michael cpmicha...@comcast.net wrote: […] 2) It may not build on your system (tho it builds on all boxes I have tried so far). It doesn't build on my boxes (gentoo and arch linux up-to-date). I find that very strange since all of the initial development that I did was on a gentoo box. If I had to guess, I would say you are using ACCEPT_KEYWORDS=~x86 to pull in masked packages...In which case, you are pulling in a development version of XCB and yes it will not build against that. I've got xcb 1.7 and it introduced a split up of xcb-util. I've attached a patch to make ecore_xcb compatible with xcb 1.7. I haven't committed it since it would break your setup. While I appreciate the work/effort that went into your patch, I cannot put it in svn because that would break building for normal distros that use 'current' versions of xcb, not 'bleeding edge' versions. Most normal distros are still shipping 0.3.6 version of the XCB libraries. When they start shipping 0.3.8 by default, then I will gladly put this in svn, but until then, it Cannot go in because while it may fix building for your 'bleeding edge' setup, it breaks building for everyone else :( dh -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On Sun, 31 Jul 2011 19:16:35 -0400 Christopher Michael cpmicha...@comcast.net wrote: On 07/30/2011 06:36 PM, Boris Faure wrote: On Tue, Jul 12, 2011 at 01:10, Christopher Michael cpmicha...@comcast.net wrote: […] 2) It may not build on your system (tho it builds on all boxes I have tried so far). It doesn't build on my boxes (gentoo and arch linux up-to-date). I find that very strange since all of the initial development that I did was on a gentoo box. If I had to guess, I would say you are using ACCEPT_KEYWORDS=~x86 to pull in masked packages...In which case, you are pulling in a development version of XCB and yes it will not build against that. I've got xcb 1.7 and it introduced a split up of xcb-util. I've attached a patch to make ecore_xcb compatible with xcb 1.7. I haven't committed it since it would break your setup. While I appreciate the work/effort that went into your patch, I cannot put it in svn because that would break building for normal distros that use 'current' versions of xcb, not 'bleeding edge' versions. Most normal distros are still shipping 0.3.6 version of the XCB libraries. When they start shipping 0.3.8 by default, then I will gladly put this in svn, but until then, it Cannot go in because while it may fix building for your 'bleeding edge' setup, it breaks building for everyone else :( dh IMO you may want to consider doing something like I have done with eeze and libmount: provide 2 versions of the relevant files with autoconf detection to determine which one actually gets compiled. This way you can support the legacy (0.3.6) version as well as the current (0.3.8) version, and everyone wins. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On 07/31/2011 07:29 PM, Mike Blumenkrantz wrote: On Sun, 31 Jul 2011 19:16:35 -0400 Christopher Michaelcpmicha...@comcast.net wrote: On 07/30/2011 06:36 PM, Boris Faure wrote: On Tue, Jul 12, 2011 at 01:10, Christopher Michael cpmicha...@comcast.net wrote: […] 2) It may not build on your system (tho it builds on all boxes I have tried so far). It doesn't build on my boxes (gentoo and arch linux up-to-date). I find that very strange since all of the initial development that I did was on a gentoo box. If I had to guess, I would say you are using ACCEPT_KEYWORDS=~x86 to pull in masked packages...In which case, you are pulling in a development version of XCB and yes it will not build against that. I've got xcb 1.7 and it introduced a split up of xcb-util. I've attached a patch to make ecore_xcb compatible with xcb 1.7. I haven't committed it since it would break your setup. While I appreciate the work/effort that went into your patch, I cannot put it in svn because that would break building for normal distros that use 'current' versions of xcb, not 'bleeding edge' versions. Most normal distros are still shipping 0.3.6 version of the XCB libraries. When they start shipping 0.3.8 by default, then I will gladly put this in svn, but until then, it Cannot go in because while it may fix building for your 'bleeding edge' setup, it breaks building for everyone else :( dh IMO you may want to consider doing something like I have done with eeze and libmount: provide 2 versions of the relevant files with autoconf detection to determine which one actually gets compiled. This way you can support the legacy (0.3.6) version as well as the current (0.3.8) version, and everyone wins. Yea, that's a thought...except that 0.3.6 is not legacy, it's the 'current' version :) 0.3.8 is a 'development' version :) dh -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On Sun, 31 Jul 2011 19:32:46 -0400 Christopher Michael cpmicha...@comcast.net wrote: On 07/31/2011 07:29 PM, Mike Blumenkrantz wrote: On Sun, 31 Jul 2011 19:16:35 -0400 Christopher Michaelcpmicha...@comcast.net wrote: On 07/30/2011 06:36 PM, Boris Faure wrote: On Tue, Jul 12, 2011 at 01:10, Christopher Michael cpmicha...@comcast.net wrote: […] 2) It may not build on your system (tho it builds on all boxes I have tried so far). It doesn't build on my boxes (gentoo and arch linux up-to-date). I find that very strange since all of the initial development that I did was on a gentoo box. If I had to guess, I would say you are using ACCEPT_KEYWORDS=~x86 to pull in masked packages...In which case, you are pulling in a development version of XCB and yes it will not build against that. I've got xcb 1.7 and it introduced a split up of xcb-util. I've attached a patch to make ecore_xcb compatible with xcb 1.7. I haven't committed it since it would break your setup. While I appreciate the work/effort that went into your patch, I cannot put it in svn because that would break building for normal distros that use 'current' versions of xcb, not 'bleeding edge' versions. Most normal distros are still shipping 0.3.6 version of the XCB libraries. When they start shipping 0.3.8 by default, then I will gladly put this in svn, but until then, it Cannot go in because while it may fix building for your 'bleeding edge' setup, it breaks building for everyone else :( dh IMO you may want to consider doing something like I have done with eeze and libmount: provide 2 versions of the relevant files with autoconf detection to determine which one actually gets compiled. This way you can support the legacy (0.3.6) version as well as the current (0.3.8) version, and everyone wins. Yea, that's a thought...except that 0.3.6 is not legacy, it's the 'current' version :) 0.3.8 is a 'development' version :) dh Unless they're coming out with 0.3.6.1, 0.3.6.2, 0.3.6.3, etc, 0.3.6 is legacy :P -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On 07/31/2011 07:35 PM, Mike Blumenkrantz wrote: On Sun, 31 Jul 2011 19:32:46 -0400 Christopher Michaelcpmicha...@comcast.net wrote: On 07/31/2011 07:29 PM, Mike Blumenkrantz wrote: On Sun, 31 Jul 2011 19:16:35 -0400 Christopher Michaelcpmicha...@comcast.net wrote: On 07/30/2011 06:36 PM, Boris Faure wrote: On Tue, Jul 12, 2011 at 01:10, Christopher Michael cpmicha...@comcast.netwrote: […] 2) It may not build on your system (tho it builds on all boxes I have tried so far). It doesn't build on my boxes (gentoo and arch linux up-to-date). I find that very strange since all of the initial development that I did was on a gentoo box. If I had to guess, I would say you are using ACCEPT_KEYWORDS=~x86 to pull in masked packages...In which case, you are pulling in a development version of XCB and yes it will not build against that. I've got xcb 1.7 and it introduced a split up of xcb-util. I've attached a patch to make ecore_xcb compatible with xcb 1.7. I haven't committed it since it would break your setup. While I appreciate the work/effort that went into your patch, I cannot put it in svn because that would break building for normal distros that use 'current' versions of xcb, not 'bleeding edge' versions. Most normal distros are still shipping 0.3.6 version of the XCB libraries. When they start shipping 0.3.8 by default, then I will gladly put this in svn, but until then, it Cannot go in because while it may fix building for your 'bleeding edge' setup, it breaks building for everyone else :( dh IMO you may want to consider doing something like I have done with eeze and libmount: provide 2 versions of the relevant files with autoconf detection to determine which one actually gets compiled. This way you can support the legacy (0.3.6) version as well as the current (0.3.8) version, and everyone wins. Yea, that's a thought...except that 0.3.6 is not legacy, it's the 'current' version :) 0.3.8 is a 'development' version :) dh Unless they're coming out with 0.3.6.1, 0.3.6.2, 0.3.6.3, etc, 0.3.6 is legacy :P Well, call it whatever you want to. I am too damn tired to argue symantics. The point is, until standard distros start shipping 0.3.8 by default, then we have to build against 0.3.6. End of discussion. dh -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On Sun, 31 Jul 2011 19:40:55 -0400 Christopher Michael cpmicha...@comcast.net wrote: On 07/31/2011 07:35 PM, Mike Blumenkrantz wrote: On Sun, 31 Jul 2011 19:32:46 -0400 Christopher Michaelcpmicha...@comcast.net wrote: On 07/31/2011 07:29 PM, Mike Blumenkrantz wrote: On Sun, 31 Jul 2011 19:16:35 -0400 Christopher Michaelcpmicha...@comcast.net wrote: On 07/30/2011 06:36 PM, Boris Faure wrote: On Tue, Jul 12, 2011 at 01:10, Christopher Michael cpmicha...@comcast.netwrote: […] 2) It may not build on your system (tho it builds on all boxes I have tried so far). It doesn't build on my boxes (gentoo and arch linux up-to-date). I find that very strange since all of the initial development that I did was on a gentoo box. If I had to guess, I would say you are using ACCEPT_KEYWORDS=~x86 to pull in masked packages...In which case, you are pulling in a development version of XCB and yes it will not build against that. I've got xcb 1.7 and it introduced a split up of xcb-util. I've attached a patch to make ecore_xcb compatible with xcb 1.7. I haven't committed it since it would break your setup. While I appreciate the work/effort that went into your patch, I cannot put it in svn because that would break building for normal distros that use 'current' versions of xcb, not 'bleeding edge' versions. Most normal distros are still shipping 0.3.6 version of the XCB libraries. When they start shipping 0.3.8 by default, then I will gladly put this in svn, but until then, it Cannot go in because while it may fix building for your 'bleeding edge' setup, it breaks building for everyone else :( dh IMO you may want to consider doing something like I have done with eeze and libmount: provide 2 versions of the relevant files with autoconf detection to determine which one actually gets compiled. This way you can support the legacy (0.3.6) version as well as the current (0.3.8) version, and everyone wins. Yea, that's a thought...except that 0.3.6 is not legacy, it's the 'current' version :) 0.3.8 is a 'development' version :) dh Unless they're coming out with 0.3.6.1, 0.3.6.2, 0.3.6.3, etc, 0.3.6 is legacy :P Well, call it whatever you want to. I am too damn tired to argue symantics. The point is, until standard distros start shipping 0.3.8 by default, then we have to build against 0.3.6. End of discussion. dh whoa calm down there angrypants, I was just kidding around. let me know if you need/want a review of autoconf stuff :) -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On Sun, 31 Jul 2011 20:05:50 -0400 Mike Blumenkrantz m...@zentific.com wrote: On Sun, 31 Jul 2011 19:40:55 -0400 Christopher Michael cpmicha...@comcast.net wrote: On 07/31/2011 07:35 PM, Mike Blumenkrantz wrote: On Sun, 31 Jul 2011 19:32:46 -0400 Christopher Michaelcpmicha...@comcast.net wrote: On 07/31/2011 07:29 PM, Mike Blumenkrantz wrote: On Sun, 31 Jul 2011 19:16:35 -0400 Christopher Michaelcpmicha...@comcast.net wrote: On 07/30/2011 06:36 PM, Boris Faure wrote: On Tue, Jul 12, 2011 at 01:10, Christopher Michael cpmicha...@comcast.netwrote: […] 2) It may not build on your system (tho it builds on all boxes I have tried so far). It doesn't build on my boxes (gentoo and arch linux up-to-date). I find that very strange since all of the initial development that I did was on a gentoo box. If I had to guess, I would say you are using ACCEPT_KEYWORDS=~x86 to pull in masked packages...In which case, you are pulling in a development version of XCB and yes it will not build against that. I've got xcb 1.7 and it introduced a split up of xcb-util. I've attached a patch to make ecore_xcb compatible with xcb 1.7. I haven't committed it since it would break your setup. While I appreciate the work/effort that went into your patch, I cannot put it in svn because that would break building for normal distros that use 'current' versions of xcb, not 'bleeding edge' versions. Most normal distros are still shipping 0.3.6 version of the XCB libraries. When they start shipping 0.3.8 by default, then I will gladly put this in svn, but until then, it Cannot go in because while it may fix building for your 'bleeding edge' setup, it breaks building for everyone else :( dh IMO you may want to consider doing something like I have done with eeze and libmount: provide 2 versions of the relevant files with autoconf detection to determine which one actually gets compiled. This way you can support the legacy (0.3.6) version as well as the current (0.3.8) version, and everyone wins. Yea, that's a thought...except that 0.3.6 is not legacy, it's the 'current' version :) 0.3.8 is a 'development' version :) dh Unless they're coming out with 0.3.6.1, 0.3.6.2, 0.3.6.3, etc, 0.3.6 is legacy :P Well, call it whatever you want to. I am too damn tired to argue symantics. The point is, until standard distros start shipping 0.3.8 by default, then we have to build against 0.3.6. End of discussion. dh whoa calm down there angrypants, I was just kidding around. let me know if you need/want a review of autoconf stuff :) What ever most distros were shipping *last year* is current, coz that's what most people will actually have. Anything else is bleeding edge, fine for developers, power users, and others that like living on the edge, but wont work for normal users. Supporting both is great, supporting current only is good. Supporting bleeding edge only is bad. And no, it does not matter that what we are making is bleeding edge. :-P -- 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 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On Tue, Jul 12, 2011 at 01:10, Christopher Michael
cpmicha...@comcast.net wrote:
[…]
2) It may not build on your system (tho it builds on all boxes I have
tried so far).
It doesn't build on my boxes (gentoo and arch linux up-to-date).
I've got xcb 1.7 and it introduced a split up of xcb-util.
I've attached a patch to make ecore_xcb compatible with xcb 1.7.
I haven't committed it since it would break your setup.
--
Boris Faure
diff --git a/ecore/configure.ac b/ecore/configure.ac
index fa7ab9d..5c5ecde 100644
--- a/ecore/configure.ac
+++ b/ecore/configure.ac
@@ -784,7 +784,14 @@ if test x$want_ecore_x_xcb = xyes ; then
fi
## x11-xcb
- PKG_CHECK_MODULES(XCB, x11-xcb xcb xcb-shm xcb-icccm xcb-image xcb-keysyms,
+ PKG_CHECK_MODULES(XCB,
+x11-xcb
+xcb
+xcb-shm
+xcb-icccm = 0.3.8
+xcb-util = 0.3.8
+xcb-image
+xcb-keysyms,
[ have_ecore_x_xcb=yes
requirements_ecore_x=x11-xcb xcb xcb-shm xcb-icccm xcb-image xcb-keysyms ${requirements_ecore_x} ],
[ have_ecore_x_xcb=no ])
diff --git a/ecore/src/lib/ecore_x/xcb/ecore_xcb_error.c b/ecore/src/lib/ecore_x/xcb/ecore_xcb_error.c
index c58c13c..9f58feb 100644
--- a/ecore/src/lib/ecore_x/xcb/ecore_xcb_error.c
+++ b/ecore/src/lib/ecore_x/xcb/ecore_xcb_error.c
@@ -67,9 +67,9 @@ _ecore_xcb_error_handle(xcb_generic_error_t *err)
WRN(Got Error:);
WRN(\tEvent: %s, xcb_event_get_request_label(err-major_code));
WRN(\tError: %s, xcb_event_get_error_label(err-error_code));
- if (err-error_code == XCB_EVENT_ERROR_BAD_VALUE)
+ if (err-error_code == XCB_VALUE)
WRN(\tBad Value: %d, ((xcb_value_error_t *)err)-bad_value);
- else if (err-error_code == XCB_EVENT_ERROR_BAD_WINDOW)
+ else if (err-error_code == XCB_WINDOW)
WRN(\tBad Window: %d, ((xcb_window_error_t *)err)-bad_value);
_error_request_code = err-sequence;
diff --git a/ecore/src/lib/ecore_x/xcb/ecore_xcb_events.c b/ecore/src/lib/ecore_x/xcb/ecore_xcb_events.c
index eb2c959..8dbaade 100644
--- a/ecore/src/lib/ecore_x/xcb/ecore_xcb_events.c
+++ b/ecore/src/lib/ecore_x/xcb/ecore_xcb_events.c
@@ -240,14 +240,14 @@ _ecore_xcb_events_handle(xcb_generic_event_t *ev)
* so trap those cases and ignore. We also ignore BadValue from
* xcb_grab/ungrab_button (happens when we are using any_mod)
* and a few others */
-if (err-error_code == XCB_EVENT_ERROR_BAD_WINDOW) return;
-else if (err-error_code == XCB_EVENT_ERROR_BAD_MATCH)
+if (err-error_code == XCB_WINDOW) return;
+else if (err-error_code == XCB_MATCH)
{
if ((err-major_code == XCB_SET_INPUT_FOCUS) ||
(err-major_code == XCB_CONFIGURE_WINDOW))
return;
}
-else if (err-error_code == XCB_EVENT_ERROR_BAD_VALUE)
+else if (err-error_code == XCB_VALUE)
{
if ((err-major_code == XCB_KILL_CLIENT) ||
(err-major_code == XCB_GRAB_BUTTON) ||
@@ -1628,7 +1628,7 @@ _ecore_xcb_event_handle_client_message(xcb_generic_event_t *event)
ecore_event_add(ECORE_X_EVENT_WINDOW_STATE_REQUEST, e, NULL, NULL);
}
else if ((ev-type == ECORE_X_ATOM_WM_CHANGE_STATE)
-(ev-format == 32) (ev-data.data32[0] == XCB_WM_STATE_ICONIC))
+(ev-format == 32) (ev-data.data32[0] == XCB_ICCCM_WM_STATE_ICONIC))
{
Ecore_X_Event_Window_State_Request *e;
diff --git a/ecore/src/lib/ecore_x/xcb/ecore_xcb_icccm.c b/ecore/src/lib/ecore_x/xcb/ecore_xcb_icccm.c
index 6c86686..03dd2cb 100644
--- a/ecore/src/lib/ecore_x/xcb/ecore_xcb_icccm.c
+++ b/ecore/src/lib/ecore_x/xcb/ecore_xcb_icccm.c
@@ -161,7 +161,7 @@ EAPI char *
ecore_x_icccm_title_get(Ecore_X_Window win)
{
xcb_get_property_cookie_t cookie;
- xcb_get_text_property_reply_t prop;
+ xcb_icccm_get_text_property_reply_t prop;
uint8_t ret = 0;
char *title = NULL;
@@ -169,18 +169,18 @@ ecore_x_icccm_title_get(Ecore_X_Window win)
if (!win) return NULL;
- cookie = xcb_get_wm_name_unchecked(_ecore_xcb_conn, win);
- ret = xcb_get_wm_name_reply(_ecore_xcb_conn, cookie, prop, NULL);
+ cookie = xcb_icccm_get_wm_name_unchecked(_ecore_xcb_conn, win);
+ ret = xcb_icccm_get_wm_name_reply(_ecore_xcb_conn, cookie, prop, NULL);
if (ret == 0) return NULL;
if (prop.name_len 1)
{
-xcb_get_text_property_reply_wipe(prop);
+xcb_icccm_get_text_property_reply_wipe(prop);
return NULL;
}
if (!(title = malloc((prop.name_len + 1) * sizeof(char *
{
-xcb_get_text_property_reply_wipe(prop);
+xcb_icccm_get_text_property_reply_wipe(prop);
return NULL;
}
memcpy(title, prop.name, sizeof(char *) * prop.name_len);
@@ -210,7 +210,7 @@ ecore_x_icccm_title_get(Ecore_X_Window win)
}
}
-
Re: [E-devel] Ecore XCB
On Tuesday 12 July 2011 16:25:21 Christopher Michael wrote: The old evas/ecore_x code used xcb_image_create_native to create basic x images, but the code for xcb_image_create_native does not check for endian-ness (it creates everything using MSB_FIRST) which is incorrect. If you need something tested on a big-endian machine, I'm sitting at one right now (PowerPC) and I can do some testing. Drop me a mail or ping me as doomster on irc.freenode.net. That said, why not just create a feature branch in order to implement/restore/fix XCB support? With multiple commits it is easier to backtrack breakage and reason about changes than with one giant drop... Good luck! Uli -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
Sent from my iPod On Jul 15, 2011, at 4:07 PM, Ulrich Eckhardt dooms...@knuut.de wrote: On Tuesday 12 July 2011 16:25:21 Christopher Michael wrote: The old evas/ecore_x code used xcb_image_create_native to create basic x images, but the code for xcb_image_create_native does not check for endian-ness (it creates everything using MSB_FIRST) which is incorrect. If you need something tested on a big-endian machine, I'm sitting at one right now (PowerPC) and I can do some testing. Drop me a mail or ping me as doomster on irc.freenode.net. Thanks. I'll get back to you wrt that one when the time comes. Dh That said, why not just create a feature branch in order to implement/restore/fix XCB support? With multiple commits it is easier to backtrack breakage and reason about changes than with one giant drop... Good luck! Uli -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On 07/12/11 01:07, Alexander Kerner wrote: On Mon, Jul 11, 2011 at 07:10:13PM -0400, Christopher Michael wrote: Hi Lists, This is just another email to let people know that Tuesday (tomorrow in EST), I will start the upload of the ecore changes to get XCB working, so expect some (hopefully minimal) svn breakage. I was going to do it today, but I thought I would send out an email warning to all and give people a day to grab a 'good' svn :) Hm. What was wrong with previous XCB support in evas/ecore? Apart from being incomplete and/or incorrect in some spots ? ;) Btw, there is still no XKB support in XCB, are you going to implement a workaround? Yup, already done. Regards, Alexander Kerner dh -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On Tue, 12 Jul 2011, Christopher Michael wrote: On 07/12/11 01:07, Alexander Kerner wrote: On Mon, Jul 11, 2011 at 07:10:13PM -0400, Christopher Michael wrote: Hi Lists, This is just another email to let people know that Tuesday (tomorrow in EST), I will start the upload of the ecore changes to get XCB working, so expect some (hopefully minimal) svn breakage. I was going to do it today, but I thought I would send out an email warning to all and give people a day to grab a 'good' svn :) Hm. What was wrong with previous XCB support in evas/ecore? Apart from being incomplete and/or incorrect in some spots ? ;) incorrect ? please elaborate. Also, is you ecore_xcb async and event driven ? Vincent Btw, there is still no XKB support in XCB, are you going to implement a workaround? Yup, already done. Regards, Alexander Kerner dh -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On 07/12/11 02:28, Vincent Torri wrote: On Tue, 12 Jul 2011, Christopher Michael wrote: On 07/12/11 01:07, Alexander Kerner wrote: On Mon, Jul 11, 2011 at 07:10:13PM -0400, Christopher Michael wrote: Hi Lists, This is just another email to let people know that Tuesday (tomorrow in EST), I will start the upload of the ecore changes to get XCB working, so expect some (hopefully minimal) svn breakage. I was going to do it today, but I thought I would send out an email warning to all and give people a day to grab a 'good' svn :) Hm. What was wrong with previous XCB support in evas/ecore? Apart from being incomplete and/or incorrect in some spots ? ;) incorrect ? please elaborate. Well, without sifting through every change and listing it here, here's just one example: The old evas/ecore_x code used xcb_image_create_native to create basic x images, but the code for xcb_image_create_native does not check for endian-ness (it creates everything using MSB_FIRST) which is incorrect. I realize that error is not the fault of the evas/ecore code, but still it was incorrect and needed addressing. Also, is you ecore_xcb async and event driven ? Vincent yup dh Btw, there is still no XKB support in XCB, are you going to implement a workaround? Yup, already done. Regards, Alexander Kerner dh -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On Mon, 11 Jul 2011 19:10:13 -0400 Christopher Michael cpmicha...@comcast.net wrote: Hi Lists, This is just another email to let people know that Tuesday (tomorrow in EST), I will start the upload of the ecore changes to get XCB working, so expect some (hopefully minimal) svn breakage. I was going to do it today, but I thought I would send out an email warning to all and give people a day to grab a 'good' svn :) For users, IF you are NOT 'current' with svn (for whatever reason) NOW would be a good time (before the breakage) ;) You should be aware that ecore (with xcb) is still considered 'beta quality' and highly experimental !!! If you try to build EFL/E using the evas ecore xcb stuff, please be aware: 1) It's not recommended for general use yet !! 2) It may not build on your system (tho it builds on all boxes I have tried so far). 3) Even if you do manage to get it built, E17 itself can NOT be run using it (requires e17 svn changes which will come later). 4) There is little to no support for any languages other than English (at the moment). 5) If it toasts your cpu, runs over your cat, kills your hamster, or does any other 'mean or harmful things' then you get to keep the pieces free of charge.remember, you were warned not to build it !! ;) my name is discomfitor and I approve this message. Cheers, dh -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
Bring it on! On 07/12/2011 07:10 AM, Christopher Michael wrote: Hi Lists, This is just another email to let people know that Tuesday (tomorrow in EST), I will start the upload of the ecore changes to get XCB working, so expect some (hopefully minimal) svn breakage. I was going to do it today, but I thought I would send out an email warning to all and give people a day to grab a 'good' svn :) For users, IF you are NOT 'current' with svn (for whatever reason) NOW would be a good time (before the breakage) ;) You should be aware that ecore (with xcb) is still considered 'beta quality' and highly experimental !!! If you try to build EFL/E using the evas ecore xcb stuff, please be aware: 1) It's not recommended for general use yet !! 2) It may not build on your system (tho it builds on all boxes I have tried so far). 3) Even if you do manage to get it built, E17 itself can NOT be run using it (requires e17 svn changes which will come later). 4) There is little to no support for any languages other than English (at the moment). 5) If it toasts your cpu, runs over your cat, kills your hamster, or does any other 'mean or harmful things' then you get to keep the pieces free of charge.remember, you were warned not to build it !! ;) Cheers, dh -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On 07/11/11 21:22, P Purkayastha wrote: Bring it on! On 07/12/2011 07:10 AM, Christopher Michael wrote: Hi Lists, This is just another email to let people know that Tuesday (tomorrow in EST), I will start the upload of the ecore changes to get XCB working, so expect some (hopefully minimal) svn breakage. I was going to do it today, but I thought I would send out an email warning to all and give people a day to grab a 'good' svn :) For users, IF you are NOT 'current' with svn (for whatever reason) NOW would be a good time (before the breakage) ;) You should be aware that ecore (with xcb) is still considered 'beta quality' and highly experimental !!! If you try to build EFL/E using the evas ecore xcb stuff, please be aware: 1) It's not recommended for general use yet !! 2) It may not build on your system (tho it builds on all boxes I have tried so far). 3) Even if you do manage to get it built, E17 itself can NOT be run using it (requires e17 svn changes which will come later). 4) There is little to no support for any languages other than English (at the moment). 5) If it toasts your cpu, runs over your cat, kills your hamster, or does any other 'mean or harmful things' then you get to keep the pieces free of charge.remember, you were warned not to build it !! ;) Cheers, dh ppurka, Well, it may have just gotten delayed for not sure how long. I just saw some recent commits to ecore for IMF stuff, and this adds delays to getting my stuff committed because now I have to try and merge the imf commits into the changes that I needed to commit...in short, more work for me :/ and a potential delay in getting this in svn. dh -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On Mon, 11 Jul 2011 22:49:33 -0400 Christopher Michael cpmicha...@comcast.net wrote: On 07/11/11 21:22, P Purkayastha wrote: Bring it on! On 07/12/2011 07:10 AM, Christopher Michael wrote: Hi Lists, This is just another email to let people know that Tuesday (tomorrow in EST), I will start the upload of the ecore changes to get XCB working, so expect some (hopefully minimal) svn breakage. I was going to do it today, but I thought I would send out an email warning to all and give people a day to grab a 'good' svn :) For users, IF you are NOT 'current' with svn (for whatever reason) NOW would be a good time (before the breakage) ;) You should be aware that ecore (with xcb) is still considered 'beta quality' and highly experimental !!! If you try to build EFL/E using the evas ecore xcb stuff, please be aware: 1) It's not recommended for general use yet !! 2) It may not build on your system (tho it builds on all boxes I have tried so far). 3) Even if you do manage to get it built, E17 itself can NOT be run using it (requires e17 svn changes which will come later). 4) There is little to no support for any languages other than English (at the moment). 5) If it toasts your cpu, runs over your cat, kills your hamster, or does any other 'mean or harmful things' then you get to keep the pieces free of charge.remember, you were warned not to build it !! ;) Cheers, dh ppurka, Well, it may have just gotten delayed for not sure how long. I just saw some recent commits to ecore for IMF stuff, and this adds delays to getting my stuff committed because now I have to try and merge the imf commits into the changes that I needed to commit...in short, more work for me :/ and a potential delay in getting this in svn. dh -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel THAT'S WHAT YOU GET FOR WAITING TO BREAK SVN -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On 07/11/11 22:55, Mike Blumenkrantz wrote: On Mon, 11 Jul 2011 22:49:33 -0400 Christopher Michaelcpmicha...@comcast.net wrote: On 07/11/11 21:22, P Purkayastha wrote: Bring it on! On 07/12/2011 07:10 AM, Christopher Michael wrote: Hi Lists, This is just another email to let people know that Tuesday (tomorrow in EST), I will start the upload of the ecore changes to get XCB working, so expect some (hopefully minimal) svn breakage. I was going to do it today, but I thought I would send out an email warning to all and give people a day to grab a 'good' svn :) For users, IF you are NOT 'current' with svn (for whatever reason) NOW would be a good time (before the breakage) ;) You should be aware that ecore (with xcb) is still considered 'beta quality' and highly experimental !!! If you try to build EFL/E using the evasecore xcb stuff, please be aware: 1) It's not recommended for general use yet !! 2) It may not build on your system (tho it builds on all boxes I have tried so far). 3) Even if you do manage to get it built, E17 itself can NOT be run using it (requires e17 svn changes which will come later). 4) There is little to no support for any languages other than English (at the moment). 5) If it toasts your cpu, runs over your cat, kills your hamster, or does any other 'mean or harmful things' then you get to keep the pieces free of charge.remember, you were warned not to build it !! ;) Cheers, dh ppurka, Well, it may have just gotten delayed for not sure how long. I just saw some recent commits to ecore for IMF stuff, and this adds delays to getting my stuff committed because now I have to try and merge the imf commits into the changes that I needed to commit...in short, more work for me :/ and a potential delay in getting this in svn. dh THAT'S WHAT YOU GET FOR WAITING TO BREAK SVN :P -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore XCB
On Mon, Jul 11, 2011 at 07:10:13PM -0400, Christopher Michael wrote: Hi Lists, This is just another email to let people know that Tuesday (tomorrow in EST), I will start the upload of the ecore changes to get XCB working, so expect some (hopefully minimal) svn breakage. I was going to do it today, but I thought I would send out an email warning to all and give people a day to grab a 'good' svn :) Hm. What was wrong with previous XCB support in evas/ecore? Btw, there is still no XKB support in XCB, are you going to implement a workaround? Regards, Alexander Kerner -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
