GSoC 2020: Info Editor Improvements - Discussion and Suggestions (logs, reports & friends)

I am trying to create some sensible filter UI for logging.

I would like to include features:

  • filter log severity (as enum or flag enum)
  • separate search fields log type, file line, log function
    – the UI is borrowed from this:
    image
  • ideally I would like to filter verbosity by ranges, but I can not figure out sensible UI for this king of feature

I am not sure how to expose log message formatting, so far I went with flag approach.

As for the context menu I am planning operations:

  • exclude log type/function/file/this line
  • sync selection - across all open info editors select the next visible log entry
  • copy all/file
3 Likes

If you’re including python errors, have you considered clicking on an error report would scroll to that line in the script in the Text Editor?

1 Like

Ghost’s logging (really printing) is enabled up by either macro’ed printf statements enabled by CMake flags, naked printf/couts, or as a runtime argument, but which is relied upon seems to be somewhat platform specific (e.g. the runtime argument seems to only be used for Linux).

In my case I’d like a clean way to log Wintab information in Ghost - see D7840. Ideally I’d like to isolate it from the noise of other Ghost-related debug information.

1 Like

Currently on python error text is being scrolled (at least in some conditions). There is no way to save any additional information in report. I can see this feature usefull, but currently it is hard to implement in clean way

2 Likes

I really like your project, you have done wonders with the Info editor or at least the UI with filtering, even if its the template and not yet implemented in code yet, looks really cool now! Thanks.

5 Likes

Filtering implementation is coming this week. Yesterday I added add,remove logic around filter boxes:
image
I wonder if filter boxes should have match case, use glob buttons…

1 Like

I am wondering how will you implement it without cluttering the UI, based on context?
having Match Case with a checkbox on the top, based on the currently selected Filter box, one can select and deselect it for each box, so you will have to save some state and maybe even allow for multiple selection for Filter boxes(?). This is as opposed to each Filter Box having its own match case. Is this close to your plan? and the currently selected Filter Box will have an orange or some colored selection around it. By “glob” buttons you mean “global”? or is it a button type?

2 Likes

there are 3-4 functionalities that i want to pack in filter UI/UX:

  • negate pattern - can be a button, or just sign in text glob (^ to negate pattern, same as in blender command line args)
  • match case
  • use glob - use globbing (pattern matching, wildcards) - sorry, nerdy stuff - in short: * match any character, ^ - negate pattern
  • match exact - match only words, do not match subset of string (need t verify naming of this one)

The last 2 might become one, I must deep dive into details.

Use glob can be always enabled, it does not have to be even an option, need to test it with user scenarios.
My first thoughts were to add buttons as below. Here are buttons for use case and use glob.
EDIT; the bottom rows will also have buttons
image

1 Like

Can anything be done so a new build will be available on https://blender.community/c/graphicall/ ?

1 Like

It is here Daily builds, but it seems to be quite old, I just asked LazyDodo for help
EDIT: I messed up. There are compiler differences on windows that I did not notice (I use Linux). I need to setup windows machine, It will take me a day to fix
EDIT: I just commited fix, build should be available soon (I will keep an eye on it)

@tintwotin it is up!

Sorry that you had to spend valuable time on getting the builds up and running again. Thank you. I gave it a spin.

  • The header should properly be visible as the factory setting of the Scripting workspace.
  • I don’t know if the spacing of the python errors is something you also deal with?
    image
    Imo, should the empty lines be removed and the line height should be no different than the transform message above.
  • Tooltips are missing from the Reports and Logs buttons.
  • The Case Sensitive button, when selected it seems to be off - maybe it should be reversed?
  • How do I get the messages in the system console to be printed in the log when ex. generating proxies in the VSE?

    They’re “printf” texts.
  • The Info menu seems to be broken in your build?
1 Like

Meh, it had to me done eventually. Anyway, thanks for taking enough interest to download the build and provide feedback. Not many will do that :slight_smile:

You will find a couple of this paper cuts (defaults, versioning, UI). I consider them to be secondary, I am changing too much in code to set defaults just yet. I will deal with it eventually.

