Xcb - Setting the WM_TRANSIENT_FOR property on a window

Hi,
This maybe another silly question but I can't find the equivalent of
XSetTransientForHint in XCB. I found the functions to query it in the
ICCCM module but not to set it. Does XCB have something similar?
Cheers,
Nick

On Sun, Mar 21, 2010 at 5:02 PM, Nicholas Allen wrote:
The xcb function is simply xcb-change-property, for just about
everything in ICCCM and EWMH. Core libxcb is very low level, and
deliberately avoids trying to provide helper functions.
That said, functions for setting WM-TRANSIENT-FOR (and other ICCCM
hints) could be a useful addition to the xcb/util/icccm helper
library. Patches welcome.
Peter Harris

Hi,

I have attached to this email a patch (0001) adding missing setters for
WM-CLASS and WM-TRANSIENT-FOR properties. Like existing setters, all the
parameters are given explicitely rather than using a structure such as
Xlib does. IMO this is much more flexible because it avoids the caller
to declare a structure, fill it and pass them to the callee (most
programs usually have their own data structures).
The second patch adds a format parameter to setters of TEXT property
because the format may be either 8, 16 or 32. As it breaks the ABI, I
have also bumped the version-info.
If nobody complains about these patches, I will commit them to xcb/util
repository.
Arnaud

On Mon, Mar 22, 2010 at 8:19 AM, Arnaud Fontaine wrote:
I see you've used variable length arrays. A few points spring to mind:
- Variable-length arrays are C99. The Microsoft C compilers still
don't support most of C99.
- Variable-length arrays are merely a portable way to spell "alloca".
The server folks have just recently (2007) removed all allocas from
the server. There is no portable way to determine the amount of stack
space available, and alloca rarely returns NULL (and variable-length
arrays can't). This matters less in a client side library, since you
can only DoS yourself.
- Making an extra copy is no fun. XCB uses iovecs to try to avoid
extra copies. You'd have to open-code ChangeProperty to use an iovec,
though, which is ugly. Thoughts?
My comments above are just things I thought of, and not deep
complaints. Feel free to commit if nobody else objects.
Peter Harris

Hi,


As usual, they are far behind concerning standards implementation... I
didn't know that though, thanks!

As C99 is already used in other bits of the library, I think it would be
better to use it when possible rather than relying on non-portable
functions such as alloca(). I am not familiar at all with Windows
programming environment, but maybe someone familiar with that could just
submit a patch to make xcb/util compiles on MS C Compiler using
macros?

Yes, this is not really a good thing... I have no idea how to do it in
another way...
Thanks for the review.
Cheers,
Arnaud

Twas brillig at 14:25:06 22.03.2010 UTC+01 when arnaud@andesi.org did gyre =
and gimble:

AFbe
AFle
AF
The problem is not in non-portable functions. The problem is when you're
out of stack space, you're screwed and have no way to recover because
VLA won't signal stortage of stack space.
=2D-=20
http://fossarchy.blogspot.com/

Mikhail already clarified my point about variable-length arrays.
Thanks, Mikhail.
By "open-code ChangeProperty", I mean copy-and-paste the body of the
generated xcb-change-property function from libxcb, modify it to suit,
and you end up calling xcb-send-request at the end (instead of
xcb-change-property).
Ugly, but it avoids the extra copies. I can see arguments on both
sides of this one. I was just wondering what you thought of the idea.
Peter Harris

Yes, thanks. I didn't know there was no way to recover in such
case... Maybe, it's better to use alloca() then.


Well, I'm thinking about leaving WM-CLASS setter as it is now because
this function is not going to be called so many times usually (therefore
this is not a big overhead) and especially because it's easier to
maintain (for now I do think it's better to focus on maintainability as
this library is not widely used yet). I will leave a comment in the
code quoting what you said though... If performance really matters at
some point, then we will simply use this solution. What do you think?
Might be a silly question which has already been discussed, but why is
iovec needed? I have never had a deep look into core xcb code. Thanks!
Cheers,
Arnaud

On Mon, Mar 22, 2010 at 16:16:27 +0100, Arnaud Fontaine wrote:
alloca() is exactly the same. Just use [cm]alloc(). Or fixed size
arrays. Pretty please.
Cheers,
Julien

On 2010-03-22 11:16, Arnaud Fontaine wrote:
No, alloca is just as bad. Most alloca implementations behave the same
way as variable-length arrays. The server moved from alloca to malloc
wholesale in 2007 because the server devs got tired of fixing alloca
related crashes one at a time.
My point is that alloca by any other name is still just as prone to
stack overflows.
Sounds sensible.
iovec lets you submit many separate buffers as if they were one large
one. It is needed to avoid allocating another buffer and copying into it.
Peter Harris

Yep, after posting this message, I re-read the alloca manpage which says
such thing, sorry ;).

