Dev:Source/Architecture/Console Output Space
Blender sends informational messages to the console both during regular usage as well as during Python script execution. It should be benificial to have the ability to view these messages within the UI without having to switch to another desktop window.
Initial Requirements
1) The console output should have its own space within the UI and not on the console command line (Done).
2) This console should display the same text that is currently written to a console in this new space (Done).
3) One should be able to copy/paste from this window (Done).
4) One should be able to clear previous output from the window (Done).
5) Error output (from stderror) should be coloured appropriately (Done).
6) It should be possible to enable/disable this functionality from the commandline (Done). This was implemented as follws for now, but I guess someone with authority may want it different in which case it is easy to change:
Command line option -c to disable the redirection and print everything to the console as before. When -b is used the -c is implied. This should keep the existing programs that rely on this flag working as normal. On Windows a console will be shown when -c is used, otherwise the console will be released (if you are already in a console it regains user input, otherwise a console flashes briefly and then goes away).
Downloads
The new files added as well as a binary file for the icons can be found in the patch archive. Look at the very top of patch.txt for their locations.
Further Enhancements
The following distilled from the responses on the ML. I may have missed some so let me know or add more here.
1. Blender style copy is working, but it would be nice to see Windows clipboard and linux console mouse select/middle click functionality too.
2. Rethink theme colors, choose good colours for rounded theme.
3. Filter menu. Only see python output, only errors, debugging and output etc. Checked menu items in header should be good for this.
4. This goes hand in hand with point 3. Replace printf's with API notification functions that categorizes messages for filtering and logging purposes.
5. Python interactive interpreter in this window. Maye very well be possible.
6. Save output to log. Should be easy, just write the output to a file when it is captured. There can be a command line option to choose a file and 'n default file for the last blender session. Also a menu option to save the current contents (filtered or not).
7. Investigate integration of notifications with platform notification systems, render farms etc.ago using the info header, but perhaps the console header could do
8. Investigate the real estate issue of having such a window in its own space, maybe some form of collapsing/statusbar mode.
9. Support for progress message (running percentages should not generate many lines).
10. What should happen to the space when the output is routed to the console as before (inactive)?
11. Decide on some form of standard for the message lines that would be easy to interpret by the code as well as when written to the console and log. Verbosity can be controlled by even more command line options. I like the following suggestion from GSR:
"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 mmad (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.
This may not neccessarily be true, because we intercept all notification messages with an API whether it goes to the UI or console we can decide what to do with it, so walking dots, spinning slashes and % updates can still be.
