Re: [gtk-list] Re: ANNOUNCE: GTK+ 1.1.5 Released
- From: Tim Janik <timj gtk org>
- To: gtk-list redhat com
- cc: Gtk-- mailing-list <gtkmm modeemi cs tut fi>
- Subject: Re: [gtk-list] Re: ANNOUNCE: GTK+ 1.1.5 Released
- Date: Mon, 23 Nov 1998 17:10:34 +0100 (CET)
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
[
Date Prev][
Date Next]   [
Thread Prev][
Thread Next]   
[
Thread Index]
[
Date Index]
[
Author Index]