Re: Contributing to glib.
- From: Mark Mielke <mark mark mielke cc>
- To: gtk-devel-list gimp org
- Subject: Re: Contributing to glib.
- Date: Tue, 11 Dec 2001 01:08:32 -0500
On Fri, Oct 06, 2000 at 08:48:18AM -0400, Mark Mielke wrote:
> I am willing to write code, provide patches, or whatever the normal
> protocol is for this sort of thing. Using the above example, I believe
> it would desirable to have String objects act similarly to perl strings,
> where the '\0' is kept at the end, but is allowed in the middle as well,
> with the actual size not including the final '\0'. This should be
> compatible with current applications using glib.
I come back to this post of mine, as I find myself wishing I could
make use of GLIB once again. Previously, somebody mentioned that
my requirements are already implemented within GLIB.
I am unable to find these methods that provide for my requirements.
The API documents describes methods such as "g_string_append()",
however, a Z-string is accepted as an argument. There is no mention of
a "appendn" or "append2" function that will accept both a "char *",
and a length.
Is it intended that these functions will ever be added? Are they in
existence, and I am simply not aware of them?
If they do not exist, what form of patch will be accepted to glib, and
what naming convention is preferable for defining these functions? I am
specifically thinking along the lines of: (= is current, + is new)
= GString* g_string_new (const gchar* init);
+ GString* g_string_new_string (const GString*);
+ GString* g_string_new_char (gchar);
+ GString* g_string_new_charp (const gchar*);
+ GString* g_string_new_charpn (const gchar*, gint);
= GString* g_string_assign (GString* lval, const gchar* rval);
+ GString* g_string_assign_string (GString*, const GString*);
+ GString* g_string_assign_char (GString*, gchar);
+ GString* g_string_assign_charp (GString*, const gchar*);
+ GString* g_string_assign_charpn (GString*, const gchar*, gint);
= GString* g_string_append (GString*, const gchar *val);
= GString* g_string_append_c (GString*, gchar c);
+ GString* g_string_append_string (GString*, const GString*);
+ GString* g_string_append_char (GString*, gchar);
+ GString* g_string_append_charp (GString*, const gchar*);
+ GString* g_string_append_charpn (GString*, const gchar*, gint);
= GString* g_string_prepend (GString*, const gchar *val);
= GString* g_string_prepend_c (GString*, gchar c);
+ GString* g_string_prepend_string (GString*, const GString*);
+ GString* g_string_prepend_char (GString*, gchar);
+ GString* g_string_prepend_charp (GString*, const gchar*);
+ GString* g_string_prepend_charpn (GString*, const gchar*, gint);
= GString* g_string_insert (GString*, gint pos, const gchar *val);
= GString* g_string_insert_c (GString*, gint pos, gchar c);
+ GString* g_string_insert_string (GString*, gint, const GString*);
+ GString* g_string_insert_char (GString*, gint, gchar);
+ GString* g_string_insert_charp (GString*, gint, const gchar*);
+ GString* g_string_insert_charpn (GString*, gint, const gchar*, gint);
The old functions would continue to exist, of course, in order to maintain
compatibility, and as convenience methods. The new functions would enhance
existing functionality.
If I author a patch that includes the above functionality, is there a
possibility that it could get into one of the development tracks for GLIB?
mark
--
mark mielke cc/markm ncf ca/markm nortelnetworks com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]