Sorry, my question was not clear. I'm actually wondering why we need to
read/write to multiple buffers in the xcb client library? This may be a
stupid question but I'm currently too tired to figure that out...
Arnaud

On 2010-03-22 11:40, Arnaud Fontaine wrote:
Consider PutImage. The request consists of the protocol header, the
BigReq header, the request body, and a large blob of data supplied by
the user. To send it all in one go, you can:
1) Allocate a new huge buffer, copy over the small protocol headers,
followed by the huge blob of data (flushing the Dcache an extra time,
and possibly going into swap on weak systems).
2) Use multiple separate write() requests (although this doesn't work so
well when you're trying to keep track of the X11 sequence number in
xcb-send-request - you'd need to add an extra flag for "request
continuation" or similar).
3) force the user to allocate larger buffers than strictly needed for
their image, so that libxcb can overwrite the space before the bits.
This interacts poorly with images allocated by 3rd party libraries, and
results in crashes for everyone who didn't read the manual carefully
(it's a really odd interface).
or
4) Just use writev (and percolate the iovec interface back up to
xcb-send-request).
Peter Harris

Hi Jamey,


Sounds a really good idea as it means more flexibility for the caller.
Indeed, for ChangeProperty on -NET-DESKTOP-NAMES in xcb-util/emwh, I let
the caller takes care of preparing a NULL-separated string of the
strings for desktop names itself...
Arnaud

I have attached this patch to this email. Hope that's ok.
Arnaud

I have attached this patch to this email. Hope that's ok.
Arnaud

On 2010-03-24 02:17, Jamey Sharp wrote:
argument we wouldn't have xcb-aux-sync either.
Peter Harris

Hi,
Thanks guy for the review. I will push the patch tomorrow if nobody
complains before.
Besides of these patches, I have also attached to this email a patch
adding WM-COLORMAP-WINDOWS atom (I know that the new type definition is
a bit ugly but this will be merged with xcb-util/ewmh soon), in case it
could be useful to anyone.
I will push all these patches tomorrow I think.
Cheers,
Arnaud

Am Wed, 24 Mar 2010 12:08:06 -0400
schrieb Peter Harris :
Think so, too. I haven't followed the whole discussion, but introducing
functions which only pass some constants as arguments to other
functions only bloats the whole thing and doesn't add any value, IMHO.
Cheers,
Carsten

Am Wed, 24 Mar 2010 12:08:06 -0400
schrieb Peter Harris :
Think so, too. I haven't followed the whole discussion, but introducing
functions which only pass some constants as arguments to other
functions only bloats the whole thing and doesn't add any value, IMHO.
Cheers,
Carsten

Hi,


Yes, it does. However, as a direct user of this library, I don't think
this is a problem. First of all, because it allows greater flexibility
(you can either using heap or stack allocation). Secondly, because all
these one-line functions are supposed to be inline in a near future, so
this won't add any overhead. Thirdly, even if thin, I think this is
still useful as most people wants to have a setter/getter for WM-NAME
for instance as it makes things more readable and providing a library
for that is a good thing IMHO. In addition, the documentation of the
function explains clearly how to use it...
Arnaud