Re: Plans for 1.3/1.4

[Jeff Garzik <jgarzik pobox com>]

On 27 Feb 1999, Owen Taylor wrote:
> I wanted to get things rolling with planning for the
> 1.3 development series of GTK+ and 1.4.

Along those lines, what are people thinking about Glib 1.3 changes?

I am interested in adding some ADTs, and already have a little bit of
code, stack and queue ADTs, in the GLIB_1_3_HACKS branch.  Below are
rough notes on my ideas.

Comments and suggestions on the APIs of these new ADTs would be greatly
appreciated.

Thanks,

	Jeff






TODO for GLib 1.3:

* alloca support, with replacement if native alloca not available
	- check out gettext's implementation



--------------------------------------------------------------------

Ideas for GLib 1.3:

(jgarzik)
* bug reporting script for glib/gtk.  Expand on gnome-bug and make it
  configure friendly and much smarter.

* better API function coverage by tests

* test subdirectory for regression tests based on bug reports

* wrap i18n routines on various platforms; wrap gettext libintl as a
  fallback.  Main reasoning behind this is that the various libintl
  implementations aren't necessarily compatible.

* benchmark garbage-collecting malloc with Gtk and GNOME apps
  (not for inclusion into GLib, just general knowledge)

* coneill's optimized MD5 checksum routine, maybe some other checksums
  too, encapsulated in a GChecksum.  Allow choice between a few built-in
  checksum functions, MD5, CRC, ?, or a user-specified checksum
  function pointer.

* New ADTs: trie, skip list, red-black tree, queue (below), stack (below)

* decent random numbers (really a portability thing)

* 'make check' tests one per module, plus bug report regression tests
  and such

* primitive memory leak checking by g_malloc, g_free

* alloca-based convenience macros, counterparts to:
	g_new, g_new0, g_strdup, g_strndup, g_strconcat, ???

* GStack, opaque ADT with interface:

	{ see code in GLIB_1_3_HACKS branch }

* GQueue, opaque ADT with interface:

	{ see code in GLIB_1_3_HACKS branch }