This is todo. I was changing quite a bit of drawing code this week. Drawing code is hard to tackle, so I am moving slowly.
It is spacing between the lines in general (every multi line information). Wrapped text is calculated differently.

Yep, it was reversed, but only when not using globbing. I commited fix today.

I just fixed it today.

You can not, they are outside of logging system. In theory I can redirect system console to UI, but I am not sure about implications (it will not be possible to filter such text for sure).
Currently you need to convert printf to CLOG_*, what is quite easy, see commit with global log for reference (althoug local logger is prefered).

1 Like

Thanks for tightening the python errors, however now the python console looks weird at start-up, is this related?
image

Auto scroll - doesn’t seems to work? Scroll to some else than the latest line, make an error in python(in the text editor) - it doesn’t scroll to that position with the error.
I’m not sure it should be a setting, but just the way it behaves.
If it should be a setting it needs to be moved into the View menu.
It also makes the buttons to the right invisible on a 1920x1080 screen:
image

Normally all View related options should be in the View menu, but maybe ask the UI team for guidelines in this case? Also, ask them about text buttons in headers are okay, when William was the UI maintainer, it wasn’t. Inverse match needs a better icon, imo.
Why does the Info menu change name, when it has the same entries in both Report and Log mode?
The Context menu is only for options to edit the selected elements. It seems to me that the stuff you put in there actually belongs in the View menu.

Maybe use the tooltip to explain how to use wildcard, for now it is unclear.

1 Like

I bet theme colors are messed up, keywords might have the same colors as background. I have not yet figured out how to do versioning properly.

Oh, we have different view how it should work. Currently:

  • Autoscroll on: view will be shifted up when new item arrives (it will not jump to new item)
  • Autoscroll off: view will always stay in the same place

But your point of view also makes sense.

It stated as technical reason, there are actually different code that manages selection.
I also forgot to put in mute options in Log menu.

Yes, I will work on it, so far it uses fnmatch function for pattern recognition general pattern matching docs

Python API for blender log system

EDIT: keep an eye on official task: https://developer.blender.org/T80072

I am experimenting with showing python logs in Info Editor. Python has excellent logging module so my approach is minimalistic. Minimal example (work-in-progress):

My approach:

  1. use python logging
  2. expose blender logging as handler bpy.utils.LogHandler. Loghandler inherits logging.Handler and is fully functional python class.
  3. optional: expose individual log utilities for quick and easy: bpy.utils.info("message"), bpy.utils.warning and so on

Additionally:

  • python log level will be mapped to blender log level
  • python log type will be mirrored to blender log type
  • if addon developer wants, one can create property for controlling log level and control it from user settings, I will not create bigger framework for this kind of settings

These changes are not in branch.

EDIT: example of functionality 2 (experimental):

import bpy

# for blender internal usage, quick and easy, but alsways logs to "bpy.log"
bpy.utils.log.error("hello")
bpy.utils.log.warning("hello")
bpy.utils.log.info("hello")
bpy.utils.log.debug("hello")

# for blender addons, the classic way
import logging
import bpy
log = logging.getLogger("bpy.my_addon")  # add type for easy filtering in blender
log.addhandler(bpy.utils.log.LogHandler())
log.setLevel(logging.INFO) # default is WARNING

# for blender addons, experimental way
import bpy
import logging

log = bpy.utils.log.getLogger("bpy.my_addon")  # automatically add handler (can also set log level based on blener's log level)
log.setLevel(logging.INFO)
8 Likes

Has any of this been submitted or committed yet, or what is the status?

Unfortunately there has been no progress (not review comments, no commits) in tasks that I created at the end of my GSoC (see post on weekly notes). This is kind of understandable, because review of this big patch is a lot of work, so I am not pushing developers on this. And still some issues remained unsolved.
EDIT: note, the meeting notes say that devs are integrating other GSoC projects right now

3 Likes

If you and your mentor where in sync on what to implement and how to implement it, I guess it’s more a question of checking if there are any problems in how it actually is implemented?

1 Like
2 Likes

oh, well. That is not what I expected… I need to think about it.

2 Likes