Status report: consultancy team, week 25, 2024

Status reports
1

Mike

  • Assistance Functionalities: Tables: Add notes to slides should be possible
    • Worked on the tile corruption
    • Likely the problem was related to the “mode” in the status (statusupdate) message
    • Restructuring it to get sent on other mode changes, too
    • The tile corruption is still there
    • Invalidating tiles needs that the mode is not omitted when it’s 0
    • maybe just invalidate all on mode change?
    • Preparing not-yet-merged changes
  • UpdateAll causes deadlock with Word OLEs
    • They raised its importance
    • Debugged what I see (intermittently) - another mutex deadlock (hope it’s the same with them)
    • Fixed

Tomaz

Fixing CI breakage from annotation work

  • Annotation objects did not get properly cloned
    • SdrPage still has a list of Annotations that needs to be consistent and up-to-date
      • it’s used like before in the import/export filters
    • Page gets duplicated - also annotations get duplicated, but Annotation object kept the old annotation from the previous page
    • Changed the cloning mechanism - annotation gets cloned when the annotation object is cloned, then added to the new page

Mentoring

Looked into dark mode issues Darshan is having for PDF slide notes export:

  • Not at all trivial…
  • There are multiple dark mode related issues
    • Slides are always taking dark mode into account in Impress - even when printing / PDF export
    • Issue exists for desktop too
    • “easy” to change - set background color to white when PDF export
    • Notes view doesn’t properly support COL_AUTO on desktop, if application document background is set to “dark”, the text is not white
      • this can have an influence to dark mode - making things hard
    • In editeng we have to decide what actual font color is COL_AUTO
      • but what background color is is also dependent on the view - what the document background color is currently for this view
      • at this point however we don’t know this yet
      • the buggy code we have currently always assumes the background is the document background, but this is not true
      • if we have a shape, the background can be the shape’s background, which is independent to the document background
      • so the effect of this is that if we have a shape with black background, the font color will not be white if we are in “light mode”
      • the current code we have here is thus not working correctly
      • this needs proper investigation and solution

Miklos

Worked on: