Re: Completed GdkWindow; enhanced design

[Marko Rauhamaa <marko at pacujo dot net>]

Kevin Ryde <user42@zip.com.au>:

> Marko Rauhamaa <marko@pacujo.net> writes:
> >
> > The filters need to be protected from GC while they are referred to
> > by a GdkWindow. I use user_data to keep track of the filter
> > procedures (as well as SCM user data).
> 
> Presumably something like the widget signals would be wanted. It'd be
> a happy side effect if it meant each distinct gtkwindow was a unique
> scheme level object. Good for hashing, comparing, etc.

Ideally all GDK objects would have a one-to-one mapping to a smob. In
fact, a few days ago I thought that was the case. But to implement such
a nice design, you need the GDK object to provide a user_data pointer.
Or you need a callback to tell you when the object's reference count
comes down to zero. Since we don't have such mechanisms, we can't link
smobs to GDK objects -- we must grant such smobs an eternal life.

> I doubt that's to be taken literally, not if anyone is meant to be
> looking at the code. I'm not trying to be critical, just that it'll be
> highly advantageous to others interested in the project if you can
> better communicate changes you're proposing.

I am being very public on this mailing list about my doings. When
problems arise, I can react quickly. However, it seems I can't first
propose plans and then wait for feedback since barely anybody
participates in the dialog (you're the only one), and the latency is in
the order of several days.

The reason I'm submitting changes before properly unit-testing them is
twofold:

  1. CVS (unlike Sun's Teamware and, I suppose, Bitkeeper) doesn't
     distinguish between local checkins and global submissions. I want
     to be able to register my changes under version control ASAP so I
     don't lose them if I need to backtrack. I guess I could familiarize
     myself with CVS branching to implement a similar thing.

  2. Lack of ownership. The longer I keep my changes to myself, the
     wider the gap between the mainstream view and my own view will
     become. Conflicts may become very painful to resolve if the changes
     are only merged after several weeks. If only one person at a time
     was working on any given file, conflicts wouldn't a problem.


Marko

-- 
Marko Rauhamaa      mailto:marko@pacujo.net     http://pacujo.net/marko/