Re: RGBA Colormaps in GtkWindow

[Owen Taylor <otaylor redhat com>]

On Fri, 2008-05-30 at 18:33 +0200, Giuseppe Fuggiano wrote:
> Hi all,
> 
> I am working on a patch to make GtkWindow to use an RGBA colormap, in
> order to add trasparency to each GTK+ application to make possible doing
> fancy things by themers and artists, but not only [0].
> 
> Actually, after some tests we discovered that not all applications are
> really ready for this change.
> 
> If an application uses a tray icon like XChat or Pidgin, it crashes
> because of an Xorg badmatch.
> 
> Months ago, Ryan "desrt" Lortie proposed some new specs for tray icon,
> that was accepted [1], but not implemented yet.
> 
> Also, some developers would like to have an xsetting to control the
> colormap, some others (like Owen Taylor) would like an environment variable.
> 
> I'd like to understand better the tray icon issue to try to fix it. Is
> there anyone could help me in that sense?

I think this issue is both a lot simpler and a lot harder than you are
making out:

 - The status icon issue is *only* an issue between GtkStatusIcon, 
   the tray icon protocol, and gnome-panel. It:

    - it can be worked around in the gnome-panel by creating a wrapper
      window if it detects an icon with a non-matching visual
    - it can be avoided  by simplying making the window for
      GtkStatusIcon never use a RGBA window independent of your setting.
    - it can be fixed properly by extending the tray icon protocol 
      to declare whether the tray wants RGBA icons or not. Ryan's
      proposal is workable, though I would do it a little differently - 
      put the visual (or colormap) ID in a property.

  - Once you fix the GtkStatusIcon issue, you need to test a wide
    variety of apps (especially less native ones like Firefox, 
    Adobe reader, etc.) to make sure that using an RGBA visual doesn't
    cause other sorts of crashes or misbehavior.

    If it does cause crashes, you need to investigate those crashes.
    If they can't be worked around, then we'd need to make apps declare
    window-by-window that an RGBA visual is OK - a rgba-ok property
    on GtkWindow, so to speak.

  - If the tests are successful, at then point, what you would need
    to do is add a *style property* for GtkWindow that says that 
    the theme wants an RGBA window.

    Despite the theme wanting an RGBA window, it might not get it - 
    you can only use RGBA windows if a compositing manager is running.

  - You'll need to extend GDK to give notification when a compositing
    manager starts or stops .. something GDK doesn't have currently
    as far as I know.

  - Now you have another issue to deal with: if a compositing manager
    stops or starts or the theme changes, then you might have to change
    a GtkWindow on the fly from RGBA to non-RGBA. This means unrealizing
    it and realizing it again. You need to do another around of testing
    similar to the round above to make sure that this won't cause
    problems for applications.

    In particular for this, you would want to test out applications that
    embed OpenGL or Xvideo within then.

    If there are problems, then again, you would need a GtkWindow
    property (unrealize-ok) to declare that it is safe to unrealize
    and realize the window again.
 
That's basically the program that would need to be followed. Fooling
around with environment variables or XSETTINGS is pointless.

- Owen