[Bf-committers] Re: New feature: Console output space type (requestfor input).

[GSR]

Hi,
jacques.beaurain at gmail.com (2006-04-21 at 0658.26 -0400):
[...] 
> 1. Command line option -c to disable the redirection and print
> everything to the console as before.

I would do -c copies to stdout as before, and in any case the messages
are sent to the blender console if visible. Simpler.

[...]
> Question; I suppose the window space will need to become completely
> hidden in this case, that may not be trivial. Although if I manage to
> make the output go both to the console and this window and implement
> some of the stuff I'll discuss below this window may still have
> use....

It stays, the user will get rid of it, instead of magically going
away, if he wants to. Simpler again.

> Now for the ideas I had. If we decide on a simple XML syntax message
> format we could use this enhance this system considerably. We can
> either continue to use printf calls or make a new Blender API call to
> do this. I would propose we continue to use the printf's; for one it
> save having to update a lot of code and it ports easier into different
> areas (libraries that use  blender or libraries that gets used by
> blender may send messages in this way). Here is a some examples:

Using XML will require to keep track of what closes what (so pretty
bad for log files and even more for concurrent access), make the file
less readable due extra verbosity (XML is not about being nice for
humans, it is "readable", but not nice). Plain, one item per line,
fixed format should do the work fine, it has been fulfilling the task
for ages.

Using printfs is the best way to have everyone doing something non
standard, XML or simple log format, while using a call or set of calls
could take care of the formatting/tagging.
 
[XML...]

Counter example:
"YYYY-MM-DD HH:MM:SS source[id](level) Message\n"

"source" would be things like python, renderer, meshtool, etc.
"id" would be some kind of thread ID number.
"level" would be things like "error", "debug", "warning", etc.
Maybe source and level in caps, with messages being normal text.

Simple, readable, parseable, easier to recover from corruption, more
concurrent friendly (manage to do the appends to stream be atomic and
100% friendly, which I think write() provides such feature), no libs
to add to blender or to use later to process.

Sadly, no matter if simple log or XML, we lose the nice progress
report feature ("walking dots", changing %), or make it spit crap like
mad (all the time stamp etc for just saying "9%"). Except if we
declare stdout for the active things, and stderr for the logging (a
small perversion of the stream, I think). Or stdout for the active
things and a file for the log.

GSR