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