Re: PROPOSAL: revise GLib message system

[Tim Janik <timj gtk org>]

On 7 Aug 1998, Owen Taylor wrote:

> 
> Tim Janik <timj@gtk.org> writes:
> 
> [...]
> 
> > to have warning, error and message handlers be implemented on a
> > per-library basis, i'd like to propose to rename
> > g_error to _g_error
> > g_warning to _g_warning
> > g_message to _g_message
> > 
> > and additionally have
> > void g_glib_error   (const gchar *format, ...);
> > void g_glib_warning (const gchar *format, ...);
> > void g_glib_message (const gchar *format, ...);
> > GErrorFunc   g_set_glib_error_handler   (GErrorFunc   func);
> > GWarningFunc g_set_glib_warning_handler (GWarningFunc func);
> > GPrintFunc   g_set_glib_message_handler (GPrintFunc func);
> > 
> > and then have this in glib.h:
> > 

[...]

> > if we then compile the glib *.c files with -DGLIB_INTERNAL, all the warnings
> > and errors from within glib will be routed through the g_glib_* functions,
> > while the current behaviour is still provided on the application level.

[...]

> > i'm curious to hear peoples comments on this isuue, and will most probably
> > go for the implementation of this in gtk, gdk and glib after a few days if
> > no one stands up and objects ;)
> 
> Objection, your honor!
> 
> I think defining g_warning (etc.) to do different things in different
> places, is evil preprocessor magic, and should be avoided. All
> the unprefixed g_* should be left to behave as is. (On the surface).

well, i partly agree with you here.

> Then, add:
> 
>  g_info (GQuark who, GSeverity severity, message, ...)
>  g_infov (GQuark who, GSeverity severity, message, va_list args)
>  g_info_set_handler (GQuark who, GSeverity severity, GInfoHandler handler);
> 
> [ Maybe make GSeverity a flags field so the same handler could
>   handle a set of warning? ]
> 
> On GCC, we can #define gtk_warning appropriately on systems without
> varargs macros, it needs to be a wrapper function (or we can make it
> an inline function) - in any case, we write:
> 
>  gtk_warning ("unable to register error handler")
> 
> and even
>   
>  gtk_return_if_fail (x != 0);
> 
> (The biggest CVS commit ever?)

this is exactly what i wanted to avoid with my approach.

> Even if people decide they _really_ want to have g_warning magically
> do different things in different source files, I do think we should do
> something like the g_info() scheme internally, so every library and
> every application doesn't have to duplicate all the handlers.
> 
> [ 
>  Automagical macros really need to be in uppercase - to at least
>  let the user know something odd is going on.

wouldn't this hold for the g_return_*if_fail macros as well? at least
to some extend?

>  #ifndef G_MODULE 
>  #define G_MODULE G
>  #endif
> 
>  #define G_WARNING G_MODULE##_warning
> 
>  gcc -DG_MODULE=gtk foo.c
> 
>  would be better. (Though sprinkling the source code with
> 
>  G_RETURN_VAL_IF_FAIL (x != NULL, FALSE);
> 
>  will make the source code much less pretty.
> ]

i'd say both of us offer viable approaches (from a technical side at least)
about the library-specific message handlers. i even considered something like
your g_info() stuff as well (it provides more flexibility and is also cleaner
technically), but wanted to avoid the extra overhead involved for non-gcc
systems.
i guess we need to decide if we want all libraries to use g_warning(), or
want all of them to introduce their own gtk_warning(), gdk_warning(),
gnome_warning(), gnomeui_warning() and gle_warning() equivalents.
if we go for the latter, it seems questionable for applications to still
use g_warning() and not myapp_warning(). also we will then need something
like glib_warning() to be used inside of glib itself (though that would
be a minor problem).

honestly, i don't know what would be the best solution, and most importantly,
the most convenient for programmers who use glib.
maybe we should even vote on this subject amongst the core developers of
involved projects?

> 
> 
> Regards,
>                                         Owen
> 

---
ciaoTJ