Re: User data in GtkText?



>>>>> "O" == Owen Taylor <otaylor@redhat.com> writes:

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

Well, that is the problem...

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

I'm willing to change the implementation, as long as the feature
remains:)

I will modify my implementation today, and upload the patch for you to
see.

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

I assume you are referring to

typedef struct _GtkTextProperty   GtkTextProperty;

and

void       gtk_text_set_property_data (GtkTextProperty  *prop,
				       gpointer          user_data);
gpointer   gtk_text_get_property_data (GtkTextProperty  *prop);
guint      gtk_text_get_property_length (GtkTextProperty  *prop);

in gtktext.h?

I could change the functions to take a position (gint pos) as argument
instead of a text property.  Then they refer to the text property at
that position.  And perhaps I should add functions to read the
property font, fore and back data while I'm at it.

The font, fore, and back data will remain after the changes, right?
If the length property is removed I'll have to deal with this at that time.

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

I'll add such functions.

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

 O>    While I'm not sure I would recommend undertaking the amount of
 O> work that work be necessary to add that, considering the fragility
 O> of the Text widget, you should at least check and do a freeze-thaw
 O> around the function if necessary.
 
I'll do that.

 >> As a side note, what is the policy of adding new widgets to CVS?

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

Fair enough.

/mailund



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]