GSoC 2020 Draft: Info Editor improvements

27.03 EDIT: dropped fancy real time viewer idea, focus on basics
29.03 EDIT: minor refinements and submitted

Info Editor improvements GSOC


Mateusz Grzeliński



My project related to blender:


Show logs and debugs in info editor. Add UI features to make it comfortable to work with logs such as filtering, searching, enable/disable on the fly.


This is developer oriented feature. Currently logs and debugs can be viewed in console. Main motivation is to create UI which allows for easier search in logs.

Some UI improvements have been proposed in T68448 and are partially implemented, but I would like to take more technical approach to issue.


Main features are:

  • show log info in Info Editor

  • show debug info in Info Editor

  • create appropriate UI for 2 above: filtering and searching, enable/disable logs from UI, add icons show what kind of log levels are available

  • import/export logs, mainly to conveniently search user provided logs

These features would lay foundation for no-console log. After this is done we can go fancy like real time view, plotting value from logs and so on.

Additional features to consider, nice to have or nice to start with:

  • industry compat keymap: change selection keymap to match that from outliner - currently info editor follows old blender convention

  • display blender commit and version info in menu (like blender -v, but available from UI)

  • report log size (memory footprint), set maximum log size, delete logs if above maximum size

  • UI: wrap multiple occurences of the same log to one record

  • navigate from log to source code

Project Details

Current status: blender has 2 ways of printing information internally: as debug or as log.


Log is fine detail info visible only in console, to change log settings you need to start blender with appropriate --log* flag. Many files creates logger locally ex. static CLG_LogRef LOG = {"ed.undo"};.

Simplifying, there is one logger type wrapped in several functions and macros which ends with puts function. Logging function takes log as string - this string is already formatted.

Logging macros (CLOG) enforce text structure:



INFO (wm.msgbus.sub): /home/mat/blender-sources/blender-src/source/blender/windowmanager/message_bus/intern/wm_message_bus_rna.c:292 WM_msg_subscribe_rna_params: rna(id=’’, Object.mode, info=‘view3d_main_region_message_subscribe’)

Because of this defined structure and centralized control in macros it will be easier to change.

UI will be a challenge as logs are typical table like data and blender does not have this concept and introducing completely new concept might be not worth the hassle. There are also external log viewers, so advanced UI for logs is not a priority.

There are around 420 CLOG entries in code (grep -r CLOG | wc -l).

Conclusion: make every CLOG visible in Info Editor.


Debugs are flag based. They are stored in Global.debug. The use of debug is complicated in blender:

  • sometimes it calls log: if (G.debug & G_DEBUG) then CLOG

  • sometimes it calls to stdout/err directly if (G.debug & G_DEBUG) fprintf(stderr, ...); fflush(stderr);

  • some libraries have its own loggers and issue must be looked one by one. Ex. FFMPEG has av_log_default_callback

  • depsgraph has dedicated module for debugging

  • some modules can be build separately (like cycles) - investigate if any conflicts will occur

  • for reference: there are 821 uses of std (grep -r 'fprintf(std' | wc -l) and 5554 uses of print itself (grep -r "printf(" | wc -l). Of course some of them are legitimate uses

In majority of cases prints should be simply replaced by logs, what solves the issue of printing debug information in Info Editor. See for example:

if (G.debug & G_DEBUG) {

printf("%s: something wrong in areafullscreen\n", func);


Developer wanted to know where is this called from - it is basically log.

Conclusion: convert every debug print to CLOG. There are only few cases there it can not be applied and it needs to studied further (like external libraries). Note: depsgraph also uses print.

Project Schedule

May 4 - June 1 : community bonding period:

  1. getting familiar with prior work regarding info editor, like,,, and so on
  2. Look at existing implementation of search functionality in blender
  3. Investigate logs: if multiple log types is the way to go, if centralized formatting in Info Editor is good idea, if it will not break command command line option --log-file
  4. Make a lisk how and where debugs are used

June 1 - June 29 - First evaluations:

I do not want to promise too many features in this period as this is the end of term and start of exams.

  • Industry compat keymap: change selection pattern in info editor to be consistent with outliner - simple task to get started

  • make log display in Info Editor

June 29 - July 27 - Second evaluations:

  • add text based search
  • log to filters search
  • UI: show current level of log
  • UI: show current level of debugs
  • dynamically disable/enable logs, debugs
  • import/export logs

July 27 - August 31 - submit code and evaluations:

  • print debugs in Info Editor


I am master student from AGH university in Kraków, Poland. I study Computer Science, System Modeling and Data Analysis. I am 21.

I did not submit many patches to blender itself, but I have been following development of blender for 6 years doing both: a little bit of artistic, a little bit of coding. I have moderate experience in C from my study classes and first work (first work was in embedded c programming), basic experience in C++ (mainly from studies) and strong experience in python from both my second job and by bachelor thesis. Also I use linux (and zsh, SpaceVim) as my daily driver.


Sweet! One caution and one wish list item…

The caution is just that the visual changes can take longer than expected. This is just because the drawing of Info is using code (TextView) that is shared with Console Editor. So you either have to always ensure that changes to Info don’t break Console or you have to sever this dependency and let each do their own drawing. I did attempt the latter once but the idea was not accepted because there was more utility in sharing the code than in anything extra I was adding. You are obviously proposing more changes though, so that doesn’t really apply.

The wish list item. Right now Info is only showing items that are normally sent to the report system. But you can increase that by starting blender with command-line arguments. It would be nice to show the current level of events by default but optionally allow these extra messages to be displayed using the current filtering. Right now if you enable these extra reports they only go to the system console. But you then get reports when just selecting items, for example. Not that useful generally, but nice to have as an option.

1 Like

My main motivation for having this as a GSoC idea was to give access to render, depsgraph and viewport logs in a user friendly way, which is something we are really lacking. The realtime info idea is interesting, but also kind of starts with a nice to have feature before we have the more important functionality in place.

Just getting all the logs to display without any kind of realtime tracking or filtering is already some work, especially since it may involve going into render, depsgraph and viewport to make the contents of the logs better and more user friendly.

I think the right click select idea about viewport stats is really a different thing. Which doesn’t mean it’s not a good project, users have asked for more control over such stats, but also do display them in the 3D viewport. But I expect that displaying them in the info editor may not be exactly what users are after, I think they expect something more simple that they can toggle on/off as an overlay while working in the 3D viewport, rather than having to open another editor.


The deadline to submit proposals is March 31 (check the timeline). You can already submit drafts there, which you can keep updating until the deadline. I think even the final PDF (that is submitted separately to the drafts) can still be updated.


@Harleya @brecht I have updated my proposal, I think your ideas are much more reasonable, have basics working before going fancy.

How far into technical details am I expected to go? I have done some research but there are many things I do not know without spending many hours in code.

1 Like

I really didn’t mean to discourage you from the visual changes you initially talked of. I was mostly just suggesting to budget more time than you might initially if just guessing from how simple the output is.

But what you have list here is awesome. Moving more information out of the system console and into Info reports would be very important work. Just getting more report items in there would be wonderful, even if not displayed nicely.

1 Like

Using the logging system throughout Blender and making that output available in the info editor makes sense to me. If we could end up in a situation where users don’t have to look at the console for errors but can see everything the info editor that would be great.

This is still different than the GSoC idea, since it doesn’t seem like this would make render, depsgraph or viewport logs much better specifically. But it’s a step toward that and about solving an important problem nonetheless.

The current proposal is technical enough, it’s more about high level design ideas about how you might implement it than specifics.