Re: PROPOSAL: revise GLib message system

[Tim Janik <timj gtk org>]

On Sat, 8 Aug 1998, Tim Janik wrote:

> On 7 Aug 1998, Owen Taylor wrote:
> 
> > 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).
> > 
> > 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? ]
> 
> you could just use multiple calls for such cases, e.g.
> typedef enum
> {
>   G_SEVERITY_FATAL,
>   G_SEVERITY_WARNING,
>   G_SEVERITY_INFO,
>   G_SEVERITY_DEBUG
> } GSeverityType;
> 
> g_info_set_handler (gtk_quark, G_SEVERITY_FATAL, gtk_info_handler_abort);
> g_info_set_handler (gtk_quark, G_SEVERITY_CRITICAL, gtk_info_handler_continue);
> g_info_set_handler (gtk_quark, G_SEVERITY_WARNING, gtk_info_handler_continue);
> g_info_set_handler (gtk_quark, G_SEVERITY_INFO, gtk_info_handler_continue);
> g_info_set_handler (gtk_quark, G_SEVERITY_DEBUG, gtk_info_handler_continue);
> 
> but i'd prefer to use g_logger instead of g_info. g_info could be needed
> as a fucntion name later on, and g_logger does express the purpose better.
> it wouldn't for instance be unreasonable if we later feature a comandline
> option, that's going to let the default message handlers log into a
> file or somesuch.
> 
> > 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?)
> 
> hm, i really like the idea of having the same function/macro name for each
> library, so that gtk, gdk, gnome *and* the application all use
> G_WARNING and G_RETURN_IF_FAIL (or g_warning and g_return_if_fail).
> 
> but for the sake of incresed readability i think we should really supply
> lower case variants of those macros, even if that means we need to make
> an exeption to the macros-are-in-upper-case rule.
> we already didn't follow that for the existing g_return_* macros.
> 
> e.g. if we have:
> 
> void g_logger (GQuark        who_quark,
>                GSeverityType severity,
>                const gchar  *format,
>                ...);
> 
> #define G_ERROR(fmt, args...) g_logger (G_LOGGER_QUARK, G_SEVERITY_FATAL, fmt, ##args)
> #define G_WARNING(fmt, args...) g_logger (G_LOGGER_QUARK, G_SEVERITY_WARNING, fmt, ##args)
> #define G_MESSAGE(fmt, args...) g_logger (G_LOGGER_QUARK, G_SEVERITY_INFO, fmt, ##args)
> 
> #ifndef G_LOGGER_QUARK
> #define G_LOGGER_QUARK        (0)
> #endif  /* G_LOGGER_QUARK */
> 
> and compile gtk files with -DG_LOGGER_QUARK=gtk_quark, the exception would
> be a few additional defines in glib.h:
> #define	g_warning	G_WARNING
> #define	g_error		G_ERROR
> #define	g_message	G_MESSAGE
> 
> with the sole purpose of increased readability.
> on non-gcc systems, G_WARNING, G_ERROR and G_MESSAGE are even going
> to be *real* functions (inlined), so we could just give them lower
> case names in the first place...
> 
> extern GQuark gtk_quark; would need to be initialized at the beginning of
> gtk_init(), but do we really want quarks in this place? we can just as well
> export const gchar *gtk_logger_domain = "Gtk", and use
> -DG_LOGGER_DOMAIN=gtk_logger_domain. (this comes pretty close to the usual
> -DPRG_NAME= or -DLIBRARY_NAME= that is used in many projects).
> 
> basically, g_warning and friends stay the same for the application programmer,
> but for libraries like gtk or gdk, their specific behaviour can be tweaked
> through a -DG_LOGGER_QUARK=something switch, i don't consider that inherently
> evil...
> 
> > 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.
> > 
> >  #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.
> > ]

since i'd like to get into actuall implementation of the above stuff,
do people still have strong objections about enhancing g_warning() and
friends with a special per-library define of -DG_LOGGER_DOMAIN="somestring"?
owen, i'm especially wondering whether you still insist on the G_WARNING
indirection.

> > 
> > Regards,
> >                                         Owen
> > 


BTW: i have commited the GModule wrapper code to glib now. the dlopen()
     implementation works farely well so far, and the HP-UX code should
     only need minor adaptions if any. unfortunately i can't test that...
     i'd like to get this stuff going on as many systems as possible, and
     i have sample implementations for AIX, Next, Windows and probably
     else systems laying around (the Dynaloader of Perl does a fair job wrt
     support of different platforms). it's just a matter of someone giving
     me a hand on system specific implementations, or supplying me with
     a temporary account on systems that don't use dl* or shl_* stuff
     (though getting this to work under windows just requires me to
     erase one of my harddisks and install that <zensored> OS on it ;( ).
     feel free to proof-read, check and flame about the stuff that's
     hiding in glib/gmodule now ;)
     owen, could you give me some input on how to integrate that
     gmodule stuff with the AM_PATH_GLIB macro? i guess the best thing
     to do is to provide AM_PATH_GMODULE (in glib.m4), which uses
     AM_PATH_GLIB internally and then provides GMODULE_CFLAGS and
     GMODULE_LIBS (and probably GMODULE_LDFLAGS for systems that need
     stuff like e.g. -rdynamic) on top of that...
     
---
ciaoTJ