GSoC 2020: Info Editor Improvements - Weekly Reports

I will be posting my weekly progress here in this thread. I make notes and designs on my wiki page.
My branch is called soc-2020-info-editor, it can be viewed online

May (in general):

6 Likes

Week 1: June 1 - 7

  • reading more docs about architecture
  • I am still working on Project Details , still reading through code
  • changes to keymap and UI (zebra background, selection) in info editor, experiments already on my branch soc-2020-info-editor, details in commit messages (in future I will document changes in phabricator, I am still learning though) D7950

Next Week’s goals:

  • create design task based on Project Details
  • get more familiar with dev process on phabricator
  • create UI for filtering reports by type (wrok started in D6926)
  • expose debug flags in UI
8 Likes

Week 2: June 8 - 14

  • technical: exploring idea: can we make single backend for text, info and console editor? They are all text based fields. Possible benefits:
    – syntax highlighting in info editor
    – wrap text in info editor
    – autocomplete popup in console the same as in text editor
    – in future: vertical scroling will be implemented once for every view (work started in D4054)
  • getting familiar with UI C api (for exposing debug flags in UI)
  • experimenting with search functionality
    obraz
2 Likes

In principle I agree, there should be a way to share logic. However I see this as a much bigger project than what can be handled as part of this GSoC project.

We have multiple use-cases for text editing: Text editor, console, text widget (hopefully multi-line soon), 3D text object edit mode, the VSE team was recently looking into a way to edit text strips within the preview region, etc. For all these a decent experience is needed, with all the expected cursor navigation (arrow keys, modifier + arrow keys, home key, etc), select-navigation, shortcuts (e.g. Ctrl+A to select all), copy/paste, … And in some cases you’d want syntax highlighting, line-wrapping and I think some basic rich text editing features and spell checking are also something we might want soon.

Point is, yes we should unify this somehow. But I think this should be done β€œthe right way” from the get-go, with a careful design that allows all these things. My idea is to have a reusable text editing widget at the core that manages all or most of this, with options and/or variants to extend it further.

My suggestion is that you keep the focus on your project. It’s easy to get side tracked by things like this, so that you end up delivering too little.

1 Like

Thank for summary.
That was also my conclusion, it is too big for this project. I was mainly looking if there is (easy) way to get syntax highlighting in info editor.

1 Like

The Info Editor uses some icons to represent different classes of reports. Many of those icons were just selected from what was already available by some amateur without much thought really. So if you want anything different, or better, or just something else, post a quick note on this thread and something new will magically appear for you.

Week 3: June 15 - 22

Unfortunately I could not work on blender this week as I prioritized studies (this is final week of studies, exams). Due to pandemic this is very disorganised both from my and my teacher’s perspective.

2 Likes

Week 4: June 23 - 28

  • made easy to read design T78164 (with subtasks), anything what I do will be linked there
  • working on implementing showing logs in info editor D8147
    – it is not on my branch yet, it crashes too often
    – getting familiar with list API, alocationg memory, also pointers gave me a headache this week
    – revise T78214 based on what I learned this week
3 Likes

Week 5: June 29 - July 05

  • working on D8147
    – it is not really stable right now, to even start, run --factory-startup
  • updated my branch - it was stale for a while as D8147 was crashing too much to merge
  • print to log conversion
    – if you care about commits 1 2 3 and more
    – reports that can not be diplayed (for example versioning reports) will be logged (they will be visible in console and info editor)
    – new loggers: wm.session, wm.job, blenloader.readfile, blenloader.undo, blenloader.versioning, bke.report
    – todo enable some loggers by default: blenloader.*, wm.session, blenloader.versioning (log format can be shortened)
  • experimental support for showing python eval logs (stdin, stderr) as report:

And here is your eye candy:

10 Likes

Week 6: July 06 - July 12 - WIP

  • working on reports of type: look in console for detail (UX nighmare). I think I have solution (although review will be needed)
  • investigating debug flag usage in blender and compiling Logging - best practices (feedback needed!)
  • investigate how different log libraries do logging (like google glog, which is already used in cycles)
  • investigate how to make a list of available loggers (probably system similar to makesdna?)
  • separate use of verbosity and severity in logs:
    – previous: 4 severity levels (fatal, error, warn, info), now: 5 levels (+ verbose severity)
    – previous: severity info has levels, now: verbosity has levels, info is just info (no levels)
    – previously: --log-level controls info level, severity warn and error will always show if logger is on, now: --log-severity for severity, --log-verbosity for level of detail in severity verbose
    – if there is a need, I will add severity debug - only available in debug builds
    – although this might be considered being picky, I think it is important to use common conventions, I am open to discussion
  • converting print to logs:
    – G_DEBUG_WM has now almost now uses in code, completely replaced by logs
    – G_DEBUG_EVENTS, G_DEBUG_JOBS is completely replaced by logs
2 Likes