summaryrefslogtreecommitdiff
path: root/sdext/qa/unit/data/tdf78427-MyraidPro-Semibold-Light.pdf
diff options
context:
space:
mode:
authorJustin Luth <jluth@mail.com>2024-08-16 21:26:56 -0400
committerMiklos Vajna <vmiklos@collabora.com>2024-09-06 08:42:31 +0200
commit09df48f87f04b0176593cb5f649ac3cd2244891e (patch)
tree3520c49f2f13ead6fcd09610348a4b453ceac16f /sdext/qa/unit/data/tdf78427-MyraidPro-Semibold-Light.pdf
parent1e905680c85c4b79cc72df5dcece38a65898a90d (diff)
tdf#161741 undo nits: NeedsClearRedo is private + prioritize TopLevel
moNeedsClearRedo is an implementation detail, so there should not be public functions for it. Plus, NeedsClearRedo can be called either against the CurrentLevel stack or the TopLevel stack (whatever that implies - there is no documentation...) and since it is a delayed call that means that multiple NeedsClearRedo attempts could be made, theoretically against both stacks. My initial implementation was "last one wins", (which may very well prove to be the best one) but whatever happens, it should be clearly intentional. Based on my limited skill at code reading, it sounds like CurrentLevel might be more of an implemention detail or a temporary expansion of a ListUndoAction, so I am guessing that any request for TopLevel clearing should be given priority. For Writer, it is always clearing the TopLevel stack sw/source/core/undo/docundo.cxx: ClearRedo() return SdrUndoManager::ImplClearRedo_NoLock(TopLevel); Change-Id: I195aefb696599f018712135a2e015549d534791f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171984 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Justin Luth <jluth@mail.com>
Diffstat (limited to 'sdext/qa/unit/data/tdf78427-MyraidPro-Semibold-Light.pdf')
0 files changed, 0 insertions, 0 deletions