Re: GdkError !!

[Havoc Pennington <hp redhat com>]

Paul Barton-Davis <pbd Op Net> writes:
> 
> except:
> 
> 	% ls .../pixmaps
> 	  <lots of files ending with .xpm>
> 
> no good reason to convert them either, if you ask me.
>

You don't need to convert the xpm's, just load them into pixbufs not
pixmaps. We're talking about newly-written code here, right?  The
recommended way to write new code with 2.0 is to load into a pixbuf.

If you want to have a pixmap, then the way to do that is to load into
a pixbuf, then create a pixmap from the pixbuf using either
gdk_pixmap_colormap_new_from_pixbuf or gdk_pixbuf_render_to_drawable.
(pixmap_colormap_new_from_pixbuf being a convenience wrapper around
the latter function). Anyhow, sort of beside the point, I'm just
saying that the pixmap_from_xpm() things are not really useful
anymore. pixbuf_new_from_file() or pixbuf_new_from_xpm_data() would be
better. new_from_file() has the advantage that you can change the
on-disk format of the image without even recompiling your app.

> i guess i feel that if its possible to create server-side images
> without an explicit window (and it clearly is), then there is no
> reason to ever require one.
> 

The window isn't required; the colormap is required. Otherwise you
can't map from the colors in the XPM or pixbuf into a pixmap.  The
window is simply used to get a colormap. A colormap in 2.0 has the
visual attached to it, the depth of the visual is needed to create the
pixmap.

Of course in GTK 2.0 there's almost no reason to use a non-default
colormap or allocate colors in a colormap because the default colormap
has an RGB color cube already allocated; colormap support is mostly
for legacy reasons.

We added gdk_gc_set_rgb_fg_color() and gdk_gc_set_rgb_bg_color()
specifically so you can just forget about colormaps and color
allocation. Of course everyone will try using the more
intuitively-named set_foreground() first, which is unfortunate, but we
can't break old code that assumes the color going into
set_foreground() is already allocated.

The interface could use some work; it might be nice if
gdk_pixmap_colormap_new_from_pixbuf() and the XPM functions would
accept a NULL colormap and fall back to the default colormap. For
people who don't know or care about colormaps, this would always work
properly, since all widgets are using the default colormap.

It's possible we should have variants of all functions that take a
colormap that don't take a colormap,
e.g. gdk_pixmap_new_from_pixbuf(), so we can phase out colormaps over
time.

Anyhow, I think 2.0 is a lot better in this respect, it does allow you
to ignore colormaps, but the interfaces could use some work to be
coherent in the new scheme while still supporting legacy apps.

Havoc