diff options
author | Justin Luth <jluth@mail.com> | 2024-08-16 21:26:56 -0400 |
---|---|---|
committer | Miklos Vajna <vmiklos@collabora.com> | 2024-09-06 08:42:31 +0200 |
commit | 09df48f87f04b0176593cb5f649ac3cd2244891e (patch) | |
tree | 3520c49f2f13ead6fcd09610348a4b453ceac16f /vcl/Executable_lo_kde5filepicker.mk | |
parent | 1e905680c85c4b79cc72df5dcece38a65898a90d (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 'vcl/Executable_lo_kde5filepicker.mk')
0 files changed, 0 insertions, 0 deletions