Re: User data in GtkText?

[Owen Taylor <otaylor redhat com>]

Thomas Mailund Jensen <mailund@daimi.aau.dk> writes:

>  OT> Hence, I haven't been to agressive about applying patches to it,
>  OT> since the rewrite will probably have a somewhat different API,
>  OT> and anything we add now will either require emulation, or break
>  OT> in the future.
> 
>  OT> I'm not going to have a chance to start on that, until at least
>  OT> after 1.2, however, so it might be worth adding stuff anyways.
> 
> In that case, I would really appreciate adding user data ASAP, since
> it is currently necessary to patch the text widget to use my editor
> widget.  Having to re-write the editor later is OK.  These things
> happens.  Not being compatible with the main branch of widgets is
> something all together different.  Applications using the editor
> widget, as the next version of gIDE I hope, cannot expect people to
> patch their gtk installation.

Well, a modified version of GtkText could be distributed, with
the editor deriving from that. But I agree, that's ugly,

I'm willing to put a user-property-data patch into GtkText, but
I'm not sure I agree with all the details of what you have:

 - TextProperty should not be exposed as all. As mentioned before,
   the internals of GTK+ are going to completely change.

 - Reading members of GTK+ widgets is allowed, writing is not.
   So you'll need a function to set the compare/clone/free
   functions.

 - Your gtk_text_set_property will not work on an unfrozen
   Text widget, because it doesn't handle updating the display,
   and doesn't handle the line-start cache.

   While I'm not sure I would recommend undertaking the amount
   of work that work be necessary to add that, considering
   the fragility of the Text widget, you should at least
   check and do a freeze-thaw around the function if necessary.
 
> As a side note, what is the policy of adding new widgets to CVS?

There is no policy, and some disagreement about the matter.  My
opinion is that GTK+ should only contain widgets that are useful in a
wide range of applications. (A syntax-highlighting editor, for
instance, probably doesn't belong in GTK+ proper ;-). Since GTK+ makes
it easy to have widgets that aren't part of libgtk, I think more
specialized widgets should be distributed separately.

(The only reason I know of for bundling things together, is that
 if you have an interpreter dynamic loading extensions, then unless
 the system has an RTLD_GLOBAL equivalent, separate extensions
 will get separate copies of GTK+. But I don't see this as much of
 an excuse for putting everything into one huge library.)

Regards,
                                        Owen