on karmic x64

(this is the screenruler package in fedora)

the problem seems to be the combination of alpha and lack-of-frame. eg:

    window.decorated = false
    window.opacity = 0.85

changing either of those makes it show up.

seems like probably mutter's fault

Created attachment 151944 [details] [review]
Work around Xlib 64-bit "specialness"

When putting 32-bit properties into longs on 64-bit architectures,
XGetWindowProperty assumes the values are supposed to be signed, and
so it sign-extends values greater than 0x7fffffff. So if they *aren't*
supposed to be signed, we need to chop off the high bits ourselves.

(Most CARDINAL-valued properties only end up using small values
anyway, so it doesn't matter, but _NET_WM_WINDOW_OPACITY uses the full
range, and so was previously failing on 64-bit machines.)

Review of attachment 151944 [details] [review]:

Good job tracking this down. Patch looks workable

a) Seems like an /* X treats format=32 items as signed-longs */ comment would be useful in the code
b) Maybe it would be cleaner to just always do this? It's a no-op on 32-bit systems. Or to change the cardinal-list functions to take/return guint32, in which case this isn't necessary.
c) Might be good to file a metacity bug pointing to this

Created attachment 151961 [details] [review]
Work around Xlib 64-bit "specialness"

new version, returning guint32 rather than gulong from cardinal-related
functions. This is actually messier because we have to remarshal an
array of gulong into array of guint32 form, but APIwise it seems more
correct, so...

Review of attachment 151961 [details] [review]:

OK, looking at this, I think I preferred the previous patch. Sorry about that. My reasoning here is that it will just be less confusing if Metacity internally follows the XLib conventions, as screwed up as they are, and uses longs for Window, Cardinal, etc. Reading this, I was worried about the variables that changed type being passed to XChangeProperty(); that doesn't happen, but it could happen in the future.

::: src/core/xprops.c
@@ +274,3 @@
+       */
+      for (i = 0; i < results->n_items; i++)
+        dest[i] = src[i];

C pedanticism for the day - not a C language lawyer, but I believe that GCC is allowed that dest and src don't alias each other (because they have different types, and neither is 'char *'), even though they obviously do. So, it could, rewrite the loop, if it wanted to, to say:

 for (i = 0; i + 4 <= results->n_items; i++)
    {
       dest[0] = src[0];
       dest[2] = src[2];
       dest[1] = src[1];
       dest[3] = src[3];
    }
  while (i < results->n_items)
    {
       dest[i] = src[i];
    }

(Maybe the interleaving optimizes memory access patterns or something...)

I think the correct thing to do is:

  union { gulong[1] src, guint32[1] dest } data = (void *)results->prop;
  for (i = 0; i < results->n_items; i++)
    data.dest[i] = data.src[i];

(or add a typedef to avoid the hacky intermediate (void *) cast.)

If I'm right about this, in one of the few cases where strict-aliasing *would* cause a problem, GCC doesn't warn, despite all the false positives it warns about. Well, anyways, if you go with the first patch, this doesn't matter.

Created attachment 152239 [details] [review]
Work around Xlib 64-bit "specialness"

updated version with comment

Comment on attachment 152239 [details] [review]
Work around Xlib 64-bit "specialness"

Attachment 152239 [details] pushed as 5764176 - Work around Xlib 64-bit "specialness"

reassigning to metacity since the same problem exists there. (with the current set of EWMH properties, it's only noticeable with _NET_WM_WINDOW_OPACITY, but it could potentially cause other problems in the future).

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.