Re: GdkColormap -> GObject

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
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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]