[pygtk] Trouble with Composited Windows example in gtk.gdk.Window docs

[Neal Holtz]

Thanks very much for the long and informative reply.
It was very helpful.  Just a few more things...

On Saturday 24 May 2008 1:12:32 am Nathaniel Smith wrote:
> bugs here in more detail and file bugs then people would be grateful.
> set_source_pixmap(Pixmap(...)) should not give an error, you should
> file that as a bug already.)

I'll do that over the next day or two ...

> 
> >   2. Why am I still getting the warning about drawing a depth 24 to
> >      a depth 32?
> 
> Dunno.  Guess you've somehow ended up with windows of different
> depths (maybe you explicitly requested that one use a colormap with an
> alpha channel?).

Yes, it appears to be caused by setting the colormap for the event box.
This code in the demo:

    # Set the colourmap for the event box.
    # Must be done before the event box is realised.
    screen = e.get_screen()
    rgba = screen.get_rgba_colormap()
    e.set_colormap(rgba)

Disable that, and the message goes away.  Interestingly enough,
that also improves the visual behaviour of the demo; with it in
there, you don't see any button relief or decoration, just the
label.  With that removed, you do in fact see proper looking buttons
allowing the background window colour to come through, so that
the button does look translucent.  And thats the same for the C
version as well in:

http://library.gnome.org/devel/gdk/unstable/gdk-Windows.html#composited-window-example

i.e., if you remove the colormap setting, you get rid of the depth 24/32
messages and also get what appears to be the desired behaviour (of translucent
buttons).  Unfortunately, I do not yet understand this stuff well enough
to be comfortable filing a bug report about this, but I'll try over
the next couple of days.

> 
> >   3. What is the behaviour of this thing supposed to be?  I don't
> >      think I get it.  When I mouse over the button, the text
> >      disappears.  When I try other mods to the code (i.e., add 2
> >      buttons in an Hbox), I seem to get some random dirt written
> >      by one of the expose handlers.

The dirt was caused by my incorrect usage of Pixmap in an attempt to
fix another problem; see below.  I now seem to get reasonable behaviour.

> 1) Pixmap(window) will not give you what you want -- it creates a
> ...
> and as a workaround you can use
>   cr.set_source_pixmap(window.cairo_create().get_target(), 0, 0)
             "    surface( "

> If you want to make the GTK+ compositing API good, then that'd be
> awesome; if you just want to play with compositing from Python, then
> I gave up and wrote my own API and the code is in 'wimpiggy'
> (http://partiwm.org, look for wimpiggy.composite), and that might be a
> better place to start; if you decide to back away slowly, then I don't
> blame you :-).

I'll look at that, thank you.  But my needs are simple (I think).
Also, I'm a newby to gtk, so this a learning experience..

Long story, probably irrelevant to most:

I use a tablet pc (a Fujitsu lifebook) in my daily lectures.  I really
want to be able to free-hand annotate and make drawings on top of
anything that appears on the screen from any app (and just as often,
to write on a blank screen just as with a clean blackboard). 

Last summer I looked around and for some reason did not find xournal
or find anything I liked, so I wrote my own in Python/PyGTK and used
it quite succesfully for one term. The drawing tool needs to have a 
transparent background and you can simulate that, of course, using 
screen captures as the background, but there is some clumsiness involved 
with that. 

Then I found xournal, and as it has a lot of really nice things that my
Python app didn't, I used it for the next term.  However, its written
in C, :-(, and as I discovered when I added something simple like
a quad-ruled background ("engineering paper"), I really would prefer
not to monkey with C code any more ...

Then when I finally started using a compositing window manager, and
saw how windows could be really transparent, and how changes in underlying
windows are immediately visible, I started thinking about whether to
add this transparency to xournal, or to redo my Python app to integrate
the things I like from both.

(There is a point, and we are almost there ...)

There is limited screen space -- I prefer not to have tool bars
and other junk visible, but rather to have "hot zones" a few pixels wide
near the edge so that when I move the pen into them for .5 sec or so, the tool
bars appear (this was easy in wxWindows but I haven't yet discovered
the pyGTK equivalent).  The idea was to have narrow translucent strips
near the edge that would process mouse-in/out events and set timers 
and react accordingly (and would not react at all if I was drawing 
something at the time).

So, I just want a way to have a truly transparent drawing surface,
and transparent widgets on top of the drawing surface.  And I don't
think I need any of the complex transformations...

And shaped windows might give me a way to interact with the underlying
application, if I can figure out a way to keep the drawing app on top,
even though the underlying app (such as kpdf in presentation mode)
thinks it should also be on top.

Oh, if anyone has got this far ...

I thought you needed a compositing window manager to have this 
window/widget transparency, but from a very brief test of a transparent
window on the normal non-compositing KDE wm, it looks like that sort
of works as well (though you can see the effect of the screen redrawing
on a slow laptop).

thats all...

-- 
Neal Holtz                            http://cee.carleton.ca/~nholtz
Dept. of Civil and Environmental Engineering     Carleton University
Ottawa, Ontario, Canada K1S 5B6.              nholtz at cee.carleton.ca
Key: http://cee.carleton.ca/~nholtz/pubkey.asc