Autarch <[EMAIL PROTECTED]> writes:
>On Mon, 7 Feb 2000, Nick Ing-Simmons wrote:
>
>> Can you give an outline of what Log::Dispatch does?
>
>I'll summarize since I'm the author.
>
>Log::Dispatch has two parts. The first is the dispatch object, which
>takes messages and levels (i.e. error, criticial, warning) and passes them
>to all of its internally held logging objects (which are all subclasses of
>Log::Dispatch::Output. These include Log::Dispatch::File,
>Log::Dispatch::Screen (really STDOUT or STDERR), etc.). The idea here is
>that you create a dispatcher and any number of logging objects and then
>you pass the messages to the dispatcher, meaning there is a single point
>of entry for logging to multiple places (each of the logging objects
>chooses whether or not to act upon the information based on the log
>level).
>
>What Dominique is proposing is a new subclass of Log::Dispatch::Output
>that displays messages in a text box. Since she would like it to be part
>of the Tk::* hierarchy, that creates some interesting namespace issues.
>
>Really, it is part of the Log::Dispatch suite, so perhaps the name should
>be Log::Dispatch::TkWindow or something like that.
That sounds right to me (say) Log::Dispatch::TkText to allow
other types of Tk widget to be added later (now I know what it is
I can imagine a Log::Displatch::TkPopup which posts a dialog box for
critical status messages only) perhaps a Log::Dispatch::Tk _could_ be
invented and used as a base class for various Tk display mechanisms?
>As I think about it, I
>can't see it possibly being included in the Tk core suite unless you were
>also willing to include the full Log::Dispatch suite as well (which
>doesn't make sense).
There is near zero chance of it being "bundled with" Tk.
But Tk can tolerate separately bundled extensions because of the way
widget classes register themselves with Tk::Widget when their .pm file
is loaded. If Log::Dispatch does not have a similar non-monolithic
extension mechanism it probably should ;-)
>I, however, would be happy to add this to the
>Log::Dispatch suite, depedent on the name chosen.
You probably don't want to do that till it settles down.
The dependancies get messy very quickly if bundles get too complex.
>
>Dominique, if you agree to this we can privately discuss adding this to
>the next release of Log::Dispatch. If we do this, Nick, you may want some
>input as to what TkSomethingOrOther ends up being (or should that
>discussion occur with the whole ptk list?). I don't have too much
>experience with Tk so whatever you all decide will work for me.
I think the discussion can be held away from the list - one of us
should post the conclusion when we have one.
--
Nick Ing-Simmons