Re: subclassing GtkText

[Havoc Pennington <hp redhat com>]

Thomas Mailund <mailund@mail1.stofanet.dk> writes: 
>  H> If you have CVS access,
> 
> I don't.
>

OK I can apply it to the tktext-port module if you're using that
module, but it sounds like you aren't.
 
>  H> it's OK to apply that patch to tktext-port, but the patch is
>  H> broken long-term so I don't want to apply it to the canonical
>  H> version of the widget in CVS HEAD.
> 
> What's wrong with it?  It simply moves the body of `new' to a function
> `construct' so subclasses can initialize the "text" part.  Are there
> other plans for such initialization?
> 

Yes, a CONSTRUCT_ONLY object argument is the correct way to do it.
However object arguments are sort of up in the air right now, so, I'm
not implementing it immediately.

Another option is to have btree autocreate a tag table lazily, i.e. 
change all references to tree->table into an accessor function, the
accessor function then creates the table if none exists.

Probably best to do both of these.

>  H> Before using tktext-port too extensively, keep in mind that it is
>  H> not the canonical widget and due to lack of Pango is fundamentally
>  H> broken for i18n (it only works for Latin1 languages). There are
>  H> also some source-incompatible changes in the GTK+ version, though
>  H> the basic structure of the widget is the same.
> 
> Which widget are we talking about here?  The patch was for the
> gtktextbuffer.[hc] from gtk+/gtk in CVS.  I thought that was the
> canonical version.
> 

The canonical version is the one in gtk+/gtk, yes. I thought you were
probably using the one in tktext-port, which is the old version.

Havoc