public inbox for guile-gtk@sourceware.org
 help / color / mirror / Atom feed
* Completed GdkWindow; enhanced design
@ 2003-05-15  7:59 Marko Rauhamaa
  2003-05-15 23:19 ` Kevin Ryde
  2003-08-22 23:56 ` gdk-window-set-geometry-hints Kevin Ryde
  0 siblings, 2 replies; 10+ messages in thread
From: Marko Rauhamaa @ 2003-05-15  7:59 UTC (permalink / raw)
  To: guile-gtk


I completed the GdkWindow functions. To implement user_data and filter
callbacks (while protecting them from GC), I added the boxed_mark ()
function to participate in the GC mark phase. Accordingly, I added a
'mark option to define-boxed and define-struct.

The GdkWindow user_data design is as follows:

   The GdkWindow user_data is either NULL (initially) or an SCM list.
   The first element of the list is the SCM user data (or #f). The
   remainder of the list consists of filter procedures.

You will see that gdk_window_mark will simply return its user_data to
protect it against GC.


Marko

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Completed GdkWindow; enhanced design
  2003-05-15  7:59 Completed GdkWindow; enhanced design Marko Rauhamaa
@ 2003-05-15 23:19 ` Kevin Ryde
  2003-05-16  0:58   ` Marko Rauhamaa
  2003-08-22 23:56 ` gdk-window-set-geometry-hints Kevin Ryde
  1 sibling, 1 reply; 10+ messages in thread
From: Kevin Ryde @ 2003-05-15 23:19 UTC (permalink / raw)
  To: Marko Rauhamaa; +Cc: guile-gtk

Marko Rauhamaa <marko@pacujo.net> writes:
>
>    The GdkWindow user_data is either NULL (initially) or an SCM list.
>    The first element of the list is the SCM user data (or #f). The
>    remainder of the list consists of filter procedures.
>
> You will see that gdk_window_mark will simply return its user_data to
> protect it against GC.

Are you aware that gtk stores a widget (pointer) in the GdkWindow
user_data?  So for instance you can't assume a window obtained from
gtk_widget_window will have an SCM in the user_data field.

The gtk 2 docs suggest one should store only NULL or a widget, because
the gtk event handler will expect that.  The gtk 1.2 code looks like
gtk_main_do_event and gtk_get_event_widget don't attempt any
validation.

(Presumably this issue must have shown up when you tested your
changes, so I wonder if I've badly missed something.)

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Completed GdkWindow; enhanced design
  2003-05-15 23:19 ` Kevin Ryde
@ 2003-05-16  0:58   ` Marko Rauhamaa
  2003-05-16  1:23     ` Kevin Ryde
  0 siblings, 1 reply; 10+ messages in thread
From: Marko Rauhamaa @ 2003-05-16  0:58 UTC (permalink / raw)
  To: guile-gtk

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

> Marko Rauhamaa <marko@pacujo.net> writes:
> >
> >    The GdkWindow user_data is either NULL (initially) or an SCM
> >    list. The first element of the list is the SCM user data (or #f).
> >    The remainder of the list consists of filter procedures.
> >
> > You will see that gdk_window_mark will simply return its user_data
> > to protect it against GC.
> 
> Are you aware that gtk stores a widget (pointer) in the GdkWindow
> puser_data? So for instance you can't assume a window obtained from
> gtk_widget_window will have an SCM in the user_data field.

I wasn't aware of that. The GDK 1.2 specification doesn't make its usual
comment about GTK reserving the user_data facility for itself.

Now what are the consequences? First, it probably doesn't make sense to
even provide the user access to user_data. But the other casualty would
be the filter procedures that can be registered for the window. Let me
make a wild guess and assume that GTK reserves the filtering mechanism
for itself as well?

If we dropped user_data and filtering support from GDK, the whole
marking/user_data mechanism becomes unneeded.

> (Presumably this issue must have shown up when you tested your
> changes, so I wonder if I've badly missed something.)

As I stated before, I'm first writing the code and just making sure it
compiles. Once I'm done writing the code, I'll start testing it.


Marko

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Completed GdkWindow; enhanced design
  2003-05-16  0:58   ` Marko Rauhamaa
@ 2003-05-16  1:23     ` Kevin Ryde
  2003-05-16  5:43       ` Marko Rauhamaa
  0 siblings, 1 reply; 10+ messages in thread
From: Kevin Ryde @ 2003-05-16  1:23 UTC (permalink / raw)
  To: Marko Rauhamaa; +Cc: guile-gtk

Marko Rauhamaa <marko@pacujo.net> writes:
>
> But the other casualty would
> be the filter procedures that can be registered for the window.

gdk_window_add_filter and friends are not related to the window
user_data are they?

> As I stated before, I'm first writing the code and just making sure it
> compiles. Once I'm done writing the code, I'll start testing it.

Nobody minds a bug or two in the latest cvs, but you really ought to
at least give new code a run before committing it.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Completed GdkWindow; enhanced design
  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
  0 siblings, 2 replies; 10+ messages in thread
From: Marko Rauhamaa @ 2003-05-16  5:43 UTC (permalink / raw)
  To: guile-gtk

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

> Marko Rauhamaa <marko@pacujo.net> writes:
> >
> > But the other casualty would be the filter procedures that can be
> > registered for the window.
> 
> gdk_window_add_filter and friends are not related to the window
> user_data are they?

Well, just like GTK widgets are not related to user_data.

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

> Nobody minds a bug or two in the latest cvs, but you really ought to
> at least give new code a run before committing it.

I've tried to be mindful of the process as laid out for me by Marius.
("Hack on!", "Make sure it compiles.")

The bulk of my changes are new code that shouldn't have an impact to
existing code (that user_data-GTK connection was news to me).


Marko

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Completed GdkWindow; enhanced design
  2003-05-16  5:43       ` Marko Rauhamaa
@ 2003-05-16  5:58         ` Marko Rauhamaa
  2003-05-16 22:36         ` Kevin Ryde
  1 sibling, 0 replies; 10+ messages in thread
From: Marko Rauhamaa @ 2003-05-16  5:58 UTC (permalink / raw)
  To: guile-gtk

Marko Rauhamaa <marko@pacujo.net>:

> Kevin Ryde <user42@zip.com.au>:
> 
> > Marko Rauhamaa <marko@pacujo.net> writes:
> > >
> > > But the other casualty would be the filter procedures that can be
> > > registered for the window.
> > 
> > gdk_window_add_filter and friends are not related to the window
> > user_data are they?
> 
> Well, just like GTK widgets are not related to user_data.
> 
> 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).

I have now backed out the mark option as well as the user_data and
window filter functions as infeasible and unneeded.


Marko

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Completed GdkWindow; enhanced design
  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
  2003-05-21 13:20           ` first checkin of gnome-guile in guile-gtk CVS Stan Pinte
  1 sibling, 2 replies; 10+ messages in thread
From: Kevin Ryde @ 2003-05-16 22:36 UTC (permalink / raw)
  To: Marko Rauhamaa; +Cc: guile-gtk

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.

I'd thought at one stage of proposing an equal? handler for the boxed
types as a similar thing, but ended up doing what I wanted a different
way.

gdkfont has it's own equal function, gdkcolor doesn't need one (on the
pointer value), and gdkcursor seems not unique at the gtk level, so it
was only gdkwindow I was looking at.

> I've tried to be mindful of the process as laid out for me by Marius.
> ("Hack on!", "Make sure it compiles.")

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Completed GdkWindow; enhanced design
  2003-05-16 22:36         ` Kevin Ryde
@ 2003-05-16 22:59           ` Marko Rauhamaa
  2003-05-21 13:20           ` first checkin of gnome-guile in guile-gtk CVS Stan Pinte
  1 sibling, 0 replies; 10+ messages in thread
From: Marko Rauhamaa @ 2003-05-16 22:59 UTC (permalink / raw)
  To: guile-gtk

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/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* first checkin of gnome-guile in guile-gtk CVS
  2003-05-16 22:36         ` Kevin Ryde
  2003-05-16 22:59           ` Marko Rauhamaa
@ 2003-05-21 13:20           ` Stan Pinte
  1 sibling, 0 replies; 10+ messages in thread
From: Stan Pinte @ 2003-05-21 13:20 UTC (permalink / raw)
  To: guile-gtk

hello,

I finally succeeded to check something correct in.

I apologize in advance for all the maintenance troubles that I am causing, but I am eager to learn, so I am open for comments!

I created a new directory, called 

http://savannah.nongnu.org/cgi-bin/viewcvs/guile-gtk/gnome-guile-0.1/

It still needs working before it compiles, but I will work on it the next days. 

Basically, The work that needs to be done is to make gnome-guile compile on its own, without the guile-gtk sources into its tree. (using an installed version of guile-gtk instead).

A small question:

I made by mistake a

http://savannah.nongnu.org/cgi-bin/viewcvs/guile-gtk/gnome-guile/ directory full of garbage...so don't worry, I'll post a mail to the admin to have that cleaned.

Stan.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* gdk-window-set-geometry-hints
  2003-05-15  7:59 Completed GdkWindow; enhanced design Marko Rauhamaa
  2003-05-15 23:19 ` Kevin Ryde
@ 2003-08-22 23:56 ` Kevin Ryde
  1 sibling, 0 replies; 10+ messages in thread
From: Kevin Ryde @ 2003-08-22 23:56 UTC (permalink / raw)
  To: guile-gtk

I think gdk-window-set-geometry-hints could be better done with
keywords a bit like gdk-window-new than with a long list of arguments,
and GdkWindowHints flags to say which are actually relevant.

The same would apply to the corresponding gtk level function
gtk-window-set-geometry-hints.  These two are the only users of
GdkGeometry + GdkWindowHints, so I guess there's no great need to wrap
GdkGeometry separately.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2003-08-22 23:56 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-15  7:59 Completed GdkWindow; enhanced design 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
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

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