public inbox for guile-gtk@sourceware.org
 help / color / mirror / Atom feed
From: Marko Rauhamaa <marko@pacujo.net>
To: guile-gtk@sources.redhat.com
Subject: Re: Completed GdkWindow; enhanced design
Date: Fri, 16 May 2003 22:59:00 -0000	[thread overview]
Message-ID: <m3smrebj4g.fsf@lumo.pacujo.net> (raw)
In-Reply-To: <874r3uplis.fsf@zip.com.au>

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/

  reply	other threads:[~2003-05-16 22:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-15  7:59 Marko Rauhamaa
2003-05-15 23:19 ` Kevin Ryde
2003-05-16  0:58   ` Marko Rauhamaa
2003-05-16  1:23     ` Kevin Ryde
2003-05-16  5:43       ` Marko Rauhamaa
2003-05-16  5:58         ` Marko Rauhamaa
2003-05-16 22:36         ` Kevin Ryde
2003-05-16 22:59           ` Marko Rauhamaa [this message]
2003-05-21 13:20           ` first checkin of gnome-guile in guile-gtk CVS Stan Pinte
2003-08-22 23:56 ` gdk-window-set-geometry-hints Kevin Ryde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3smrebj4g.fsf@lumo.pacujo.net \
    --to=marko@pacujo.net \
    --cc=guile-gtk@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).