Nabble - Free Desktop - xcb

[ANNOUNCE] xpyb 1.2

2009-12-17T12:07:09Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

xpyb 1.2 is now available.

git tag 1.2

Changelog
=========
Adam Jackson (1):
Multilib install fix

Aldo Cortesi (1):
Fix scope error in generated definition of QueryTextExtents. (cherry picked from commit aa0fc9

Eamon F Walsh (2):
Add a COPYING file.
Add a copy of the documentation from the wiki.

Eamon Walsh (2):
Install documentation and README files.
Release xpyb 1.2

Download
========
http://xcb.freedesktop.org/dist/xpyb-1.2.tar.gz
md5: 9294aad6a72b1943fba351f64db088e7
sha1: 184cb5194a38b01fcff2c5e19cc7f0b7baa06771

http://xcb.freedesktop.org/dist/xpyb-1.2.tar.bz2
md5: 953cd851d7ad3e59577062ca53c77f3d
sha1: 1fbb6a128e8c46321e1a5197c6c55c0b884c28fa

- --
Eamon Walsh
National Security Agency
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksqjuIACgkQXKrSC8VF5s0ccwCfUwnSyGCSFPMtXCM+qrr/a4FL
twIAn3yrfVZDR5bpoa2K6m0Cltji5pR+
=p+mV
-----END PGP SIGNATURE-----

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-17T09:56:05Z

On Wed, Dec 16, 2009 at 10:19 PM, Barton C Massey <bart@...> wrote:
> I don't recall that there's anything in the X Protocol Specification
> that prevents servers from hardwiring atoms other than the standard
> ones. ... As long as the server correctly responds to intern_atom
> requests for the hardwired atoms, you should be good.

That's right, as far as I know.

> Just the presence of an extension with the right version number (e.g.
> a sufficiently advanced MISC extension) could indicate this. ... The
> primary benefit would be killing one or more round trips...

As Rémi said, all those InternAtom requests are batched into a single
round-trip, so you need something with zero round-trips to win on
latency. A protocol version bump is the only way to get that, I think,
although it could possibly be a minor version bump as Alan suggested.

The only advantage of an extension is a bandwidth savings, and the
disadvantages are having to decide which atoms are worthy of being
included in an extension, and having to take at least one extra
round-trip if the extension isn't available. In fact I think an
extension would require two round-trips even in the success case: one
for QueryExtension and another for the extension's QueryVersion, or some
similar second request to decide which atoms are available.

I've added notes at the X12 page about how I think I'd handle this.
http://www.x.org/wiki/Development/X12

Jamey
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-17T00:47:17Z

At 1260950948 time_t, Julien Danjou wrote:
> As far as I understand, this is not possible until X12: atoms that are
> predefined and atom that are not are a in the proto spec.

Answering to myself for future quote:
EWMH is a bad standard and including its atoms as it part
of X$whatever sounds like a bad idea in its current state.

--
Julien Danjou
// ᐰ <julien@...> http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// Tomorrow I was nothing, yesterday I'll be.

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

signature.asc (205 bytes) Download Attachment

Re: EWMH API for XCB

2009-12-16T23:51:50Z

Hello,

On Wed, 16 Dec 2009 22:19:11 -0800, Barton C Massey <bart@...>
wrote:
> I don't recall that there's anything in the X Protocol
> Specification that prevents servers from hardwiring atoms
> other than the standard ones. Just the presence of an
> extension with the right version number (e.g. a sufficiently
> advanced MISC extension) could indicate this.

Pardon my ignorance, but don't you need a round trip to check for an
extension as well? Wouldn't that just replace one round trip for another
one in the successful case, and add one extra round trip in the failure
case?

--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-16T22:19:11Z

I don't recall that there's anything in the X Protocol
Specification that prevents servers from hardwiring atoms
other than the standard ones. Just the presence of an
extension with the right version number (e.g. a sufficiently
advanced MISC extension) could indicate this. As long as
the server correctly responds to intern_atom requests for
the hardwired atoms, you should be good. I think apps that
find the right evidence would be well within their rights to
assume that they didn't need to intern EWMH atoms by prior
agreement, without moving to X12. The primary benefit would
be killing one or more round trips...

I'm sure I'm confused as usual, though.

Bart
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

xpyb bub

2009-12-16T21:23:06Z

Hi folks,

I'm porting a window manger over from a Python Xlib implementation, to
xpyb. I'm tripping over a bug in the generated definition for
QueryTextExtents:

def QueryTextExtents(self, font, string_len, string):
buf = cStringIO.StringIO()
buf.write(pack('x', ))
buf.write(pack('B', (self.string_len & 1)))
^^^^^^^^^^^^^^^^^

The enclosing xprotoExtension object does not have a string_len attribute - the
definition should look like this:

def QueryTextExtents(self, font, string_len, string):
buf = cStringIO.StringIO()
buf.write(pack('x', ))
buf.write(pack('B', (string_len & 1)))

Below is a small patch that fixes this problem. It checks whether the
enclosing object is a Request, and uses the appropriate scope. The
patch can be made nicer by adding an is_request attribute to Request
(similar to the existing is_reply attribute on Reply), so someone with
commit to both the xpyb and xcbgen projects could clean it up a bit.

The patch can also be pulled from my repo here:

git://github.com/cortesi/xpyb.git

Regards,

Aldo

--
Aldo Cortesi
www.nullcube.com
+64 210 718 900

diff --git a/src/py_client.py b/src/py_client.py
index c056fd6..c25e39d 100755
--- a/src/py_client.py
+++ b/src/py_client.py
@@ -257,7 +257,11 @@ def _py_get_length_field(expr):
Otherwise, just reference the structure field directly.
'''
if expr.lenfield_name != None:
- return 'self.%s' % expr.lenfield_name
+ # This would be nicer if Request had an is_request attribute...
+ if hasattr(expr.parent.parent, "opcode"):
+ return expr.lenfield_name
+ else:
+ return 'self.%s' % expr.lenfield_name
else:
return str(expr.nmemb)
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-16T11:27:38Z

On Wed, 16 Dec 2009, Arnaud Fontaine wrote:

> Ok, that's unfortunate ;). So let's wait for X12 (which should happen
> Somewhere in Time)...

Iron Maiden power !

Vincent

ps: sorry for the noise

>I have just added an entry in the page pointed out
> by Alan.
>
> Cheers,
> Arnaud
> _______________________________________________
> Xcb mailing list
> Xcb@...
> http://lists.freedesktop.org/mailman/listinfo/xcb
>
>

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-16T11:11:51Z

>>>>> Jamey Sharp <jamey@...> writes:

Hi,

> Something could be done with an extension, though. As a thought
> experiment, imagine an extension which, if present, means all the
> EWMH atoms are in a continguous range that you can query from the
> extension. But there wouldn't be much value in that, I think.

I think so too that it would not be really valuable as an extension.

>> Since it's not an incompatible change, couldn't it be done in a
>> R7 of the X11 protocol spec? (Even though we claim the katamari
>> is X11R7.x now, the last X11 protocol spec update was R6.8, when
>> we defined the new constants & address families for IPv6.)

> I'd forgotten the X protocol even *had* a minor version, but
> that's still set to 0. (See X_PROTOCOL_REVISION in either X.h or
> xcb.h.)

> I don't think there's any infrastructure for handling minor
> protocol version bumps in any of the client libraries. It might
> have been better to do a minor version change instead of an
> extension for big-requests and for generic events, but since the
> facility is untested I suppose we'll continue using extensions to
> describe protocol changes.

Ok, that's unfortunate ;). So let's wait for X12 (which should happen
Somewhere in Time)... I have just added an entry in the page pointed out
by Alan.

Cheers,
Arnaud
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-16T10:58:44Z

>>>>> Jamey Sharp <jamey@...> writes:

Hi,

> A nice way to test a multi-screen setup is with Xnest or Xephyr,
> which let you configure several screens that all show up as
> windows on your real screen.

Yes, I usually Xephyr which is really useful for testing.

> Cool, I like this much better! I hope passing the screen number to
> all those calls doesn't make using this code too painful?

I think that's ok as it's just one parameter, and it couldn't have been
fixed otherwise IMO.

> Minor further suggestions, in xcb_ewmh_init_atoms:

> You don't need to count the number of screens. You have a bunch of
> options, but since you're getting an iterator over them, I'd just
> set ewmh-> nb_screens = screen_iter.rem before using the iterator
> in any loops. Or if you want your code to be more
> self-explanatory, set ewmh-> nb_screens =
> xcb_setup_roots_length(setup).

You're right, I used these functions quite a while ago but I didn't
check when I wrote my code. Thanks much. I have committed it there[0]

> Each entry in wm_cm_sn is used only once, so I'd declare it inside
> the loop as a single buffer that you reuse each time, instead of
> using C99's variable-length arrays (VLA). It's nice that C99 added
> VLA support, but you don't need it here, and last I checked GDB
> did a bad job debugging functions with VLAs in them.

Thanks. I have committed there[1].

>> Hrm ok, oops... I have silently and discretly edited my previous
>> commit to hide that :).

> Nicely done. ;-) Looks right to me now, and the history clearly
> shows that it was right all along. ;-)

;)

> I'm not as concerned as you are about consistency across different
> projects, but I think there's a lot of value in documenting "best
> practices" for setting up these projects. I'd completely approve
> of additions to the wiki about these topics, but of course it's a
> wiki, so you don't need my approval anyway. :-)

Thanks for all the comments again! I will commit a patch tomorrow to
ship ewmh as its own library.

Cheers,
Arnaud

[0] http://cgit.freedesktop.org/~arnau/xcb-util/commit/?h=xcb-ewmh&id=137eb9e775e920e217ed4ae70d69d1f482a4472a
[1] http://cgit.freedesktop.org/~arnau/xcb-util/commit/?h=xcb-ewmh&id=39684ad478e0c557276f8ba14b830547d47cd876
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-16T08:48:51Z

On Wed, Dec 16, 2009 at 07:42:59AM -0800, Alan Coopersmith wrote:
> Since it's not an incompatible change, couldn't it be done in a R7 of the
> X11 protocol spec? (Even though we claim the katamari is X11R7.x now,
> the last X11 protocol spec update was R6.8, when we defined the new
> constants & address families for IPv6.)

I'd forgotten the X protocol even *had* a minor version, but that's
still set to 0. (See X_PROTOCOL_REVISION in either X.h or xcb.h.)

I don't think there's any infrastructure for handling minor protocol
version bumps in any of the client libraries. It might have been better
to do a minor version change instead of an extension for big-requests
and for generic events, but since the facility is untested I suppose
we'll continue using extensions to describe protocol changes.

Jamey

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

signature.asc (205 bytes) Download Attachment

Re: EWMH API for XCB

2009-12-16T07:42:59Z

Julien Danjou wrote:
> At 1260922943 time_t, Arnaud Fontaine wrote:
>> As EWMH becomes more and more popular, I hope these atoms will be
>> pre-defined like ICCCM, as it would mean much less code/requests. Is
>> there any plan for that? (I guess it's not at all a priority for now,
>> but well, it would be much easier)
>
> As far as I understand, this is not possible until X12: atoms that are
> predefined and atom that are not are a in the proto spec.

Since it's not an incompatible change, couldn't it be done in a R7 of the
X11 protocol spec? (Even though we claim the katamari is X11R7.x now,
the last X11 protocol spec update was R6.8, when we defined the new
constants & address families for IPv6.)

If not, the X12 wishlist is available for your wiki-editing pleasure:
http://www.x.org/wiki/Development/X12

--
-Alan Coopersmith- alan.coopersmith@...
Sun Microsystems, Inc. - X Window System Engineering

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-16T00:18:49Z

On Wed, Dec 16, 2009 at 12:09 AM, Julien Danjou <julien@...> wrote:
> At 1260922943 time_t, Arnaud Fontaine wrote:
>> As EWMH becomes more and more popular, I hope these atoms will be
>> pre-defined like ICCCM, as it would mean much less code/requests. Is
>> there any plan for that? (I guess it's not at all a priority for now,
>> but well, it would be much easier)
>
> As far as I understand, this is not possible until X12: atoms that are
> predefined and atom that are not are a in the proto spec.

Oh yes, I knew there was something I'd forgotten to reply to. That's
absolutely correct: The list of predefined atoms won't change until
the hypothetical X12, which will also replace the root weave with
ponies.

Something could be done with an extension, though. As a thought
experiment, imagine an extension which, if present, means all the EWMH
atoms are in a continguous range that you can query from the
extension. But there wouldn't be much value in that, I think.

Jamey
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-16T00:09:08Z

At 1260922943 time_t, Arnaud Fontaine wrote:
> As EWMH becomes more and more popular, I hope these atoms will be
> pre-defined like ICCCM, as it would mean much less code/requests. Is
> there any plan for that? (I guess it's not at all a priority for now,
> but well, it would be much easier)

As far as I understand, this is not possible until X12: atoms that are
predefined and atom that are not are a in the proto spec.

--
Julien Danjou
// ᐰ <julien@...> http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// My root password is

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

signature.asc (205 bytes) Download Attachment

Re: EWMH API for XCB

2009-12-15T19:34:35Z

On Wed, Dec 16, 2009 at 01:14:47AM +0100, Arnaud Fontaine wrote:
> >>>>> Jamey Sharp <jamey@...> writes:
> >> I'm a bit confused by this macro and does not understand anything
> >> besides of the basic principle. I was thinking about simply
> >> adding an assertion otherwise.
>
> > Absolutely, that would be better than nothing.
>
> Well, I think it would be better to not make it static as it could be
> useful to any program implementing extensions to EWMH.

That makes sense.

> Therefore, I have just added an assert()[0]. I think it's ok this way,
> isn't it?

Josh's explanation of the difficulties with asserts aside, it's fine
with me. :-)

> > I'm not talking about different connections. I'm talking about
> > different screens on the same connection. All the atoms are
> > guaranteed to be the same in that case, except for _NET_WM_CM_Sn.
>
> Oh ok, I didn't think at all about that as I have never used such
> configuration.

A nice way to test a multi-screen setup is with Xnest or Xephyr, which
let you configure several screens that all show up as windows on your
real screen.

> Therefore, I removed root member of xcb_ewmh_connection_t
> in favor of screens and nb_screens. I added a parameter, namely the
> screen number, to all the functions using the root window. Also, I
> modified _NET_WM_CM_Sn which is now per-screen (xcb_atom_t *). I have
> committed it there[1].

Cool, I like this much better! I hope passing the screen number to all
those calls doesn't make using this code too painful?

Minor further suggestions, in xcb_ewmh_init_atoms:

You don't need to count the number of screens. You have a bunch of
options, but since you're getting an iterator over them, I'd just set
ewmh->nb_screens = screen_iter.rem before using the iterator in any
loops. Or if you want your code to be more self-explanatory, set
ewmh->nb_screens = xcb_setup_roots_length(setup).

Each entry in wm_cm_sn is used only once, so I'd declare it inside the
loop as a single buffer that you reuse each time, instead of using C99's
variable-length arrays (VLA). It's nice that C99 added VLA support, but
you don't need it here, and last I checked GDB did a bad job debugging
functions with VLAs in them.

> Hrm ok, oops... I have silently and discretly edited my previous commit
> to hide that :).

Nicely done. ;-) Looks right to me now, and the history clearly shows
that it was right all along. ;-)

> >> > Do you really want it in the xcb-util bundle though?
>
> I think it does make sense and I will put it in a separate repository
> then. However, I think it would be good to share at least configure.ac,
> coding style (I have not found anything like that except by looking at
> existing code but it's pretty unconsistent ATM AFAIK), and Doxygen
> configuration in order to have something consistent across libraries,
> even though I'm not sure how it could be achieve. Maybe a document on
> the wiki giving some templates such as Doxygen and configure.ac and
> another one for the coding style as it's more general?

I'm not as concerned as you are about consistency across different
projects, but I think there's a lot of value in documenting "best
practices" for setting up these projects. I'd completely approve of
additions to the wiki about these topics, but of course it's a wiki, so
you don't need my approval anyway. :-)

> Thank you very much for all your comments. The code looks much better
> now!

Thanks for your hard work. :-) This is cool!

Jamey

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

signature.asc (205 bytes) Download Attachment

Re: EWMH API for XCB

2009-12-15T17:01:41Z

>>>>> Josh Triplett <josh@...> writes:

Hi,

>> Well, I think it would be better to not make it static as it
>> could be useful to any program implementing extensions to
>> EWMH. Therefore, I have just added an assert()[0]. I think it's
>> ok this way, isn't it?

> In XCB, we've had some bad experiences with asserts, simply
> because end-users notice them and blame XCB rather than buggy
> applications. :) Detecting problems at compile time seem ideal
> when you can. This case seems somewhat less problematic since an
> application would have to explicitly use your new library;
> however, I'd still suggest doing as much checking as you possibly
> can at compile time.

Yes, it makes sense, I didn't think about that point. Could you suggest
a patch as I don't really know how to do it properly? Thanks much.

Cheers,
Arnaud
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-15T16:51:25Z

On Wed, Dec 16, 2009 at 01:14:47AM +0100, Arnaud Fontaine wrote:

> >>>>> Jamey Sharp <jamey@...> writes:
> > Yeah, the data_len parameter in xcb_ewmh_send_client_message isn't
> > a constant, so it can't be checked at compile time. I meant that
> > you'd add something like this in every caller:
>
> > BUILD_BUG_ON(sizeof data > sizeof ((xcb_client_message_event_t *)
> > 0)->data);
>
> > Unlike an assertion, this doesn't generate any code; instead the
> > compiler can prove that all those calls are safe, but only if
> > you've checked all the callers, which is why I suggested making
> > this function static. Also, you could wrap
> > xcb_ewmh_send_client_message up in a macro that does this, if you
> > wanted.
>
> >> I'm a bit confused by this macro and does not understand anything
> >> besides of the basic principle. I was thinking about simply
> >> adding an assertion otherwise.
>
> > Absolutely, that would be better than nothing.
>
> Well, I think it would be better to not make it static as it could be
> useful to any program implementing extensions to EWMH. Therefore, I have
> just added an assert()[0]. I think it's ok this way, isn't it?

In XCB, we've had some bad experiences with asserts, simply because
end-users notice them and blame XCB rather than buggy applications. :)
Detecting problems at compile time seem ideal when you can. This case
seems somewhat less problematic since an application would have to
explicitly use your new library; however, I'd still suggest doing as
much checking as you possibly can at compile time.

- Josh Triplett
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-15T16:22:23Z

>>>>> Barton C Massey <bart@...> writes:

Hi,

> I understand. But shouldn't we just use the Python thing on XML
> instead of the m4 thing on, well, m4 to generate the C code
> anyway, is all I'm saying?

Well, as Jamey explained, it's not really possible to use XML for
that. However, I didn't use m4 a lot as I think it becomes quickly
unreadable, thus not easily maintainable, but that's just my opinion ;).

As EWMH becomes more and more popular, I hope these atoms will be
pre-defined like ICCCM, as it would mean much less code/requests. Is
there any plan for that? (I guess it's not at all a priority for now,
but well, it would be much easier)

Arnaud
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-15T16:14:47Z

>>>>> Jamey Sharp <jamey@...> writes:

Hi,

> Yeah, the data_len parameter in xcb_ewmh_send_client_message isn't
> a constant, so it can't be checked at compile time. I meant that
> you'd add something like this in every caller:

> BUILD_BUG_ON(sizeof data > sizeof ((xcb_client_message_event_t *)
> 0)->data);

> Unlike an assertion, this doesn't generate any code; instead the
> compiler can prove that all those calls are safe, but only if
> you've checked all the callers, which is why I suggested making
> this function static. Also, you could wrap
> xcb_ewmh_send_client_message up in a macro that does this, if you
> wanted.

>> I'm a bit confused by this macro and does not understand anything
>> besides of the basic principle. I was thinking about simply
>> adding an assertion otherwise.

> Absolutely, that would be better than nothing.

Well, I think it would be better to not make it static as it could be
useful to any program implementing extensions to EWMH. Therefore, I have
just added an assert()[0]. I think it's ok this way, isn't it?

> I'm not talking about different connections. I'm talking about
> different screens on the same connection. All the atoms are
> guaranteed to be the same in that case, except for _NET_WM_CM_Sn.

Oh ok, I didn't think at all about that as I have never used such
configuration. Therefore, I removed root member of xcb_ewmh_connection_t
in favor of screens and nb_screens. I added a parameter, namely the
screen number, to all the functions using the root window. Also, I
modified _NET_WM_CM_Sn which is now per-screen (xcb_atom_t *). I have
committed it there[1].

> The patch looks good to me, except that I think it's wrong. :-)
> You're assigning an XID to a dereferenced pointer of type "char",
> as far as I can tell. I think you need one more cast on the
> left-hand side, something like this:

> *(xcb_atom_t *) ((char *) ewmh + ewmh_atoms[i].m_offset) =
> reply->atom;

Hrm ok, oops... I have silently and discretly edited my previous commit
to hide that :).

>> That's why I have only defined accessors for
>> _NET_WM_SYNC_REQUEST_COUNTER.

> Yes, all your functions are named *_request_counter, but they all
> use
ewmh-> _NET_WM_SYNC_REQUEST. Isn't that wrong?

> And the comment header still has that typo of missing a "T". ;-)

I did not see it at all. Thanks much! I have just committed it[1].

>> > Do you really want it in the xcb-util bundle though?
>>
>> Well, I think it's better to keep it within xcb-util.

> I'd be interested in hearing your thoughts on the discussion
> Julien and I had today on this topic.

> I think the history of free software contradicts this. For
> example, bundling lots of code into libX11 certainly didn't help
> it be maintained any better. :-) Conversely, lots of projects
> abandoned by their original authors have been picked up by
> somebody else who needed them, despite not being bundled with
> anything else.

>> Moreover, xcb-util/icccm and xcb-util/image are already used in
>> other projects, but are still parts of xcb-util.

> Yes, so are aux, and render-util I think, and awesome is using the
> property and event libraries apparently. And yes, I'd like all of
> those split out, but just because that hasn't happened doesn't
> mean we should add anything more to the mess.

I think it does make sense and I will put it in a separate repository
then. However, I think it would be good to share at least configure.ac,
coding style (I have not found anything like that except by looking at
existing code but it's pretty unconsistent ATM AFAIK), and Doxygen
configuration in order to have something consistent across libraries,
even though I'm not sure how it could be achieve. Maybe a document on
the wiki giving some templates such as Doxygen and configure.ac and
another one for the coding style as it's more general?

Thank you very much for all your comments. The code looks much better
now!

Cheers,
Arnaud

[0] http://cgit.freedesktop.org/~arnau/xcb-util/commit/?h=xcb-ewmh&id=d9fa9092f0b7dadef0797a01b301605c7d35984e
[1] http://cgit.freedesktop.org/~arnau/xcb-util/commit/?h=xcb-ewmh&id=d301f9210a3594829451e4559644747c1f88444a
[2] http://cgit.freedesktop.org/~arnau/xcb-util/commit/?h=xcb-ewmh&id=9e76acc5599026d22c329e10c4e9a14ada90900d
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: POSIX threads cancellation / VLC

2009-12-15T00:23:44Z

On Tue, Dec 15, 2009 at 07:54:13AM +0100, Rémi Denis-Courmont wrote:
> I am happy to announce that VLC media player (what will become vesion
> 1.1.0) has been almost completely ported to XCB. Namely, the X11 and XVideo
> outputs, the screen capture input, the (new) screen capture wizard, the
> windowing code, the "global hotkeys", and the seldom used panaromic video
> filter are now purely XCB-based. Also, the GLX output was rewritten to
> X11-XCB. This just leave the Qt4 UI, the VAAPI bindings to libavcodec, and
> the skin engine using Xlib.

Incredibly awesome! Thank you for telling us about this!

> The main driver for XCB was saner error/event handling and thread safety.
> It was practically impossible to use Xlib properly with the multi-thread
> and plugin-based architecture that VLC has. Also, this was a good
> opportunity to rebuild our X11 competence and refactor the aging code.

Glad to hear you've had a good experience with those particular pieces
of XCB; we spent a disproportionately large amount of effort getting
those pieces *right*, making it really gratifying to hear that we
succeeded. Thank you!

> Anyway. VLC uses *synchronous* thread cancellation in many code paths, and
> our XCB event handling looks like:
>
> for (;;)
> {
> poll(xcb_fd);
> disable_cancel();
> handle_xcb_events...;
> enable_cancel();
> }
>
> This is not terribly efficient. We could use XCB in blocking mode, but we
> need to catch the cancel signal from a safe place. So I'm wondering if
> handling thread cancellation directly inside XCB would be acceptable.
> Mostly, this means installing cleanup handlers in strategic places, and
> disabling cancellation in some other ones in the core XCB code.

Handling cancellation seems fairly reasonable. We've used pthreads in
XCB, so that makes it fairly reasonable that we ought to support
the use of pthreads functionality, including cancellation.

> I had a partial patch for this, but I wouldn't bother rebasing it you guys
> don't like the idea at all.

I'd like to see the patch. Please do go ahead and send it. You don't
necessarily have to go to the trouble of rebasing it before sending it,
if you've written it against a relatively recent XCB. Go ahead and send
it, tell us what version it applies to, and we can evaluate it enough to
get the idea and figure out if you should go ahead and rebase.

- Josh Tiplett
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: POSIX threads cancellation / VLC

2009-12-14T23:28:49Z

You wrote:
> I am happy to announce that VLC media player (what will become vesion
> 1.1.0) has been almost completely ported to XCB. Namely, the X11 and XVideo
> outputs, the screen capture input, the (new) screen capture wizard, the
> windowing code, the "global hotkeys", and the seldom used panaromic video
> filter are now purely XCB-based. Also, the GLX output was rewritten to
> X11-XCB. This just leave the Qt4 UI, the VAAPI bindings to libavcodec, and
> the skin engine using Xlib.

Wow! Cool!

Hmmm. I don't know if I have a strong opinion on this. On
the one hand it would muck up the code some, but on the
other hand other folks might want it also, in which case it
would be worth it.

Let's see what the rest of the list thinks?

Thanks much for the note.

Bart
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

POSIX threads cancellation / VLC

2009-12-14T22:54:13Z

Hello,

I am happy to announce that VLC media player (what will become vesion
1.1.0) has been almost completely ported to XCB. Namely, the X11 and XVideo
outputs, the screen capture input, the (new) screen capture wizard, the
windowing code, the "global hotkeys", and the seldom used panaromic video
filter are now purely XCB-based. Also, the GLX output was rewritten to
X11-XCB. This just leave the Qt4 UI, the VAAPI bindings to libavcodec, and
the skin engine using Xlib.

The main driver for XCB was saner error/event handling and thread safety.
It was practically impossible to use Xlib properly with the multi-thread
and plugin-based architecture that VLC has. Also, this was a good
opportunity to rebuild our X11 competence and refactor the aging code.

Anyway. VLC uses *synchronous* thread cancellation in many code paths, and
our XCB event handling looks like:

for (;;)
{
poll(xcb_fd);
disable_cancel();
handle_xcb_events...;
enable_cancel();
}

This is not terribly efficient. We could use XCB in blocking mode, but we
need to catch the cancel signal from a safe place. So I'm wondering if
handling thread cancellation directly inside XCB would be acceptable.
Mostly, this means installing cleanup handlers in strategic places, and
disabling cancellation in some other ones in the core XCB code.

I had a partial patch for this, but I wouldn't bother rebasing it you guys
don't like the idea at all.

Best regards,

--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: XCB Workshop?

2009-12-14T22:27:56Z

X.Org can easily afford to send you, and in my opinion
(which matters) it would be really relevant to have you
here. Let me know if I can change your mind.

Bart

In message <sa51vixnlam.fsf@...> you wrote:

> Hi,
>
> I would have been happy to come but it would be too expensive for me and
> considering that I'm not a core developer at all, I think it would not
> make sense to ask for sponsorship. Hope there will be another meeting
> nearer ;).
>
> Cheers,
> Arnaud
> _______________________________________________
> Xcb mailing list
> Xcb@...
> http://lists.freedesktop.org/mailman/listinfo/xcb

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: XCB Workshop?

2009-12-14T17:42:41Z

On Tue, Dec 15, 2009 at 01:16:49AM +0100, Arnaud Fontaine wrote:
> I would have been happy to come but it would be too expensive for me and
> considering that I'm not a core developer at all, I think it would not
> make sense to ask for sponsorship. Hope there will be another meeting
> nearer ;).

The Awesome window manager is one of the most extensive users of XCB.
Can I encourage you to at least ask Bart and X.org, and see what they
say?

Seriously folks, there's no harm in asking. Don't be shy. :-)

Jamey

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

signature.asc (205 bytes) Download Attachment

Re: EWMH API for XCB

2009-12-14T17:39:13Z

On Tue, Dec 15, 2009 at 01:13:38AM +0100, Arnaud Fontaine wrote:

> >>>>> "Jamey" == Jamey Sharp <jamey@...> writes:
> > In xcb_ewmh_send_client_message, you probably should check
> > data_len before copying data into a fixed-size buffer--unless you
> > want to declare that function static and ensure that all the
> > callers are safe. If you want to go the latter route you might
> > look at the BUILD_BUG_ON macro from include/linux/kernel.h, to get
> > a compile-time check.
>
> When adding the following macro:
> #define BUILD_BUG_OR_ZERO(e) ((void) (sizeof(struct { int:-!!(e); })))
>
> And the following line before the memcpy:
> BUILD_BUG_OR_ZERO((data_len >> 2) > 5);
>
> I get the following error I can't get rid of:
> ewmh.c:563: error: bit-field ‘<anonymous>’ width not an integer constant

Yeah, the data_len parameter in xcb_ewmh_send_client_message isn't a
constant, so it can't be checked at compile time. I meant that you'd add
something like this in every caller:

BUILD_BUG_ON(sizeof data > sizeof ((xcb_client_message_event_t *) 0)->data);

Unlike an assertion, this doesn't generate any code; instead the
compiler can prove that all those calls are safe, but only if you've
checked all the callers, which is why I suggested making this function
static. Also, you could wrap xcb_ewmh_send_client_message up in a macro
that does this, if you wanted.

> I'm a bit confused by this macro and does not understand anything
> besides of the basic principle. I was thinking about simply adding an
> assertion otherwise.

Absolutely, that would be better than nothing.

> > Huh. So an xcb_ewmh_connection_t is only usable on a single
> > screen, and you have to pick which one to use when you initialize
> > it? I know X's concept of screens is becoming pretty obsolete in
> > the RandR era, but if anything still has to deal with multi-screen
> > setups it'd be window managers.
>
> Actually, it's the caller who takes care of xcb_ewmh_connection_t. For
> instance, a window manager managing two displays would simply initialize
> xcb_ewmh_connection_t by calling xcb_ewmh_init_atoms() twice. I think it
> can't be done otherwise, because the Atoms are specific to a display and
> so do xcb_connection_t. That's why xcb_ewmh_connection_t has been
> defined, only to avoid extra parameters such as xcb_connection_t and
> EWMH Atoms in each function of the API.

I'm not talking about different connections. I'm talking about different
screens on the same connection. All the atoms are guaranteed to be the
same in that case, except for _NET_WM_CM_Sn.

> > I'm a little dismayed that xcb_ewmh_init_atoms_replies gets 82
> > copies of four nearly-identical lines of code ...
>
> Hope that's not too ugly[1] ;)

The patch looks good to me, except that I think it's wrong. :-) You're
assigning an XID to a dereferenced pointer of type "char", as far as I
can tell. I think you need one more cast on the left-hand side,
something like this:

*(xcb_atom_t *) ((char *) ewmh + ewmh_atoms[i].m_offset) = reply->atom;

Assuming I'm right, I'd think this bug would be pretty obvious, since at
least in my setup the X server looks like it's allocating more than 256
atoms before the window manager starts.

> That's why I have only defined accessors for _NET_WM_SYNC_REQUEST_COUNTER.

Yes, all your functions are named *_request_counter, but they all use
ewmh->_NET_WM_SYNC_REQUEST. Isn't that wrong?

And the comment header still has that typo of missing a "T". ;-)

> > Do you really want it in the xcb-util bundle though?
>
> Well, I think it's better to keep it within xcb-util.

I'd be interested in hearing your thoughts on the discussion Julien and
I had today on this topic.

> For instance, if all the libraries provided in xcb-util would have
> not been shipped as a bundle, I think they would be in a much worst
> shape, mainly because the original author of the code is rarely the
> maintainer on a long stretch of time. Keeping it as a bundle ensures
> that even if the author does not have time anymore to maintain his
> code, someone else will take over the maintenance and update it when
> necessary (this is what happened with xcb-util/icccm at least).

I think the history of free software contradicts this. For example,
bundling lots of code into libX11 certainly didn't help it be maintained
any better. :-) Conversely, lots of projects abandoned by their original
authors have been picked up by somebody else who needed them, despite
not being bundled with anything else.

> Moreover, xcb-util/icccm and xcb-util/image are already used in
> other projects, but are still parts of xcb-util.

Yes, so are aux, and render-util I think, and awesome is using the
property and event libraries apparently. And yes, I'd like all of those
split out, but just because that hasn't happened doesn't mean we should
add anything more to the mess.

Jamey

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

signature.asc (205 bytes) Download Attachment

Re: XCB Workshop?

2009-12-14T16:16:49Z

Hi,

I would have been happy to come but it would be too expensive for me and
considering that I'm not a core developer at all, I think it would not
make sense to ask for sponsorship. Hope there will be another meeting
nearer ;).

Cheers,
Arnaud
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-14T16:13:38Z

>>>>> "Jamey" == Jamey Sharp <jamey@...> writes:

Hi,

Thanks for reviewing it Jamey.

> Do you really want it in the xcb-util bundle though? Why not
> manage it as its own project? I originally intended xcb-util as a
> collection of sample, proof-of-concept code, more than anything
> else. I'd really like to see somebody split the useful bits out
> into their own repositories. "Useful" is probably best defined as
> "somebody outside of xcb-util is using this," which would mean
> your ewmh bits already don't belong. :-)

Well, I think it's better to keep it within xcb-util. For instance, if
all the libraries provided in xcb-util would have not been shipped as a
bundle, I think they would be in a much worst shape, mainly because the
original author of the code is rarely the maintainer on a long stretch
of time. Keeping it as a bundle ensures that even if the author does not
have time anymore to maintain his code, someone else will take over the
maintenance and update it when necessary (this is what happened with
xcb-util/icccm at least). Moreover, xcb-util/icccm and xcb-util/image
are already used in other projects, but are still parts of
xcb-util.

> This seems like a perfectly sensible implementation of EWMH to me,
> macros and m4 and all. (By all means, do whatever it takes to
> avoid copying and pasting code.) I do have a few minor comments:

> In xcb_ewmh_send_client_message, you probably should check
> data_len before copying data into a fixed-size buffer--unless you
> want to declare that function static and ensure that all the
> callers are safe. If you want to go the latter route you might
> look at the BUILD_BUG_ON macro from include/linux/kernel.h, to get
> a compile-time check.

When adding the following macro:
#define BUILD_BUG_OR_ZERO(e) ((void) (sizeof(struct { int:-!!(e); })))

And the following line before the memcpy:
BUILD_BUG_OR_ZERO((data_len >> 2) > 5);

I get the following error I can't get rid of:
ewmh.c:563: error: bit-field ‘<anonymous>’ width not an integer constant

I'm a bit confused by this macro and does not understand anything
besides of the basic principle. I was thinking about simply adding an
assertion otherwise.

> Also in xcb_ewmh_send_client_message, I'd encourage using memcpy
> instead of a hand-coded loop: It's easier to understand at a
> glance, and GCC will generate better code from it.

Thanks, I have just committed it[0].

> Huh. So an xcb_ewmh_connection_t is only usable on a single
> screen, and you have to pick which one to use when you initialize
> it? I know X's concept of screens is becoming pretty obsolete in
> the RandR era, but if anything still has to deal with multi-screen
> setups it'd be window managers.

Actually, it's the caller who takes care of xcb_ewmh_connection_t. For
instance, a window manager managing two displays would simply initialize
xcb_ewmh_connection_t by calling xcb_ewmh_init_atoms() twice. I think it
can't be done otherwise, because the Atoms are specific to a display and
so do xcb_connection_t. That's why xcb_ewmh_connection_t has been
defined, only to avoid extra parameters such as xcb_connection_t and
EWMH Atoms in each function of the API.

> xcb_ewmh_init_atoms_replies probably should explicitly discard the
> rest of the InternAtom replies if one fails.

> I'm a little dismayed that xcb_ewmh_init_atoms_replies gets 82
> copies of four nearly-identical lines of code, even if they are
> all auto-generated from a bit of m4. I would be inclined to turn
> it into a simple loop, either by casting the address of the first
> atom to (uint32_t *) and treating it as an array, or by including
> offsetof(xcb_ewmh_connection_t, $1) in the internal ewmh_atom_t
> struct.

Hope that's not too ugly[1] ;). Concerning discarding the rest of
InternAtom replies if one fails, I have just requested the remaining
replies anyway.

> The _NET_WM_SYNC_REQUEST section doesn't look right to me, but I
> don't know the EWMH spec well enough to figure out why.

Why doesn't it look right to you?

> At least, the comment header is missing a "T". :-) And
> _NET_WM_SYNC_REQUEST_COUNTER is mentioned only in the comment
> header.

From EWMH specification:

"A client indicates that it is willing to participate in the protocol by
listing _NET_WM_SYNC_REQUEST in the WM_PROTOCOLS property of the client
window and storing the XID of an XSync counter in the property
_NET_WM_SYNC_REQUEST_COUNTER."

That's why I have only defined accessors for _NET_WM_SYNC_REQUEST_COUNTER.
But not for _NET_WM_SYNC_REQUEST (only a ClientMessage function indeed)
as it's listed in WM_PROTOCOLS on a client window, therefore
xcb_set_wm_protocols from xcb-util/icccm should be called for this
Atom. Does it make sense?

Thanks again for your review, it does help a lot.

Cheers,
Arnaud

[0] http://cgit.freedesktop.org/~arnau/xcb-util/commit/?h=xcb-ewmh&id=ff5eae62cee4f13ae4df5f1bb58c62b605c03290
[1] http://cgit.freedesktop.org/~arnau/xcb-util/commit/?h=xcb-ewmh&id=ae4e594200e41f809e07f1133bb04da5e2752ebb
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-14T11:26:56Z

At 1260817099 time_t, Jamey Sharp wrote:
> I'm only complaining about all the libraries being in the same git repo.
> If you want those libraries at git://anongit.freedesktop.org/xcb/libewmh
> or similar, with issues discussed on this list and documentation and
> tarballs at xcb.freedesktop.org, that's fine with me.

Ok, I see your point, and it seems reasonable.
Arnaud, would I also suggest you do not merge and build a libxcb-ewmh?

--
Julien Danjou
// ᐰ <julien@...> http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// In the Sixth Sense, Bruce Willis is dead.

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

signature.asc (205 bytes) Download Attachment

Re: EWMH API for XCB

2009-12-14T11:19:30Z

On Mon, Dec 14, 2009 at 10:58:19AM -0800, Jamey Sharp wrote:

> On Mon, Dec 14, 2009 at 10:14:54AM +0100, Julien Danjou wrote:
> > At 1260732594 time_t, Jamey Sharp wrote:
> > > Do you really want it in the xcb-util bundle though? Why not manage
> > > it as its own project?
> >
> > Not sure it's a good idea to keep things out. We [awesome] use
> > xcb-util heavily, and I spent some time last year rewriting and
> > ehancing many parts of it so it can be useful.
> > Many functions are needed for Xlib users that want to bring XCB to
> > their app/lib, and telling them to go somewhere else where upstream
> > might disapear does not seem like a valuable option right now.
>
> I'm only complaining about all the libraries being in the same git repo.
> If you want those libraries at git://anongit.freedesktop.org/xcb/libewmh
> or similar, with issues discussed on this list and documentation and
> tarballs at xcb.freedesktop.org, that's fine with me.
>
> I'm concerned that keeping everything together makes it harder to have
> healthy competition in library interfaces. I think X client architecture
> has stagnated over the last 20 years because when people had a problem,
> they came up with a quick fix, blessed it by putting it in Xlib, and
> then no matter how much people hated it they couldn't change it. I don't
> want to avoid quick fixes---I want to avoid blessed implementations.

I wouldn't go so far as to think of the bits in xcb-util as somehow
"blessed". (I'd probably call them "special", with all the
meanings thereof. ;) ) Or did you have concerns about putting these
bits in the xcb directory of git repos at all?

But I second Jamey's sentiment: new code should not go in xcb-util, it
should go in its own module. That module can most certainly live in the
xcb directory of git repositories, just in its own repository. xcb-util
really neds splitting into one repo per library. Having more than one
library in a single project makes things painful for many reasons,
particularly with libraries of varying usefulness, completeness, and
API/ABI stability.

- Josh Triplett
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-14T10:58:19Z

On Mon, Dec 14, 2009 at 10:14:54AM +0100, Julien Danjou wrote:

> At 1260732594 time_t, Jamey Sharp wrote:
> > Do you really want it in the xcb-util bundle though? Why not manage
> > it as its own project?
>
> Not sure it's a good idea to keep things out. We [awesome] use
> xcb-util heavily, and I spent some time last year rewriting and
> ehancing many parts of it so it can be useful.
> Many functions are needed for Xlib users that want to bring XCB to
> their app/lib, and telling them to go somewhere else where upstream
> might disapear does not seem like a valuable option right now.

I'm only complaining about all the libraries being in the same git repo.
If you want those libraries at git://anongit.freedesktop.org/xcb/libewmh
or similar, with issues discussed on this list and documentation and
tarballs at xcb.freedesktop.org, that's fine with me.

I'm concerned that keeping everything together makes it harder to have
healthy competition in library interfaces. I think X client architecture
has stagnated over the last 20 years because when people had a problem,
they came up with a quick fix, blessed it by putting it in Xlib, and
then no matter how much people hated it they couldn't change it. I don't
want to avoid quick fixes---I want to avoid blessed implementations.

But I absolutely agree that discouraging people from using XCB would be
bad. :-)

> unless we are blocking developement, which we are not currently, at
> least. :-)

Thank goodness you're better at that than I am. :-)

Jamey

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

signature.asc (205 bytes) Download Attachment

Re: EWMH API for XCB

2009-12-14T01:14:54Z

At 1260732594 time_t, Jamey Sharp wrote:
> Do you really want it in the xcb-util bundle though? Why not manage it
> as its own project? I originally intended xcb-util as a collection of
> sample, proof-of-concept code, more than anything else. I'd really like
> to see somebody split the useful bits out into their own repositories.
> "Useful" is probably best defined as "somebody outside of xcb-util is
> using this," which would mean your ewmh bits already don't belong. :-)

Not sure it's a good idea to keep things out. We [awesome] use xcb-util
heavily, and I spent some time last year rewriting and ehancing many parts
of it so it can be useful.
Many functions are needed for Xlib users that want to bring XCB to
their app/lib, and telling them to go somewhere else where upstream
might disapear does not seem like a valuable option right now. XCB is
not yet a wide deployed library (if you don't count Xlib usage of it).
Having basic bricks managed by the XCB team until many more competents
people come and make things better does not seems a bad idea to me,
unless we are blocking developement, which we are not currently, at
least. :-)

Cheers,
--
Julien Danjou
// ᐰ <julien@...> http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// Trust me.

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

signature.asc (205 bytes) Download Attachment

Re: EWMH API for XCB

2009-12-13T23:58:20Z

In message <20091214050249.GA30448@...> you wrote:

> On Sun, Dec 13, 2009 at 05:50:56PM -0800, Barton C Massey wrote:
> > In message <20091214011643.GA29653@...> you wrote:
> > > These atoms are ones that *aren't* predefined, but are specified by
> > > EWMH (or I think, in a couple of cases, by ICCCM).
> >
> > I understand.
>
> Um... At least one of us doesn't. :-)
>
> > But shouldn't we just use the Python thing on XML instead of the m4
> > thing on, well, m4 to generate the C code anyway, is all I'm saying?
>
> Sure, Arnaud *could* write some Python to generate tiny parts of the C
> source for his library, but it wouldn't bear any resemblance to the
> Python we already have, because these atoms are not specified by the X
> protocol. You have to call InternAtom on them--they don't have constant
> values, unlike the core protocol atoms. Not only would it be all-new
> code, but m4 is much better suited to the way this code is using it than
> Python would be, and XML is a poor choice when this code only needs a
> single list of short strings.

Never mind.

Bart
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-13T21:02:49Z

On Sun, Dec 13, 2009 at 05:50:56PM -0800, Barton C Massey wrote:
> In message <20091214011643.GA29653@...> you wrote:
> > These atoms are ones that *aren't* predefined, but are specified by
> > EWMH (or I think, in a couple of cases, by ICCCM).
>
> I understand.

Um... At least one of us doesn't. :-)

> But shouldn't we just use the Python thing on XML instead of the m4
> thing on, well, m4 to generate the C code anyway, is all I'm saying?

Sure, Arnaud *could* write some Python to generate tiny parts of the C
source for his library, but it wouldn't bear any resemblance to the
Python we already have, because these atoms are not specified by the X
protocol. You have to call InternAtom on them--they don't have constant
values, unlike the core protocol atoms. Not only would it be all-new
code, but m4 is much better suited to the way this code is using it than
Python would be, and XML is a poor choice when this code only needs a
single list of short strings.

Jamey

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

signature.asc (205 bytes) Download Attachment

Re: EWMH API for XCB

2009-12-13T17:50:56Z

In message <20091214011643.GA29653@...> you wrote:

> On Sun, Dec 13, 2009 at 04:41:20PM -0800, Barton C Massey wrote:
> > In message <20091213192954.GA21824@...> you wrote:
> > > This seems like a perfectly sensible implementation of EWMH to me,
> > > macros and m4 and all.
> >
> > I'm quite confused. Didn't someone just add a patch to XCB
> > to get the predefined atoms out of the m4 and into xml where
> > they belong? If so, shouldn't the same approach be taken
> > here? Or am I missing something?
>
> These atoms are ones that *aren't* predefined, but are specified by EWMH
> (or I think, in a couple of cases, by ICCCM).

I understand. But shouldn't we just use the Python thing on
XML instead of the m4 thing on, well, m4 to generate the C
code anyway, is all I'm saying?

Bart
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

Re: EWMH API for XCB

2009-12-13T17:16:43Z

On Sun, Dec 13, 2009 at 04:41:20PM -0800, Barton C Massey wrote:
> In message <20091213192954.GA21824@...> you wrote:
> > This seems like a perfectly sensible implementation of EWMH to me,
> > macros and m4 and all.
>
> I'm quite confused. Didn't someone just add a patch to XCB
> to get the predefined atoms out of the m4 and into xml where
> they belong? If so, shouldn't the same approach be taken
> here? Or am I missing something?

These atoms are ones that *aren't* predefined, but are specified by EWMH
(or I think, in a couple of cases, by ICCCM).

Jamey

_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb

signature.asc (205 bytes) Download Attachment

Re: EWMH API for XCB

2009-12-13T16:41:20Z

In message <20091213192954.GA21824@...> you wrote:
> This seems like a perfectly sensible implementation of EWMH to me,
> macros and m4 and all. (By all means, do whatever it takes to avoid
> copying and pasting code.)

I'm quite confused. Didn't someone just add a patch to XCB
to get the predefined atoms out of the m4 and into xml where
they belong? If so, shouldn't the same approach be taken
here? Or am I missing something?

Bart
_______________________________________________
Xcb mailing list
Xcb@...
http://lists.freedesktop.org/mailman/listinfo/xcb