[10340] in The GTK GIMP ToolKit mailing list archive
[gtk-list] Re: ANNOUNCE: GTK+ 1.1.5 Released
daemon@ATHENA.MIT.EDU (Tim Janik)
Mon Nov 23 11:17:18 1998
From: Tim Janik <timj@gtk.org>
Date: Mon, 23 Nov 1998 17:10:34 +0100 (CET)
To: gtk-list@redhat.com
cc: Gtk-- mailing-list <gtkmm@modeemi.cs.tut.fi>
In-Reply-To: <m3ogpyehzm.fsf@linux2.worldnet.fr>
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
On 23 Nov 1998, Guillaume Laurent wrote:
> Tim Janik <timj@gtk.org> writes:
>
> > it will integrate very well, trust me ;)
>
> I don't think so, not in its current form anyway. The problem is that
> we can't call gtk_type_new() directly in Gtk--, because we provide or
> own types (this to override the widget's signals).
>
> So, initially, when you had
>
> gtk_foowidget_new()
> {
> widget = gtk_type_new();
> /*
> * more widget setup code, like setting adjustments etc...
> */
> }
>
> in Gtk-- we had to do
>
> Gtk_FooWidget::Gtk_FooWidget()
> {
> /*
> * duplicate widget setup code
> */
> }
>
> The solution was then to have the widget setup code isolated in a
> seperate, standardly named, function (hence its '_construct()' suffix)
> which we could call from our constructor.
you can do that still, the functions are just named differently/got
split into seperate ones.
> So with the new gtk+ construction mechanism, off the top of my head
> I'd say that we'll just need a gtk_widget_construct() to allow us to
> shunt the call to gtk_type_new().
what would a gtk_widget_construct() do?
> Then again, this is just a quick answer without really looking at the
> new code (I'll do this tonight). There may be other, more elegant
> solutions, or may be the amount of code duplication will be small
> enough to be manageable in the long run (if it's just a couple of
> set_adjustment() here and there, well, we can live with that).
>
> --
> Guillaume.
> http://www.worldnet.fr/~glaurent
>
---
ciaoTJ
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
