Re: GdkColormap -> GObject
- From: Tim Janik <timj gtk org>
- To: Havoc Pennington <hp redhat com>
- Cc: gtk-devel-list gnome org
- Subject: Re: GdkColormap -> GObject
- Date: Thu, 18 May 2000 05:16:34 +0200 (CEST)
On 16 May 2000, Havoc Pennington wrote:
>
> Hi,
>
> Thanks, I'll make all those changes.
>
> The lack of a real GdkColormap makes me nervous too; here are some of
> the issues:
>
> - gdk_colormap_new() has to return a GdkXColormap or
> GdkWin32Colormap, to keep backward compatibility
>
> - right now all the colormap operations are not virtual, so we'd
> need to add a ton of functions to the class struct, but it
> isn't really useful for users to override any of these
>
> These same issues apply to GdkDragContext and GdkImage. GdkGC is
> already fully virtualized, and Owen and I decided that GdkDrawable
> must be fully virtualized for things to work (right now it has some
> member variables).
>
> One idea is to have a G_TYPE_NO_DERIVATION flag, which would allow
> glib to issue a warning if you try to subclass these types.
> This might be a stupid hack, I don't know.
>
> GdkFont is still sort of up in the air, Owen has to do Pango
> integration, so I'm going to ignore it for now.
>
> Window/Pixmap are a big mess because the names for the objects are
> already taken (GdkWindow must remain a GdkDrawable typedef,
> GdkWindowClass is an enumeration, etc.). So I have
> GdkWindowObject/GdkWindowObjectClass at the moment.
that's breaking with the naming conventions for API/objects,
and will just be extremely confusing long term.
GdkWindowClass can simply be renamed, it's not widely used
anyways.
gdk_drawable_alloc() needs to vanish though, and
gdk_drawable_get_type() should prolly be renamed.
so we basically get:
struct _GdkWindowClass
{
GObjectClass parent_class;
void (*construct) (GdkWindowAttr *attributes,
guint attributes_mask);
/* put GdkDrawableClass functions here */
};
struct _GdkWindow
{
GObject parent_instance;
};
typedef GdkWindow GdkDrawable;
typedef GdkWindowClass GdkDrawableClass;
with the existing API, that'll mostly preserve source
compatibility.
the x11/win32/nanox ports can then introduce
GdkWindow derived types GdkWindowX11, GdkWindowWin32,
GdkWindowNanoX (and some for pixmaps/bitmaps) and
just need to care about setting up the root window.
gdk_window_new () will then create window objects from
the type id of the parent window passed in (NULL for
root window).
disclaimer, i only looked into this very briefly, so if i'm
missing some clashes, please point them out.
>
> Havoc
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]