2023-08-16 00:20:26 +10:00
|
|
|
/* SPDX-FileCopyrightText: 2004 Blender Authors
|
2023-05-31 16:19:06 +02:00
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
2008-12-30 19:01:12 +00:00
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup edundo
|
2011-02-27 20:29:51 +00:00
|
|
|
*/
|
|
|
|
|
|
2023-07-22 11:27:25 +10:00
|
|
|
#include <cstring>
|
2008-12-30 19:01:12 +00:00
|
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
2018-04-05 13:41:52 +02:00
|
|
|
#include "CLG_log.h"
|
|
|
|
|
|
2018-04-16 16:27:55 +02:00
|
|
|
#include "DNA_object_types.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "DNA_scene_types.h"
|
2008-12-30 19:01:12 +00:00
|
|
|
|
2018-07-12 14:43:35 +02:00
|
|
|
#include "BLI_listbase.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLI_utildefines.h"
|
2008-12-30 19:01:12 +00:00
|
|
|
|
2024-02-09 18:59:42 +01:00
|
|
|
#include "BLT_translation.hh"
|
2012-04-13 19:59:29 +00:00
|
|
|
|
2024-01-21 19:49:58 +01:00
|
|
|
#include "BKE_blender_undo.hh"
|
2024-02-09 19:29:34 +01:00
|
|
|
#include "BKE_callbacks.hh"
|
2023-11-16 11:41:55 +01:00
|
|
|
#include "BKE_context.hh"
|
2024-02-10 18:25:14 +01:00
|
|
|
#include "BKE_global.hh"
|
2024-01-23 15:18:09 -05:00
|
|
|
#include "BKE_layer.hh"
|
2023-12-01 19:43:16 +01:00
|
|
|
#include "BKE_main.hh"
|
2023-08-02 22:14:18 +02:00
|
|
|
#include "BKE_paint.hh"
|
2024-02-10 18:34:29 +01:00
|
|
|
#include "BKE_report.hh"
|
2024-02-10 19:16:25 +01:00
|
|
|
#include "BKE_scene.hh"
|
2023-09-25 17:48:21 -04:00
|
|
|
#include "BKE_screen.hh"
|
2024-01-15 12:26:09 -05:00
|
|
|
#include "BKE_undo_system.hh"
|
2018-07-31 10:22:19 +02:00
|
|
|
#include "BKE_workspace.h"
|
2008-12-30 19:01:12 +00:00
|
|
|
|
2023-08-28 15:01:05 +02:00
|
|
|
#include "BLO_blend_validate.hh"
|
2018-10-17 16:43:02 +02:00
|
|
|
|
2023-08-05 02:57:52 +02:00
|
|
|
#include "ED_asset.hh"
|
|
|
|
|
#include "ED_gpencil_legacy.hh"
|
|
|
|
|
#include "ED_object.hh"
|
|
|
|
|
#include "ED_outliner.hh"
|
|
|
|
|
#include "ED_render.hh"
|
2023-08-04 23:11:22 +02:00
|
|
|
#include "ED_screen.hh"
|
2023-08-05 02:57:52 +02:00
|
|
|
#include "ED_undo.hh"
|
2008-12-31 18:52:15 +00:00
|
|
|
|
2023-08-04 23:11:22 +02:00
|
|
|
#include "WM_api.hh"
|
2024-01-04 14:30:21 -05:00
|
|
|
#include "WM_toolsystem.hh"
|
2023-08-04 23:11:22 +02:00
|
|
|
#include "WM_types.hh"
|
2008-12-30 19:01:12 +00:00
|
|
|
|
2023-08-10 22:40:27 +02:00
|
|
|
#include "RNA_access.hh"
|
|
|
|
|
#include "RNA_define.hh"
|
|
|
|
|
#include "RNA_enum_types.hh"
|
2008-12-30 19:01:12 +00:00
|
|
|
|
2023-08-05 02:57:52 +02:00
|
|
|
#include "UI_interface.hh"
|
|
|
|
|
#include "UI_resources.hh"
|
Code holiday commit:
- fix: user pref, window title was reset to 'Blender' on tab usage
- Undo history menu back:
- name "Undo History"
- hotkey alt+ctrl+z (alt+apple+z for mac)
- works like 2.4x, only for global undo, editmode and particle edit.
- Menu scroll
- for small windows or screens, popup menus now allow to display
all items, using internal scrolling
- works with a timer, scrolling 10 items per second when mouse
is over the top or bottom arrow
- if menu is too big to display, it now draws to top or bottom,
based on largest available space.
- also works for hotkey driven pop up menus.
- User pref "DPI" follows widget/layout size
- widgets & headers now become bigger and smaller, to match
'dpi' font sizes. Works well to match UI to monitor size.
- note that icons can get fuzzy, we need better mipmaps for it
2011-06-04 17:03:46 +00:00
|
|
|
|
2024-03-22 16:24:30 +01:00
|
|
|
using blender::Set;
|
|
|
|
|
using blender::Vector;
|
|
|
|
|
|
2018-04-05 13:41:52 +02:00
|
|
|
/** We only need this locally. */
|
|
|
|
|
static CLG_LogRef LOG = {"ed.undo"};
|
|
|
|
|
|
2018-04-02 15:02:08 +02:00
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Generic Undo System Access
|
|
|
|
|
*
|
|
|
|
|
* Non-operator undo editor functions.
|
|
|
|
|
* \{ */
|
2008-12-30 19:01:12 +00:00
|
|
|
|
2020-10-30 20:24:13 +11:00
|
|
|
bool ED_undo_is_state_valid(bContext *C)
|
|
|
|
|
{
|
|
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
|
|
|
|
|
|
|
|
|
/* Currently only checks matching begin/end calls. */
|
2023-01-23 00:32:39 +01:00
|
|
|
if (wm->undo_stack == nullptr) {
|
2020-10-30 20:24:13 +11:00
|
|
|
/* No undo stack is valid, nothing to do. */
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
if (wm->undo_stack->group_level != 0) {
|
|
|
|
|
/* If this fails #ED_undo_grouped_begin, #ED_undo_grouped_end calls don't match. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2023-01-23 00:32:39 +01:00
|
|
|
if (wm->undo_stack->step_active != nullptr) {
|
2020-10-30 20:24:13 +11:00
|
|
|
if (wm->undo_stack->step_active->skip == true) {
|
|
|
|
|
/* Skip is only allowed between begin/end calls,
|
|
|
|
|
* a state that should never happen in main event loop. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ED_undo_group_begin(bContext *C)
|
|
|
|
|
{
|
|
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
|
|
|
|
BKE_undosys_stack_group_begin(wm->undo_stack);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ED_undo_group_end(bContext *C)
|
|
|
|
|
{
|
|
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
|
|
|
|
BKE_undosys_stack_group_end(wm->undo_stack);
|
|
|
|
|
}
|
|
|
|
|
|
2010-11-17 09:45:45 +00:00
|
|
|
void ED_undo_push(bContext *C, const char *str)
|
2008-12-30 19:01:12 +00:00
|
|
|
{
|
2018-04-05 13:41:52 +02:00
|
|
|
CLOG_INFO(&LOG, 1, "name='%s'", str);
|
2020-05-14 14:58:54 +10:00
|
|
|
WM_file_tag_modified();
|
2018-04-05 13:41:52 +02:00
|
|
|
|
2020-05-14 14:58:54 +10:00
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
|
|
|
|
int steps = U.undosteps;
|
|
|
|
|
|
|
|
|
|
/* Ensure steps that have been initialized are always pushed,
|
|
|
|
|
* even when undo steps are zero.
|
|
|
|
|
*
|
|
|
|
|
* Note that some modes (paint, sculpt) initialize an undo step before an action runs,
|
|
|
|
|
* then accumulate changes there, or restore data from it in the case of 2D painting.
|
|
|
|
|
*
|
|
|
|
|
* For this reason we need to handle the undo step even when undo steps is set to zero.
|
|
|
|
|
*/
|
2023-01-23 00:32:39 +01:00
|
|
|
if ((steps <= 0) && wm->undo_stack->step_init != nullptr) {
|
2020-05-14 14:58:54 +10:00
|
|
|
steps = 1;
|
|
|
|
|
}
|
2018-03-19 14:17:59 +01:00
|
|
|
if (steps <= 0) {
|
|
|
|
|
return;
|
2008-12-30 19:01:12 +00:00
|
|
|
}
|
2020-07-19 18:59:14 +10:00
|
|
|
if (G.background) {
|
|
|
|
|
/* Python developers may have explicitly created the undo stack in background mode,
|
2023-02-12 14:37:16 +11:00
|
|
|
* otherwise allow it to be nullptr, see: #60934.
|
2023-01-23 00:32:39 +01:00
|
|
|
* Otherwise it must never be nullptr, even when undo is disabled. */
|
|
|
|
|
if (wm->undo_stack == nullptr) {
|
2020-07-19 18:59:14 +10:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-03-19 14:17:59 +01:00
|
|
|
|
2021-10-19 18:33:42 +11:00
|
|
|
eUndoPushReturn push_retval;
|
2020-12-27 22:15:20 +01:00
|
|
|
|
2018-03-19 14:17:59 +01:00
|
|
|
/* Only apply limit if this is the last undo step. */
|
2023-01-23 00:32:39 +01:00
|
|
|
if (wm->undo_stack->step_active && (wm->undo_stack->step_active->next == nullptr)) {
|
2018-03-19 14:17:59 +01:00
|
|
|
BKE_undosys_stack_limit_steps_and_memory(wm->undo_stack, steps - 1, 0);
|
2014-05-14 01:09:09 +03:00
|
|
|
}
|
2018-03-19 14:17:59 +01:00
|
|
|
|
2020-12-27 22:15:20 +01:00
|
|
|
push_retval = BKE_undosys_step_push(wm->undo_stack, C, str);
|
2018-03-19 14:17:59 +01:00
|
|
|
|
|
|
|
|
if (U.undomemory != 0) {
|
2023-01-23 17:31:46 +11:00
|
|
|
const size_t memory_limit = size_t(U.undomemory) * 1024 * 1024;
|
2020-05-14 14:52:07 +10:00
|
|
|
BKE_undosys_stack_limit_steps_and_memory(wm->undo_stack, -1, memory_limit);
|
2008-12-30 19:01:12 +00:00
|
|
|
}
|
2014-03-13 22:35:26 +02:00
|
|
|
|
2019-07-10 19:37:33 +10:00
|
|
|
if (CLOG_CHECK(&LOG, 1)) {
|
|
|
|
|
BKE_undosys_print(wm->undo_stack);
|
|
|
|
|
}
|
2020-12-27 22:15:20 +01:00
|
|
|
|
|
|
|
|
if (push_retval & UNDO_PUSH_RET_OVERRIDE_CHANGED) {
|
2023-01-23 00:32:39 +01:00
|
|
|
WM_main_add_notifier(NC_WM | ND_LIB_OVERRIDE_CHANGED, nullptr);
|
2020-12-27 22:15:20 +01:00
|
|
|
}
|
2008-12-30 19:01:12 +00:00
|
|
|
}
|
|
|
|
|
|
2019-02-07 10:09:56 +11:00
|
|
|
/**
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
* Common pre management of undo/redo (killing all running jobs, calling pre handlers, etc.).
|
2019-02-07 10:09:56 +11:00
|
|
|
*/
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
static void ed_undo_step_pre(bContext *C,
|
|
|
|
|
wmWindowManager *wm,
|
|
|
|
|
const enum eUndoStepDir undo_dir,
|
2021-01-14 11:44:16 +01:00
|
|
|
ReportList *reports)
|
2014-02-15 13:28:26 +11:00
|
|
|
{
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
BLI_assert(ELEM(undo_dir, STEP_UNDO, STEP_REDO));
|
|
|
|
|
|
|
|
|
|
Main *bmain = CTX_data_main(C);
|
2014-02-15 13:28:26 +11:00
|
|
|
Scene *scene = CTX_data_scene(C);
|
2020-04-03 13:25:03 +02:00
|
|
|
ScrArea *area = CTX_wm_area(C);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-11-29 15:26:46 +00:00
|
|
|
/* undo during jobs are running can easily lead to freeing data using by jobs,
|
2011-12-11 19:23:02 +00:00
|
|
|
* or they can just lead to freezing job in some other cases */
|
2018-08-24 12:36:19 +10:00
|
|
|
WM_jobs_kill_all(wm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-10-17 16:43:02 +02:00
|
|
|
if (G.debug & G_DEBUG_IO) {
|
2023-01-23 00:32:39 +01:00
|
|
|
if (bmain->lock != nullptr) {
|
2023-08-30 15:06:59 +02:00
|
|
|
BKE_report(
|
|
|
|
|
reports, RPT_DEBUG, "Checking validity of current .blend file *BEFORE* undo step");
|
2018-10-17 16:43:02 +02:00
|
|
|
BLO_main_validate_libraries(bmain, reports);
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2018-10-17 16:43:02 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-04-03 13:25:03 +02:00
|
|
|
if (area && (area->spacetype == SPACE_VIEW3D)) {
|
2018-07-31 10:22:19 +02:00
|
|
|
Object *obact = CTX_data_active_object(C);
|
2023-03-08 12:35:58 +01:00
|
|
|
if (obact && (obact->type == OB_GPENCIL_LEGACY)) {
|
2023-01-23 00:32:39 +01:00
|
|
|
ED_gpencil_toggle_brush_cursor(C, false, nullptr);
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2018-07-31 10:22:19 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-07-12 14:43:35 +02:00
|
|
|
/* App-Handlers (pre). */
|
|
|
|
|
{
|
2021-07-03 23:08:40 +10:00
|
|
|
/* NOTE: ignore grease pencil for now. */
|
2018-07-12 14:43:35 +02:00
|
|
|
wm->op_undo_depth++;
|
2019-09-09 10:25:04 +02:00
|
|
|
BKE_callback_exec_id(
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
bmain, &scene->id, (undo_dir == STEP_UNDO) ? BKE_CB_EVT_UNDO_PRE : BKE_CB_EVT_REDO_PRE);
|
2018-07-12 14:43:35 +02:00
|
|
|
wm->op_undo_depth--;
|
|
|
|
|
}
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
/**
|
|
|
|
|
* Common post management of undo/redo (calling post handlers, adding notifiers etc.).
|
|
|
|
|
*
|
|
|
|
|
* \note Also check #undo_history_exec in bottom if you change notifiers.
|
|
|
|
|
*/
|
|
|
|
|
static void ed_undo_step_post(bContext *C,
|
|
|
|
|
wmWindowManager *wm,
|
|
|
|
|
const enum eUndoStepDir undo_dir,
|
|
|
|
|
ReportList *reports)
|
|
|
|
|
{
|
2024-01-26 18:30:55 -05:00
|
|
|
using namespace blender::ed;
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
BLI_assert(ELEM(undo_dir, STEP_UNDO, STEP_REDO));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
Main *bmain = CTX_data_main(C);
|
|
|
|
|
Scene *scene = CTX_data_scene(C);
|
2021-03-17 11:37:10 +01:00
|
|
|
ScrArea *area = CTX_wm_area(C);
|
|
|
|
|
|
|
|
|
|
/* Set special modes for grease pencil */
|
2023-01-23 00:32:39 +01:00
|
|
|
if (area != nullptr && (area->spacetype == SPACE_VIEW3D)) {
|
2021-03-17 11:37:10 +01:00
|
|
|
Object *obact = CTX_data_active_object(C);
|
2023-03-08 12:35:58 +01:00
|
|
|
if (obact && (obact->type == OB_GPENCIL_LEGACY)) {
|
2021-03-17 11:37:10 +01:00
|
|
|
/* set cursor */
|
2023-02-07 17:34:20 +11:00
|
|
|
if (obact->mode & OB_MODE_ALL_PAINT_GPENCIL) {
|
2023-01-23 00:32:39 +01:00
|
|
|
ED_gpencil_toggle_brush_cursor(C, true, nullptr);
|
2021-03-17 11:37:10 +01:00
|
|
|
}
|
|
|
|
|
else {
|
2023-01-23 00:32:39 +01:00
|
|
|
ED_gpencil_toggle_brush_cursor(C, false, nullptr);
|
2021-03-17 11:37:10 +01:00
|
|
|
}
|
|
|
|
|
/* set workspace mode */
|
|
|
|
|
Base *basact = CTX_data_active_base(C);
|
2024-03-28 01:30:38 +01:00
|
|
|
object::base_activate(C, basact);
|
2021-03-17 11:37:10 +01:00
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-07-12 14:43:35 +02:00
|
|
|
/* App-Handlers (post). */
|
|
|
|
|
{
|
|
|
|
|
wm->op_undo_depth++;
|
2019-09-09 10:25:04 +02:00
|
|
|
BKE_callback_exec_id(
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
bmain, &scene->id, (undo_dir == STEP_UNDO) ? BKE_CB_EVT_UNDO_POST : BKE_CB_EVT_REDO_POST);
|
2018-07-12 14:43:35 +02:00
|
|
|
wm->op_undo_depth--;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-10-17 16:43:02 +02:00
|
|
|
if (G.debug & G_DEBUG_IO) {
|
2023-01-23 00:32:39 +01:00
|
|
|
if (bmain->lock != nullptr) {
|
2023-08-30 15:06:59 +02:00
|
|
|
BKE_report(reports, RPT_INFO, "Checking validity of current .blend file *AFTER* undo step");
|
2018-10-17 16:43:02 +02:00
|
|
|
BLO_main_validate_libraries(bmain, reports);
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-01-23 00:32:39 +01:00
|
|
|
WM_event_add_notifier(C, NC_WINDOW, nullptr);
|
|
|
|
|
WM_event_add_notifier(C, NC_WM | ND_UNDO, nullptr);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-10-29 20:20:16 +11:00
|
|
|
WM_toolsystem_refresh_active(C);
|
2018-06-04 16:41:03 +02:00
|
|
|
WM_toolsystem_refresh_screen_all(bmain);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2024-01-26 18:30:55 -05:00
|
|
|
asset::list::storage_tag_main_data_dirty();
|
2021-07-09 12:56:26 +02:00
|
|
|
|
2019-07-10 19:37:33 +10:00
|
|
|
if (CLOG_CHECK(&LOG, 1)) {
|
|
|
|
|
BKE_undosys_print(wm->undo_stack);
|
|
|
|
|
}
|
2008-12-30 19:01:12 +00:00
|
|
|
}
|
|
|
|
|
|
2021-04-09 18:47:10 +10:00
|
|
|
/**
|
|
|
|
|
* Undo or redo one step from current active one.
|
|
|
|
|
* May undo or redo several steps at once only if the target step is a 'skipped' one.
|
|
|
|
|
* The target step will be the one immediately before or after the active one.
|
|
|
|
|
*/
|
2021-01-14 09:49:22 +11:00
|
|
|
static int ed_undo_step_direction(bContext *C, enum eUndoStepDir step, ReportList *reports)
|
2019-06-07 15:30:49 +10:00
|
|
|
{
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
BLI_assert(ELEM(step, STEP_UNDO, STEP_REDO));
|
|
|
|
|
|
|
|
|
|
CLOG_INFO(&LOG, 1, "direction=%s", (step == STEP_UNDO) ? "STEP_UNDO" : "STEP_REDO");
|
|
|
|
|
|
2023-02-09 11:30:25 +11:00
|
|
|
/* TODO(@ideasman42): undo_system: use undo system */
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
/* grease pencil can be can be used in plenty of spaces, so check it first */
|
|
|
|
|
/* FIXME: This gpencil undo effectively only supports the one step undo/redo, undo based on name
|
|
|
|
|
* or index is fully not implemented.
|
|
|
|
|
* FIXME: However, it seems to never be used in current code (`ED_gpencil_session_active` seems
|
|
|
|
|
* to always return false). */
|
|
|
|
|
if (ED_gpencil_session_active()) {
|
2021-02-04 22:03:39 +01:00
|
|
|
return ED_undo_gpencil_step(C, step);
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
|
|
|
|
|
|
|
|
|
ed_undo_step_pre(C, wm, step, reports);
|
|
|
|
|
|
|
|
|
|
if (step == STEP_UNDO) {
|
|
|
|
|
BKE_undosys_step_undo(wm->undo_stack, C);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
BKE_undosys_step_redo(wm->undo_stack, C);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ed_undo_step_post(C, wm, step, reports);
|
|
|
|
|
|
|
|
|
|
return OPERATOR_FINISHED;
|
2019-06-07 15:30:49 +10:00
|
|
|
}
|
|
|
|
|
|
2021-04-09 18:47:10 +10:00
|
|
|
/**
|
|
|
|
|
* Undo the step matching given name.
|
|
|
|
|
* May undo several steps at once.
|
|
|
|
|
* The target step will be the one immediately before given named one.
|
|
|
|
|
*/
|
2019-06-07 15:30:49 +10:00
|
|
|
static int ed_undo_step_by_name(bContext *C, const char *undo_name, ReportList *reports)
|
|
|
|
|
{
|
2023-01-23 00:32:39 +01:00
|
|
|
BLI_assert(undo_name != nullptr);
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
|
|
|
|
|
/* FIXME: See comments in `ed_undo_step_direction`. */
|
|
|
|
|
if (ED_gpencil_session_active()) {
|
2021-07-15 18:23:28 +10:00
|
|
|
BLI_assert_msg(0, "Not implemented currently.");
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
|
|
|
|
UndoStep *undo_step_from_name = BKE_undosys_step_find_by_name(wm->undo_stack, undo_name);
|
2023-01-23 00:32:39 +01:00
|
|
|
if (undo_step_from_name == nullptr) {
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
CLOG_ERROR(&LOG, "Step name='%s' not found in current undo stack", undo_name);
|
|
|
|
|
|
|
|
|
|
return OPERATOR_CANCELLED;
|
|
|
|
|
}
|
|
|
|
|
|
BKE UndoSys refactor: deduplicate and simplify code, sanitize naming.
Now we only use 'undo' or 'redo' in function names when the direction is
clear (and we assert about it). Otherwise, use 'load' instead.
When passing an undo step to BKE functions, consider calling code has
done its work and is actually passing the target step (i.e. the final
step intended to be loaded), instead of assuming we have to load the
step before/after it.
Also deduplicate and simplify a lot of core undo code in BKE, now
`BKE_undosys_step_load_data_ex` is the only place where all the complex
logic of undo/redo loop (to handle several steps in a row) is placed. We also
only use a single loop there, instead of the two existing ones in
previous code.
Note that here we consider that when we are loading the current active
step, we are undoing. This makes sense in that doing so //may// undo
some changes (ideally it should never do so), but should never, ever
redo anything.
`BKE_undosys_step_load_from_index` also gets heavily simplified, it's
not basically a shallow wrapper around
`BKE_undosys_step_load_from_index`.
And some general update of variable names, commenting, etc.
Part of T83806.
Differential Revision: https://developer.blender.org/D10227
2021-01-27 16:42:50 +01:00
|
|
|
UndoStep *undo_step_target = undo_step_from_name->prev;
|
2023-01-23 00:32:39 +01:00
|
|
|
if (undo_step_target == nullptr) {
|
BKE UndoSys refactor: deduplicate and simplify code, sanitize naming.
Now we only use 'undo' or 'redo' in function names when the direction is
clear (and we assert about it). Otherwise, use 'load' instead.
When passing an undo step to BKE functions, consider calling code has
done its work and is actually passing the target step (i.e. the final
step intended to be loaded), instead of assuming we have to load the
step before/after it.
Also deduplicate and simplify a lot of core undo code in BKE, now
`BKE_undosys_step_load_data_ex` is the only place where all the complex
logic of undo/redo loop (to handle several steps in a row) is placed. We also
only use a single loop there, instead of the two existing ones in
previous code.
Note that here we consider that when we are loading the current active
step, we are undoing. This makes sense in that doing so //may// undo
some changes (ideally it should never do so), but should never, ever
redo anything.
`BKE_undosys_step_load_from_index` also gets heavily simplified, it's
not basically a shallow wrapper around
`BKE_undosys_step_load_from_index`.
And some general update of variable names, commenting, etc.
Part of T83806.
Differential Revision: https://developer.blender.org/D10227
2021-01-27 16:42:50 +01:00
|
|
|
CLOG_ERROR(&LOG, "Step name='%s' cannot be undone", undo_name);
|
|
|
|
|
|
|
|
|
|
return OPERATOR_CANCELLED;
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-23 00:32:39 +01:00
|
|
|
const int undo_dir_i = BKE_undosys_step_calc_direction(
|
|
|
|
|
wm->undo_stack, undo_step_target, nullptr);
|
BKE UndoSys refactor: deduplicate and simplify code, sanitize naming.
Now we only use 'undo' or 'redo' in function names when the direction is
clear (and we assert about it). Otherwise, use 'load' instead.
When passing an undo step to BKE functions, consider calling code has
done its work and is actually passing the target step (i.e. the final
step intended to be loaded), instead of assuming we have to load the
step before/after it.
Also deduplicate and simplify a lot of core undo code in BKE, now
`BKE_undosys_step_load_data_ex` is the only place where all the complex
logic of undo/redo loop (to handle several steps in a row) is placed. We also
only use a single loop there, instead of the two existing ones in
previous code.
Note that here we consider that when we are loading the current active
step, we are undoing. This makes sense in that doing so //may// undo
some changes (ideally it should never do so), but should never, ever
redo anything.
`BKE_undosys_step_load_from_index` also gets heavily simplified, it's
not basically a shallow wrapper around
`BKE_undosys_step_load_from_index`.
And some general update of variable names, commenting, etc.
Part of T83806.
Differential Revision: https://developer.blender.org/D10227
2021-01-27 16:42:50 +01:00
|
|
|
BLI_assert(ELEM(undo_dir_i, -1, 1));
|
|
|
|
|
const enum eUndoStepDir undo_dir = (undo_dir_i == -1) ? STEP_UNDO : STEP_REDO;
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
|
|
|
|
|
CLOG_INFO(&LOG,
|
|
|
|
|
1,
|
BKE UndoSys refactor: deduplicate and simplify code, sanitize naming.
Now we only use 'undo' or 'redo' in function names when the direction is
clear (and we assert about it). Otherwise, use 'load' instead.
When passing an undo step to BKE functions, consider calling code has
done its work and is actually passing the target step (i.e. the final
step intended to be loaded), instead of assuming we have to load the
step before/after it.
Also deduplicate and simplify a lot of core undo code in BKE, now
`BKE_undosys_step_load_data_ex` is the only place where all the complex
logic of undo/redo loop (to handle several steps in a row) is placed. We also
only use a single loop there, instead of the two existing ones in
previous code.
Note that here we consider that when we are loading the current active
step, we are undoing. This makes sense in that doing so //may// undo
some changes (ideally it should never do so), but should never, ever
redo anything.
`BKE_undosys_step_load_from_index` also gets heavily simplified, it's
not basically a shallow wrapper around
`BKE_undosys_step_load_from_index`.
And some general update of variable names, commenting, etc.
Part of T83806.
Differential Revision: https://developer.blender.org/D10227
2021-01-27 16:42:50 +01:00
|
|
|
"name='%s', found direction=%s",
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
undo_name,
|
BKE UndoSys refactor: deduplicate and simplify code, sanitize naming.
Now we only use 'undo' or 'redo' in function names when the direction is
clear (and we assert about it). Otherwise, use 'load' instead.
When passing an undo step to BKE functions, consider calling code has
done its work and is actually passing the target step (i.e. the final
step intended to be loaded), instead of assuming we have to load the
step before/after it.
Also deduplicate and simplify a lot of core undo code in BKE, now
`BKE_undosys_step_load_data_ex` is the only place where all the complex
logic of undo/redo loop (to handle several steps in a row) is placed. We also
only use a single loop there, instead of the two existing ones in
previous code.
Note that here we consider that when we are loading the current active
step, we are undoing. This makes sense in that doing so //may// undo
some changes (ideally it should never do so), but should never, ever
redo anything.
`BKE_undosys_step_load_from_index` also gets heavily simplified, it's
not basically a shallow wrapper around
`BKE_undosys_step_load_from_index`.
And some general update of variable names, commenting, etc.
Part of T83806.
Differential Revision: https://developer.blender.org/D10227
2021-01-27 16:42:50 +01:00
|
|
|
(undo_dir == STEP_UNDO) ? "STEP_UNDO" : "STEP_REDO");
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
|
|
|
|
|
ed_undo_step_pre(C, wm, undo_dir, reports);
|
|
|
|
|
|
2023-01-23 00:32:39 +01:00
|
|
|
BKE_undosys_step_load_data_ex(wm->undo_stack, C, undo_step_target, nullptr, true);
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
|
|
|
|
|
ed_undo_step_post(C, wm, undo_dir, reports);
|
|
|
|
|
|
|
|
|
|
return OPERATOR_FINISHED;
|
2019-06-07 15:30:49 +10:00
|
|
|
}
|
|
|
|
|
|
2021-04-09 18:47:10 +10:00
|
|
|
/**
|
|
|
|
|
* Load the step matching given index in the stack.
|
|
|
|
|
* May undo or redo several steps at once.
|
|
|
|
|
* The target step will be the one indicated by the given index.
|
|
|
|
|
*/
|
2021-01-14 11:44:16 +01:00
|
|
|
static int ed_undo_step_by_index(bContext *C, const int undo_index, ReportList *reports)
|
2019-06-07 15:30:49 +10:00
|
|
|
{
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
BLI_assert(undo_index >= 0);
|
|
|
|
|
|
|
|
|
|
/* FIXME: See comments in `ed_undo_step_direction`. */
|
|
|
|
|
if (ED_gpencil_session_active()) {
|
2021-07-15 18:23:28 +10:00
|
|
|
BLI_assert_msg(0, "Not implemented currently.");
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
|
|
|
|
const int active_step_index = BLI_findindex(&wm->undo_stack->steps, wm->undo_stack->step_active);
|
2021-12-16 23:31:20 +11:00
|
|
|
if (undo_index == active_step_index) {
|
|
|
|
|
return OPERATOR_CANCELLED;
|
|
|
|
|
}
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
const enum eUndoStepDir undo_dir = (undo_index < active_step_index) ? STEP_UNDO : STEP_REDO;
|
|
|
|
|
|
|
|
|
|
CLOG_INFO(&LOG,
|
|
|
|
|
1,
|
|
|
|
|
"index='%d', found direction=%s",
|
|
|
|
|
undo_index,
|
|
|
|
|
(undo_dir == STEP_UNDO) ? "STEP_UNDO" : "STEP_REDO");
|
|
|
|
|
|
|
|
|
|
ed_undo_step_pre(C, wm, undo_dir, reports);
|
|
|
|
|
|
BKE UndoSys refactor: deduplicate and simplify code, sanitize naming.
Now we only use 'undo' or 'redo' in function names when the direction is
clear (and we assert about it). Otherwise, use 'load' instead.
When passing an undo step to BKE functions, consider calling code has
done its work and is actually passing the target step (i.e. the final
step intended to be loaded), instead of assuming we have to load the
step before/after it.
Also deduplicate and simplify a lot of core undo code in BKE, now
`BKE_undosys_step_load_data_ex` is the only place where all the complex
logic of undo/redo loop (to handle several steps in a row) is placed. We also
only use a single loop there, instead of the two existing ones in
previous code.
Note that here we consider that when we are loading the current active
step, we are undoing. This makes sense in that doing so //may// undo
some changes (ideally it should never do so), but should never, ever
redo anything.
`BKE_undosys_step_load_from_index` also gets heavily simplified, it's
not basically a shallow wrapper around
`BKE_undosys_step_load_from_index`.
And some general update of variable names, commenting, etc.
Part of T83806.
Differential Revision: https://developer.blender.org/D10227
2021-01-27 16:42:50 +01:00
|
|
|
BKE_undosys_step_load_from_index(wm->undo_stack, C, undo_index);
|
ed_undo refactor: split/remove `ed_undo_step_impl`.
This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.
Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.
Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.
Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.
Note: This is part of on-going refactor work on undo system, see T83806.
Differential Revision: https://developer.blender.org/D10112
2021-01-14 16:15:30 +01:00
|
|
|
|
|
|
|
|
ed_undo_step_post(C, wm, undo_dir, reports);
|
|
|
|
|
|
|
|
|
|
return OPERATOR_FINISHED;
|
2019-06-07 15:30:49 +10:00
|
|
|
}
|
|
|
|
|
|
Implement grouped undo option for operators
This option makes an operator to not push a task to the undo stack if the previous stored elemen is the same operator or part of the same undo group.
The main usage is for animation, so you can change frames to inspect the
poses, and revert the previous pose without having to roll back tons of
"change frame" operator, or even see the undo stack full.
This complements rB13ee9b8e
Design with help by Sergey Sharybin.
Reviewers: sergey, mont29
Reviewed By: mont29, sergey
Subscribers: pyc0d3r, hjalti, Severin, lowercase, brecht, monio, aligorith, hadrien, jbakker
Differential Revision: https://developer.blender.org/D2330
2016-11-15 11:50:11 +01:00
|
|
|
void ED_undo_grouped_push(bContext *C, const char *str)
|
|
|
|
|
{
|
|
|
|
|
/* do nothing if previous undo task is the same as this one (or from the same undo group) */
|
2018-06-13 18:22:17 +02:00
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
|
|
|
|
const UndoStep *us = wm->undo_stack->step_active;
|
|
|
|
|
if (us && STREQ(str, us->name)) {
|
|
|
|
|
BKE_undosys_stack_clear_active(wm->undo_stack);
|
Implement grouped undo option for operators
This option makes an operator to not push a task to the undo stack if the previous stored elemen is the same operator or part of the same undo group.
The main usage is for animation, so you can change frames to inspect the
poses, and revert the previous pose without having to roll back tons of
"change frame" operator, or even see the undo stack full.
This complements rB13ee9b8e
Design with help by Sergey Sharybin.
Reviewers: sergey, mont29
Reviewed By: mont29, sergey
Subscribers: pyc0d3r, hjalti, Severin, lowercase, brecht, monio, aligorith, hadrien, jbakker
Differential Revision: https://developer.blender.org/D2330
2016-11-15 11:50:11 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Implement grouped undo option for operators
This option makes an operator to not push a task to the undo stack if the previous stored elemen is the same operator or part of the same undo group.
The main usage is for animation, so you can change frames to inspect the
poses, and revert the previous pose without having to roll back tons of
"change frame" operator, or even see the undo stack full.
This complements rB13ee9b8e
Design with help by Sergey Sharybin.
Reviewers: sergey, mont29
Reviewed By: mont29, sergey
Subscribers: pyc0d3r, hjalti, Severin, lowercase, brecht, monio, aligorith, hadrien, jbakker
Differential Revision: https://developer.blender.org/D2330
2016-11-15 11:50:11 +01:00
|
|
|
/* push as usual */
|
|
|
|
|
ED_undo_push(C, str);
|
|
|
|
|
}
|
|
|
|
|
|
2009-02-04 11:52:16 +00:00
|
|
|
void ED_undo_pop(bContext *C)
|
|
|
|
|
{
|
2023-01-23 00:32:39 +01:00
|
|
|
ed_undo_step_direction(C, STEP_UNDO, nullptr);
|
2009-02-04 11:52:16 +00:00
|
|
|
}
|
2009-04-15 17:53:12 +00:00
|
|
|
void ED_undo_redo(bContext *C)
|
|
|
|
|
{
|
2023-01-23 00:32:39 +01:00
|
|
|
ed_undo_step_direction(C, STEP_REDO, nullptr);
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ED_undo_push_op(bContext *C, wmOperator *op)
|
|
|
|
|
{
|
|
|
|
|
/* in future, get undo string info? */
|
|
|
|
|
ED_undo_push(C, op->type->name);
|
|
|
|
|
}
|
|
|
|
|
|
Implement grouped undo option for operators
This option makes an operator to not push a task to the undo stack if the previous stored elemen is the same operator or part of the same undo group.
The main usage is for animation, so you can change frames to inspect the
poses, and revert the previous pose without having to roll back tons of
"change frame" operator, or even see the undo stack full.
This complements rB13ee9b8e
Design with help by Sergey Sharybin.
Reviewers: sergey, mont29
Reviewed By: mont29, sergey
Subscribers: pyc0d3r, hjalti, Severin, lowercase, brecht, monio, aligorith, hadrien, jbakker
Differential Revision: https://developer.blender.org/D2330
2016-11-15 11:50:11 +01:00
|
|
|
void ED_undo_grouped_push_op(bContext *C, wmOperator *op)
|
|
|
|
|
{
|
|
|
|
|
if (op->type->undo_group[0] != '\0') {
|
|
|
|
|
ED_undo_grouped_push(C, op->type->undo_group);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
ED_undo_grouped_push(C, op->type->name);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
void ED_undo_pop_op(bContext *C, wmOperator *op)
|
|
|
|
|
{
|
|
|
|
|
/* search back a couple of undo's, in case something else added pushes */
|
2019-06-07 15:30:49 +10:00
|
|
|
ed_undo_step_by_name(C, op->type->name, op->reports);
|
2009-04-15 17:53:12 +00:00
|
|
|
}
|
2009-02-04 11:52:16 +00:00
|
|
|
|
2015-04-18 15:41:12 +02:00
|
|
|
bool ED_undo_is_valid(const bContext *C, const char *undoname)
|
2011-01-12 18:00:23 +00:00
|
|
|
{
|
2018-03-19 14:17:59 +01:00
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
|
|
|
|
return BKE_undosys_stack_has_undo(wm->undo_stack, undoname);
|
2011-01-12 18:00:23 +00:00
|
|
|
}
|
|
|
|
|
|
2019-01-19 00:48:00 +11:00
|
|
|
bool ED_undo_is_memfile_compatible(const bContext *C)
|
|
|
|
|
{
|
2023-02-12 14:37:16 +11:00
|
|
|
/* Some modes don't co-exist with memfile undo, disable their use: #60593
|
2019-01-19 00:48:00 +11:00
|
|
|
* (this matches 2.7x behavior). */
|
2022-09-14 21:33:51 +02:00
|
|
|
const Scene *scene = CTX_data_scene(C);
|
2019-01-19 00:48:00 +11:00
|
|
|
ViewLayer *view_layer = CTX_data_view_layer(C);
|
2023-01-23 00:32:39 +01:00
|
|
|
if (view_layer != nullptr) {
|
2022-09-14 21:33:51 +02:00
|
|
|
BKE_view_layer_synced_ensure(scene, view_layer);
|
2022-09-01 10:00:53 +02:00
|
|
|
Object *obact = BKE_view_layer_active_object_get(view_layer);
|
2023-01-23 00:32:39 +01:00
|
|
|
if (obact != nullptr) {
|
2019-11-07 16:52:03 +11:00
|
|
|
if (obact->mode & OB_MODE_EDIT) {
|
2019-01-19 00:48:00 +11:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-03 08:36:28 +10:00
|
|
|
bool ED_undo_is_legacy_compatible_for_property(bContext *C, ID *id)
|
2019-07-05 13:46:48 +10:00
|
|
|
{
|
2022-09-14 21:33:51 +02:00
|
|
|
const Scene *scene = CTX_data_scene(C);
|
2019-07-05 13:46:48 +10:00
|
|
|
ViewLayer *view_layer = CTX_data_view_layer(C);
|
2023-01-23 00:32:39 +01:00
|
|
|
if (view_layer != nullptr) {
|
2022-09-14 21:33:51 +02:00
|
|
|
BKE_view_layer_synced_ensure(scene, view_layer);
|
2022-09-01 10:00:53 +02:00
|
|
|
Object *obact = BKE_view_layer_active_object_get(view_layer);
|
2023-01-23 00:32:39 +01:00
|
|
|
if (obact != nullptr) {
|
2019-07-05 13:46:48 +10:00
|
|
|
if (obact->mode & OB_MODE_ALL_PAINT) {
|
|
|
|
|
/* Don't store property changes when painting
|
|
|
|
|
* (only do undo pushes on brush strokes which each paint operator handles on its own). */
|
|
|
|
|
CLOG_INFO(&LOG, 1, "skipping undo for paint-mode");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2020-07-03 17:30:31 +02:00
|
|
|
if (obact->mode & OB_MODE_EDIT) {
|
2023-01-23 00:32:39 +01:00
|
|
|
if ((id == nullptr) || (obact->data == nullptr) ||
|
2024-01-02 18:12:54 +01:00
|
|
|
(GS(id->name) != GS(((ID *)obact->data)->name)))
|
|
|
|
|
{
|
2019-07-05 13:46:48 +10:00
|
|
|
/* No undo push on id type mismatch in edit-mode. */
|
|
|
|
|
CLOG_INFO(&LOG, 1, "skipping undo for edit-mode");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-02 19:37:22 +10:00
|
|
|
UndoStack *ED_undo_stack_get()
|
2018-04-03 08:35:42 +02:00
|
|
|
{
|
2023-01-23 00:32:39 +01:00
|
|
|
wmWindowManager *wm = static_cast<wmWindowManager *>(G_MAIN->wm.first);
|
2018-04-03 08:35:42 +02:00
|
|
|
return wm->undo_stack;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-02 15:02:08 +02:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Undo, Undo Push & Redo Operators
|
|
|
|
|
* \{ */
|
|
|
|
|
|
2021-12-16 23:31:20 +11:00
|
|
|
/**
|
|
|
|
|
* Refresh to run after user activated undo/redo actions.
|
|
|
|
|
*/
|
|
|
|
|
static void ed_undo_refresh_for_op(bContext *C)
|
|
|
|
|
{
|
|
|
|
|
/* The "last operator" should disappear, later we can tie this with undo stack nicer. */
|
|
|
|
|
WM_operator_stack_clear(CTX_wm_manager(C));
|
|
|
|
|
|
|
|
|
|
/* Keep button under the cursor active. */
|
|
|
|
|
WM_event_add_mousemove(CTX_wm_window(C));
|
|
|
|
|
|
|
|
|
|
ED_outliner_select_sync_from_all_tag(C);
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-17 16:43:02 +02:00
|
|
|
static int ed_undo_exec(bContext *C, wmOperator *op)
|
2009-01-01 13:15:35 +00:00
|
|
|
{
|
2012-06-01 11:46:25 +00:00
|
|
|
/* "last operator" should disappear, later we can tie this with undo stack nicer */
|
2011-05-18 10:56:26 +00:00
|
|
|
WM_operator_stack_clear(CTX_wm_manager(C));
|
2021-01-14 09:49:22 +11:00
|
|
|
int ret = ed_undo_step_direction(C, STEP_UNDO, op->reports);
|
2018-09-13 23:20:04 +10:00
|
|
|
if (ret & OPERATOR_FINISHED) {
|
2021-12-16 23:31:20 +11:00
|
|
|
ed_undo_refresh_for_op(C);
|
2018-09-13 23:20:04 +10:00
|
|
|
}
|
|
|
|
|
return ret;
|
2009-01-01 13:15:35 +00:00
|
|
|
}
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
|
2011-02-22 02:42:19 +00:00
|
|
|
static int ed_undo_push_exec(bContext *C, wmOperator *op)
|
|
|
|
|
{
|
2019-02-08 10:15:11 +11:00
|
|
|
if (G.background) {
|
2023-02-12 14:37:16 +11:00
|
|
|
/* Exception for background mode, see: #60934.
|
2021-07-03 23:08:40 +10:00
|
|
|
* NOTE: since the undo stack isn't initialized on startup, background mode behavior
|
2019-02-08 10:15:11 +11:00
|
|
|
* won't match regular usage, this is just for scripts to do explicit undo pushes. */
|
|
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
2023-01-23 00:32:39 +01:00
|
|
|
if (wm->undo_stack == nullptr) {
|
2019-02-08 10:15:11 +11:00
|
|
|
wm->undo_stack = BKE_undosys_stack_create();
|
|
|
|
|
}
|
|
|
|
|
}
|
2012-09-10 01:55:58 +00:00
|
|
|
char str[BKE_UNDO_STR_MAX];
|
2011-02-22 02:42:19 +00:00
|
|
|
RNA_string_get(op->ptr, "message", str);
|
|
|
|
|
ED_undo_push(C, str);
|
|
|
|
|
return OPERATOR_FINISHED;
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-17 16:43:02 +02:00
|
|
|
static int ed_redo_exec(bContext *C, wmOperator *op)
|
2008-12-30 19:01:12 +00:00
|
|
|
{
|
2021-01-14 09:49:22 +11:00
|
|
|
int ret = ed_undo_step_direction(C, STEP_REDO, op->reports);
|
2018-09-13 23:20:04 +10:00
|
|
|
if (ret & OPERATOR_FINISHED) {
|
2021-12-16 23:31:20 +11:00
|
|
|
ed_undo_refresh_for_op(C);
|
2018-09-13 23:20:04 +10:00
|
|
|
}
|
|
|
|
|
return ret;
|
2008-12-30 19:01:12 +00:00
|
|
|
}
|
|
|
|
|
|
2023-01-23 00:32:39 +01:00
|
|
|
static int ed_undo_redo_exec(bContext *C, wmOperator * /*op*/)
|
2016-12-29 12:38:20 +01:00
|
|
|
{
|
|
|
|
|
wmOperator *last_op = WM_operator_last_redo(C);
|
2018-09-13 23:20:04 +10:00
|
|
|
int ret = ED_undo_operator_repeat(C, last_op);
|
|
|
|
|
ret = ret ? OPERATOR_FINISHED : OPERATOR_CANCELLED;
|
|
|
|
|
if (ret & OPERATOR_FINISHED) {
|
|
|
|
|
/* Keep button under the cursor active. */
|
2020-03-06 16:22:28 +01:00
|
|
|
WM_event_add_mousemove(CTX_wm_window(C));
|
2018-09-13 23:20:04 +10:00
|
|
|
}
|
|
|
|
|
return ret;
|
2016-12-29 12:38:20 +01:00
|
|
|
}
|
|
|
|
|
|
2023-02-12 14:37:16 +11:00
|
|
|
/* Disable in background mode, we could support if it's useful, #60934. */
|
2019-02-01 14:05:33 +11:00
|
|
|
|
|
|
|
|
static bool ed_undo_is_init_poll(bContext *C)
|
|
|
|
|
{
|
|
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
2023-01-23 00:32:39 +01:00
|
|
|
if (wm->undo_stack == nullptr) {
|
2021-09-02 15:29:33 +10:00
|
|
|
/* This message is intended for Python developers,
|
|
|
|
|
* it will be part of the exception when attempting to call undo in background mode. */
|
|
|
|
|
CTX_wm_operator_poll_msg_set(
|
|
|
|
|
C,
|
2021-09-13 12:40:10 +02:00
|
|
|
"Undo disabled at startup in background-mode "
|
|
|
|
|
"(call `ed.undo_push()` to explicitly initialize the undo-system)");
|
2019-02-01 14:05:33 +11:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool ed_undo_is_init_and_screenactive_poll(bContext *C)
|
|
|
|
|
{
|
|
|
|
|
if (ed_undo_is_init_poll(C) == false) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return ED_operator_screenactive(C);
|
|
|
|
|
}
|
|
|
|
|
|
2018-07-02 11:47:00 +02:00
|
|
|
static bool ed_undo_redo_poll(bContext *C)
|
2017-07-01 10:50:29 +03:00
|
|
|
{
|
|
|
|
|
wmOperator *last_op = WM_operator_last_redo(C);
|
2019-02-01 14:05:33 +11:00
|
|
|
return (last_op && ed_undo_is_init_and_screenactive_poll(C) &&
|
|
|
|
|
WM_operator_check_ui_enabled(C, last_op->type->name));
|
2017-07-01 10:50:29 +03:00
|
|
|
}
|
2008-12-30 19:01:12 +00:00
|
|
|
|
2020-01-28 09:33:41 -08:00
|
|
|
static bool ed_undo_poll(bContext *C)
|
|
|
|
|
{
|
|
|
|
|
if (!ed_undo_is_init_and_screenactive_poll(C)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
UndoStack *undo_stack = CTX_wm_manager(C)->undo_stack;
|
2023-01-23 00:32:39 +01:00
|
|
|
return (undo_stack->step_active != nullptr) && (undo_stack->step_active->prev != nullptr);
|
2020-01-28 09:33:41 -08:00
|
|
|
}
|
|
|
|
|
|
2008-12-31 18:52:15 +00:00
|
|
|
void ED_OT_undo(wmOperatorType *ot)
|
|
|
|
|
{
|
|
|
|
|
/* identifiers */
|
2012-03-22 07:26:09 +00:00
|
|
|
ot->name = "Undo";
|
|
|
|
|
ot->description = "Undo previous action";
|
|
|
|
|
ot->idname = "ED_OT_undo";
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2008-12-31 18:52:15 +00:00
|
|
|
/* api callbacks */
|
2012-03-22 07:26:09 +00:00
|
|
|
ot->exec = ed_undo_exec;
|
2020-01-28 09:33:41 -08:00
|
|
|
ot->poll = ed_undo_poll;
|
2008-12-31 18:52:15 +00:00
|
|
|
}
|
|
|
|
|
|
2011-02-22 02:42:19 +00:00
|
|
|
void ED_OT_undo_push(wmOperatorType *ot)
|
|
|
|
|
{
|
|
|
|
|
/* identifiers */
|
2012-03-22 07:26:09 +00:00
|
|
|
ot->name = "Undo Push";
|
|
|
|
|
ot->description = "Add an undo state (internal use only)";
|
|
|
|
|
ot->idname = "ED_OT_undo_push";
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-02-22 02:42:19 +00:00
|
|
|
/* api callbacks */
|
2012-03-22 07:26:09 +00:00
|
|
|
ot->exec = ed_undo_push_exec;
|
2019-02-08 10:15:11 +11:00
|
|
|
/* Unlike others undo operators this initializes undo stack. */
|
|
|
|
|
ot->poll = ED_operator_screenactive;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-22 07:26:09 +00:00
|
|
|
ot->flag = OPTYPE_INTERNAL;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-09-10 01:55:58 +00:00
|
|
|
RNA_def_string(ot->srna,
|
|
|
|
|
"message",
|
|
|
|
|
"Add an undo step *function may be moved*",
|
|
|
|
|
BKE_UNDO_STR_MAX,
|
|
|
|
|
"Undo Message",
|
|
|
|
|
"");
|
2011-02-22 02:42:19 +00:00
|
|
|
}
|
|
|
|
|
|
2020-01-28 09:33:41 -08:00
|
|
|
static bool ed_redo_poll(bContext *C)
|
|
|
|
|
{
|
|
|
|
|
if (!ed_undo_is_init_and_screenactive_poll(C)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
UndoStack *undo_stack = CTX_wm_manager(C)->undo_stack;
|
2023-01-23 00:32:39 +01:00
|
|
|
return (undo_stack->step_active != nullptr) && (undo_stack->step_active->next != nullptr);
|
2020-01-28 09:33:41 -08:00
|
|
|
}
|
|
|
|
|
|
2008-12-31 18:52:15 +00:00
|
|
|
void ED_OT_redo(wmOperatorType *ot)
|
|
|
|
|
{
|
|
|
|
|
/* identifiers */
|
2012-03-22 07:26:09 +00:00
|
|
|
ot->name = "Redo";
|
|
|
|
|
ot->description = "Redo previous action";
|
|
|
|
|
ot->idname = "ED_OT_redo";
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2008-12-31 18:52:15 +00:00
|
|
|
/* api callbacks */
|
2012-03-22 07:26:09 +00:00
|
|
|
ot->exec = ed_redo_exec;
|
2020-01-28 09:33:41 -08:00
|
|
|
ot->poll = ed_redo_poll;
|
2008-12-31 18:52:15 +00:00
|
|
|
}
|
|
|
|
|
|
2016-12-29 12:38:20 +01:00
|
|
|
void ED_OT_undo_redo(wmOperatorType *ot)
|
|
|
|
|
{
|
|
|
|
|
/* identifiers */
|
|
|
|
|
ot->name = "Undo and Redo";
|
|
|
|
|
ot->description = "Undo and redo previous action";
|
|
|
|
|
ot->idname = "ED_OT_undo_redo";
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-12-29 12:38:20 +01:00
|
|
|
/* api callbacks */
|
|
|
|
|
ot->exec = ed_undo_redo_exec;
|
2017-07-01 10:50:29 +03:00
|
|
|
ot->poll = ed_undo_redo_poll;
|
2016-12-29 12:38:20 +01:00
|
|
|
}
|
2008-12-31 18:52:15 +00:00
|
|
|
|
2018-04-02 15:02:08 +02:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Operator Repeat
|
|
|
|
|
* \{ */
|
|
|
|
|
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
int ED_undo_operator_repeat(bContext *C, wmOperator *op)
|
2010-12-15 04:06:19 +00:00
|
|
|
{
|
2012-03-30 10:00:20 +00:00
|
|
|
int ret = 0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-24 06:38:07 +00:00
|
|
|
if (op) {
|
2018-04-05 13:41:52 +02:00
|
|
|
CLOG_INFO(&LOG, 1, "idname='%s'", op->type->idname);
|
2012-03-30 10:00:20 +00:00
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
2023-07-25 12:42:42 +02:00
|
|
|
const ScrArea *area = CTX_wm_area(C);
|
2023-06-03 08:36:28 +10:00
|
|
|
Scene *scene = CTX_data_scene(C);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-06-14 21:55:40 +02:00
|
|
|
/* keep in sync with logic in view3d_panel_operator_redo() */
|
2020-04-03 12:51:03 +02:00
|
|
|
ARegion *region_orig = CTX_wm_region(C);
|
2023-07-25 12:42:42 +02:00
|
|
|
/* If the redo is called from a HUD, this knows about the region type the operator was
|
|
|
|
|
* initially called in, so attempt to restore that. */
|
|
|
|
|
ARegion *redo_region_from_hud = (region_orig->regiontype == RGN_TYPE_HUD) ?
|
|
|
|
|
ED_area_type_hud_redo_region_find(area, region_orig) :
|
|
|
|
|
nullptr;
|
|
|
|
|
ARegion *region_repeat = redo_region_from_hud ? redo_region_from_hud :
|
|
|
|
|
BKE_area_find_region_active_win(area);
|
|
|
|
|
|
|
|
|
|
if (region_repeat) {
|
|
|
|
|
CTX_wm_region_set(C, region_repeat);
|
2018-06-14 21:55:40 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-07-16 11:45:52 +10:00
|
|
|
if (WM_operator_repeat_check(C, op) && WM_operator_poll(C, op->type) &&
|
2021-07-03 23:08:40 +10:00
|
|
|
/* NOTE: undo/redo can't run if there are jobs active,
|
2019-04-18 07:21:26 +02:00
|
|
|
* check for screen jobs only so jobs like material/texture/world preview
|
2023-02-12 14:37:16 +11:00
|
|
|
* (which copy their data), won't stop redo, see #29579.
|
2019-04-18 07:21:26 +02:00
|
|
|
*
|
2021-07-03 23:08:40 +10:00
|
|
|
* NOTE: WM_operator_check_ui_enabled() jobs test _must_ stay in sync with this. */
|
2014-01-12 22:05:24 +11:00
|
|
|
(WM_jobs_test(wm, scene, WM_JOB_TYPE_ANY) == 0))
|
|
|
|
|
{
|
2010-12-15 04:06:19 +00:00
|
|
|
int retval;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:19:45 +10:00
|
|
|
if (G.debug & G_DEBUG) {
|
2010-12-15 04:06:19 +00:00
|
|
|
printf("redo_cb: operator redo %s\n", op->type->name);
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-03-15 05:16:07 +11:00
|
|
|
WM_operator_free_all_after(wm, op);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2010-12-15 04:06:19 +00:00
|
|
|
ED_undo_pop_op(C, op);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-24 06:38:07 +00:00
|
|
|
if (op->type->check) {
|
2014-06-15 01:40:15 +10:00
|
|
|
if (op->type->check(C, op)) {
|
|
|
|
|
/* check for popup and re-layout buttons */
|
2020-04-03 12:51:03 +02:00
|
|
|
ARegion *region_menu = CTX_wm_menu(C);
|
|
|
|
|
if (region_menu) {
|
|
|
|
|
ED_region_tag_refresh_ui(region_menu);
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2014-06-15 01:40:15 +10:00
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-30 10:00:20 +00:00
|
|
|
retval = WM_operator_repeat(C, op);
|
|
|
|
|
if ((retval & OPERATOR_FINISHED) == 0) {
|
2019-04-22 09:19:45 +10:00
|
|
|
if (G.debug & G_DEBUG) {
|
2010-12-15 04:06:19 +00:00
|
|
|
printf("redo_cb: operator redo failed: %s, return %d\n", op->type->name, retval);
|
2019-04-22 09:19:45 +10:00
|
|
|
}
|
2010-12-15 04:06:19 +00:00
|
|
|
ED_undo_redo(C);
|
|
|
|
|
}
|
|
|
|
|
else {
|
2012-03-30 10:00:20 +00:00
|
|
|
ret = 1;
|
2010-12-15 04:06:19 +00:00
|
|
|
}
|
|
|
|
|
}
|
2011-07-26 13:05:22 +00:00
|
|
|
else {
|
2012-03-31 00:59:17 +00:00
|
|
|
if (G.debug & G_DEBUG) {
|
2011-07-26 13:05:22 +00:00
|
|
|
printf("redo_cb: WM_operator_repeat_check returned false %s\n", op->type->name);
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-06-14 21:55:40 +02:00
|
|
|
/* set region back */
|
2020-04-03 12:51:03 +02:00
|
|
|
CTX_wm_region_set(C, region_orig);
|
2010-12-15 04:06:19 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2023-01-23 00:32:39 +01:00
|
|
|
CLOG_WARN(&LOG, "called with nullptr 'op'");
|
2010-12-15 04:06:19 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2010-12-15 04:06:19 +00:00
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-23 00:32:39 +01:00
|
|
|
void ED_undo_operator_repeat_cb(bContext *C, void *arg_op, void * /*arg_unused*/)
|
2010-12-15 04:06:19 +00:00
|
|
|
{
|
|
|
|
|
ED_undo_operator_repeat(C, (wmOperator *)arg_op);
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-23 00:32:39 +01:00
|
|
|
void ED_undo_operator_repeat_cb_evt(bContext *C, void *arg_op, int /*arg_unused*/)
|
2010-12-15 04:06:19 +00:00
|
|
|
{
|
|
|
|
|
ED_undo_operator_repeat(C, (wmOperator *)arg_op);
|
|
|
|
|
}
|
Code holiday commit:
- fix: user pref, window title was reset to 'Blender' on tab usage
- Undo history menu back:
- name "Undo History"
- hotkey alt+ctrl+z (alt+apple+z for mac)
- works like 2.4x, only for global undo, editmode and particle edit.
- Menu scroll
- for small windows or screens, popup menus now allow to display
all items, using internal scrolling
- works with a timer, scrolling 10 items per second when mouse
is over the top or bottom arrow
- if menu is too big to display, it now draws to top or bottom,
based on largest available space.
- also works for hotkey driven pop up menus.
- User pref "DPI" follows widget/layout size
- widgets & headers now become bigger and smaller, to match
'dpi' font sizes. Works well to match UI to monitor size.
- note that icons can get fuzzy, we need better mipmaps for it
2011-06-04 17:03:46 +00:00
|
|
|
|
2018-04-02 15:02:08 +02:00
|
|
|
/** \} */
|
Code holiday commit:
- fix: user pref, window title was reset to 'Blender' on tab usage
- Undo history menu back:
- name "Undo History"
- hotkey alt+ctrl+z (alt+apple+z for mac)
- works like 2.4x, only for global undo, editmode and particle edit.
- Menu scroll
- for small windows or screens, popup menus now allow to display
all items, using internal scrolling
- works with a timer, scrolling 10 items per second when mouse
is over the top or bottom arrow
- if menu is too big to display, it now draws to top or bottom,
based on largest available space.
- also works for hotkey driven pop up menus.
- User pref "DPI" follows widget/layout size
- widgets & headers now become bigger and smaller, to match
'dpi' font sizes. Works well to match UI to monitor size.
- note that icons can get fuzzy, we need better mipmaps for it
2011-06-04 17:03:46 +00:00
|
|
|
|
2018-04-02 15:02:08 +02:00
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Undo History Operator
|
2021-12-17 15:54:05 +11:00
|
|
|
*
|
|
|
|
|
* See `TOPBAR_MT_undo_history` which is used to access this operator.
|
2018-04-02 15:02:08 +02:00
|
|
|
* \{ */
|
Code holiday commit:
- fix: user pref, window title was reset to 'Blender' on tab usage
- Undo history menu back:
- name "Undo History"
- hotkey alt+ctrl+z (alt+apple+z for mac)
- works like 2.4x, only for global undo, editmode and particle edit.
- Menu scroll
- for small windows or screens, popup menus now allow to display
all items, using internal scrolling
- works with a timer, scrolling 10 items per second when mouse
is over the top or bottom arrow
- if menu is too big to display, it now draws to top or bottom,
based on largest available space.
- also works for hotkey driven pop up menus.
- User pref "DPI" follows widget/layout size
- widgets & headers now become bigger and smaller, to match
'dpi' font sizes. Works well to match UI to monitor size.
- note that icons can get fuzzy, we need better mipmaps for it
2011-06-04 17:03:46 +00:00
|
|
|
|
2021-07-03 23:08:40 +10:00
|
|
|
/* NOTE: also check #ed_undo_step() in top if you change notifiers. */
|
Code holiday commit:
- fix: user pref, window title was reset to 'Blender' on tab usage
- Undo history menu back:
- name "Undo History"
- hotkey alt+ctrl+z (alt+apple+z for mac)
- works like 2.4x, only for global undo, editmode and particle edit.
- Menu scroll
- for small windows or screens, popup menus now allow to display
all items, using internal scrolling
- works with a timer, scrolling 10 items per second when mouse
is over the top or bottom arrow
- if menu is too big to display, it now draws to top or bottom,
based on largest available space.
- also works for hotkey driven pop up menus.
- User pref "DPI" follows widget/layout size
- widgets & headers now become bigger and smaller, to match
'dpi' font sizes. Works well to match UI to monitor size.
- note that icons can get fuzzy, we need better mipmaps for it
2011-06-04 17:03:46 +00:00
|
|
|
static int undo_history_exec(bContext *C, wmOperator *op)
|
|
|
|
|
{
|
2018-03-19 14:17:59 +01:00
|
|
|
PropertyRNA *prop = RNA_struct_find_property(op->ptr, "item");
|
|
|
|
|
if (RNA_property_is_set(op->ptr, prop)) {
|
2021-12-17 15:54:05 +11:00
|
|
|
const int item = RNA_property_int_get(op->ptr, prop);
|
2021-12-16 23:31:20 +11:00
|
|
|
const int ret = ed_undo_step_by_index(C, item, op->reports);
|
|
|
|
|
if (ret & OPERATOR_FINISHED) {
|
|
|
|
|
ed_undo_refresh_for_op(C);
|
|
|
|
|
|
2023-01-23 00:32:39 +01:00
|
|
|
WM_event_add_notifier(C, NC_WINDOW, nullptr);
|
2021-12-16 23:31:20 +11:00
|
|
|
return OPERATOR_FINISHED;
|
|
|
|
|
}
|
Code holiday commit:
- fix: user pref, window title was reset to 'Blender' on tab usage
- Undo history menu back:
- name "Undo History"
- hotkey alt+ctrl+z (alt+apple+z for mac)
- works like 2.4x, only for global undo, editmode and particle edit.
- Menu scroll
- for small windows or screens, popup menus now allow to display
all items, using internal scrolling
- works with a timer, scrolling 10 items per second when mouse
is over the top or bottom arrow
- if menu is too big to display, it now draws to top or bottom,
based on largest available space.
- also works for hotkey driven pop up menus.
- User pref "DPI" follows widget/layout size
- widgets & headers now become bigger and smaller, to match
'dpi' font sizes. Works well to match UI to monitor size.
- note that icons can get fuzzy, we need better mipmaps for it
2011-06-04 17:03:46 +00:00
|
|
|
}
|
|
|
|
|
return OPERATOR_CANCELLED;
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-23 00:32:39 +01:00
|
|
|
static int undo_history_invoke(bContext *C, wmOperator *op, const wmEvent * /*event*/)
|
2020-01-28 09:33:41 -08:00
|
|
|
{
|
2021-12-17 15:54:05 +11:00
|
|
|
PropertyRNA *prop = RNA_struct_find_property(op->ptr, "item");
|
|
|
|
|
if (RNA_property_is_set(op->ptr, prop)) {
|
|
|
|
|
return undo_history_exec(C, op);
|
2020-01-28 09:33:41 -08:00
|
|
|
}
|
2021-12-17 15:54:05 +11:00
|
|
|
|
|
|
|
|
WM_menu_name_call(C, "TOPBAR_MT_undo_history", WM_OP_INVOKE_DEFAULT);
|
|
|
|
|
return OPERATOR_FINISHED;
|
2020-01-28 09:33:41 -08:00
|
|
|
}
|
|
|
|
|
|
Code holiday commit:
- fix: user pref, window title was reset to 'Blender' on tab usage
- Undo history menu back:
- name "Undo History"
- hotkey alt+ctrl+z (alt+apple+z for mac)
- works like 2.4x, only for global undo, editmode and particle edit.
- Menu scroll
- for small windows or screens, popup menus now allow to display
all items, using internal scrolling
- works with a timer, scrolling 10 items per second when mouse
is over the top or bottom arrow
- if menu is too big to display, it now draws to top or bottom,
based on largest available space.
- also works for hotkey driven pop up menus.
- User pref "DPI" follows widget/layout size
- widgets & headers now become bigger and smaller, to match
'dpi' font sizes. Works well to match UI to monitor size.
- note that icons can get fuzzy, we need better mipmaps for it
2011-06-04 17:03:46 +00:00
|
|
|
void ED_OT_undo_history(wmOperatorType *ot)
|
|
|
|
|
{
|
|
|
|
|
/* identifiers */
|
2012-03-22 07:26:09 +00:00
|
|
|
ot->name = "Undo History";
|
|
|
|
|
ot->description = "Redo specific action in history";
|
|
|
|
|
ot->idname = "ED_OT_undo_history";
|
2018-04-02 15:02:08 +02:00
|
|
|
|
Code holiday commit:
- fix: user pref, window title was reset to 'Blender' on tab usage
- Undo history menu back:
- name "Undo History"
- hotkey alt+ctrl+z (alt+apple+z for mac)
- works like 2.4x, only for global undo, editmode and particle edit.
- Menu scroll
- for small windows or screens, popup menus now allow to display
all items, using internal scrolling
- works with a timer, scrolling 10 items per second when mouse
is over the top or bottom arrow
- if menu is too big to display, it now draws to top or bottom,
based on largest available space.
- also works for hotkey driven pop up menus.
- User pref "DPI" follows widget/layout size
- widgets & headers now become bigger and smaller, to match
'dpi' font sizes. Works well to match UI to monitor size.
- note that icons can get fuzzy, we need better mipmaps for it
2011-06-04 17:03:46 +00:00
|
|
|
/* api callbacks */
|
|
|
|
|
ot->invoke = undo_history_invoke;
|
2012-03-22 07:26:09 +00:00
|
|
|
ot->exec = undo_history_exec;
|
2021-12-17 15:54:05 +11:00
|
|
|
ot->poll = ed_undo_is_init_and_screenactive_poll;
|
Code holiday commit:
- fix: user pref, window title was reset to 'Blender' on tab usage
- Undo history menu back:
- name "Undo History"
- hotkey alt+ctrl+z (alt+apple+z for mac)
- works like 2.4x, only for global undo, editmode and particle edit.
- Menu scroll
- for small windows or screens, popup menus now allow to display
all items, using internal scrolling
- works with a timer, scrolling 10 items per second when mouse
is over the top or bottom arrow
- if menu is too big to display, it now draws to top or bottom,
based on largest available space.
- also works for hotkey driven pop up menus.
- User pref "DPI" follows widget/layout size
- widgets & headers now become bigger and smaller, to match
'dpi' font sizes. Works well to match UI to monitor size.
- note that icons can get fuzzy, we need better mipmaps for it
2011-06-04 17:03:46 +00:00
|
|
|
|
|
|
|
|
RNA_def_int(ot->srna, "item", 0, 0, INT_MAX, "Item", "", 0, INT_MAX);
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-02 15:02:08 +02:00
|
|
|
/** \} */
|
2018-04-16 16:27:55 +02:00
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Undo Helper Functions
|
|
|
|
|
* \{ */
|
|
|
|
|
|
2021-02-25 16:08:48 +11:00
|
|
|
void ED_undo_object_set_active_or_warn(
|
|
|
|
|
Scene *scene, ViewLayer *view_layer, Object *ob, const char *info, CLG_LogRef *log)
|
2018-04-16 16:27:55 +02:00
|
|
|
{
|
2024-03-28 01:30:38 +01:00
|
|
|
using namespace blender::ed;
|
2022-09-14 21:33:51 +02:00
|
|
|
BKE_view_layer_synced_ensure(scene, view_layer);
|
2022-09-01 10:00:53 +02:00
|
|
|
Object *ob_prev = BKE_view_layer_active_object_get(view_layer);
|
2018-04-16 16:27:55 +02:00
|
|
|
if (ob_prev != ob) {
|
|
|
|
|
Base *base = BKE_view_layer_base_find(view_layer, ob);
|
2023-01-23 00:32:39 +01:00
|
|
|
if (base != nullptr) {
|
2018-04-16 16:27:55 +02:00
|
|
|
view_layer->basact = base;
|
2024-03-28 01:30:38 +01:00
|
|
|
object::base_active_refresh(G_MAIN, scene, view_layer);
|
2018-04-16 16:27:55 +02:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* Should never fail, may not crash but can give odd behavior. */
|
|
|
|
|
CLOG_WARN(log, "'%s' failed to restore active object: '%s'", info, ob->id.name + 2);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-27 11:39:49 +11:00
|
|
|
void ED_undo_object_editmode_validate_scene_from_windows(wmWindowManager *wm,
|
|
|
|
|
const Scene *scene_ref,
|
|
|
|
|
Scene **scene_p,
|
|
|
|
|
ViewLayer **view_layer_p)
|
|
|
|
|
{
|
|
|
|
|
if (*scene_p == scene_ref) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
LISTBASE_FOREACH (wmWindow *, win, &wm->windows) {
|
|
|
|
|
if (win->scene == scene_ref) {
|
|
|
|
|
*scene_p = win->scene;
|
|
|
|
|
*view_layer_p = WM_window_get_active_view_layer(win);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ED_undo_object_editmode_restore_helper(Scene *scene,
|
|
|
|
|
ViewLayer *view_layer,
|
2019-02-07 20:27:11 +11:00
|
|
|
Object **object_array,
|
|
|
|
|
uint object_array_len,
|
|
|
|
|
uint object_array_stride)
|
|
|
|
|
{
|
2024-03-28 01:30:38 +01:00
|
|
|
using namespace blender::ed;
|
2023-10-27 11:39:49 +11:00
|
|
|
Main *bmain = G_MAIN;
|
2019-08-01 13:53:25 +10:00
|
|
|
/* Don't request unique data because we want to de-select objects when exiting edit-mode
|
2019-02-07 20:27:11 +11:00
|
|
|
* for that to be done on all objects we can't skip ones that share data. */
|
2024-03-22 16:24:30 +01:00
|
|
|
Vector<Base *> bases = ED_undo_editmode_bases_from_view_layer(scene, view_layer);
|
|
|
|
|
for (Base *base : bases) {
|
|
|
|
|
((ID *)base->object->data)->tag |= LIB_TAG_DOIT;
|
2019-02-07 20:27:11 +11:00
|
|
|
}
|
|
|
|
|
Object **ob_p = object_array;
|
2023-01-23 00:32:39 +01:00
|
|
|
for (uint i = 0; i < object_array_len;
|
|
|
|
|
i++, ob_p = static_cast<Object **>(POINTER_OFFSET(ob_p, object_array_stride)))
|
|
|
|
|
{
|
2019-02-07 20:27:11 +11:00
|
|
|
Object *obedit = *ob_p;
|
2024-03-28 01:30:38 +01:00
|
|
|
object::editmode_enter_ex(bmain, scene, obedit, object::EM_NO_CONTEXT);
|
2019-02-07 20:27:11 +11:00
|
|
|
((ID *)obedit->data)->tag &= ~LIB_TAG_DOIT;
|
|
|
|
|
}
|
2024-03-22 16:24:30 +01:00
|
|
|
for (Base *base : bases) {
|
|
|
|
|
ID *id = static_cast<ID *>(base->object->data);
|
2019-02-07 20:27:11 +11:00
|
|
|
if (id->tag & LIB_TAG_DOIT) {
|
2024-03-28 01:30:38 +01:00
|
|
|
object::editmode_exit_ex(bmain, scene, base->object, object::EM_FREEDATA);
|
2019-02-07 20:27:11 +11:00
|
|
|
/* Ideally we would know the selection state it was before entering edit-mode,
|
|
|
|
|
* for now follow the convention of having them unselected when exiting the mode. */
|
2024-03-28 01:30:38 +01:00
|
|
|
object::base_select(base, object::BA_DESELECT);
|
2019-02-07 20:27:11 +11:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-16 16:27:55 +02:00
|
|
|
/** \} */
|
2020-02-04 18:26:57 +11:00
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Undo View Layer Helper Functions
|
|
|
|
|
*
|
|
|
|
|
* Needed because view layer functions such as
|
|
|
|
|
* #BKE_view_layer_array_from_objects_in_edit_mode_unique_data also check visibility,
|
|
|
|
|
* which is not reliable when it comes to object undo operations,
|
|
|
|
|
* since hidden objects can be operated on in the properties editor,
|
|
|
|
|
* and local collections may be used.
|
|
|
|
|
* \{ */
|
|
|
|
|
|
2024-03-22 16:24:30 +01:00
|
|
|
Vector<Object *> ED_undo_editmode_objects_from_view_layer(const Scene *scene,
|
|
|
|
|
ViewLayer *view_layer)
|
2020-02-04 18:26:57 +11:00
|
|
|
{
|
2022-09-14 21:33:51 +02:00
|
|
|
BKE_view_layer_synced_ensure(scene, view_layer);
|
|
|
|
|
Base *baseact = BKE_view_layer_active_base_get(view_layer);
|
2023-01-23 00:32:39 +01:00
|
|
|
if ((baseact == nullptr) || (baseact->object->mode & OB_MODE_EDIT) == 0) {
|
2024-03-22 16:24:30 +01:00
|
|
|
return {};
|
2020-02-04 18:26:57 +11:00
|
|
|
}
|
2024-03-22 16:24:30 +01:00
|
|
|
Set<const ID *> object_data;
|
2021-03-16 18:36:34 +11:00
|
|
|
const short object_type = baseact->object->type;
|
2024-03-22 16:24:30 +01:00
|
|
|
Vector<Object *> objects(object_data.size());
|
2021-03-16 18:36:34 +11:00
|
|
|
/* Base iteration, starting with the active-base to ensure it's the first item in the array.
|
|
|
|
|
* Looping over the active-base twice is OK as the tag check prevents it being handled twice. */
|
2023-01-23 00:32:39 +01:00
|
|
|
for (Base *base = baseact,
|
|
|
|
|
*base_next = static_cast<Base *>(BKE_view_layer_object_bases_get(view_layer)->first);
|
|
|
|
|
base;
|
|
|
|
|
base = base_next, base_next = base_next ? base_next->next : nullptr)
|
|
|
|
|
{
|
2020-02-04 18:26:57 +11:00
|
|
|
Object *ob = base->object;
|
|
|
|
|
if ((ob->type == object_type) && (ob->mode & OB_MODE_EDIT)) {
|
2024-03-22 16:24:30 +01:00
|
|
|
if (object_data.add(static_cast<const ID *>(ob->data))) {
|
|
|
|
|
objects.append(ob);
|
2020-02-04 18:26:57 +11:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2024-03-24 13:11:01 +01:00
|
|
|
BLI_assert(!object_data.is_empty());
|
2021-03-16 18:36:34 +11:00
|
|
|
BLI_assert(objects[0] == baseact->object);
|
2020-02-04 18:26:57 +11:00
|
|
|
return objects;
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-22 16:24:30 +01:00
|
|
|
Vector<Base *> ED_undo_editmode_bases_from_view_layer(const Scene *scene, ViewLayer *view_layer)
|
2020-02-04 18:26:57 +11:00
|
|
|
{
|
2022-09-14 21:33:51 +02:00
|
|
|
BKE_view_layer_synced_ensure(scene, view_layer);
|
|
|
|
|
Base *baseact = BKE_view_layer_active_base_get(view_layer);
|
2023-01-23 00:32:39 +01:00
|
|
|
if ((baseact == nullptr) || (baseact->object->mode & OB_MODE_EDIT) == 0) {
|
2024-03-22 16:24:30 +01:00
|
|
|
return {};
|
2020-02-04 18:26:57 +11:00
|
|
|
}
|
2024-03-22 16:24:30 +01:00
|
|
|
Set<const ID *> object_data;
|
2021-03-16 18:36:34 +11:00
|
|
|
const short object_type = baseact->object->type;
|
2024-03-22 16:24:30 +01:00
|
|
|
Vector<Base *> bases;
|
2021-03-16 18:36:34 +11:00
|
|
|
/* Base iteration, starting with the active-base to ensure it's the first item in the array.
|
|
|
|
|
* Looping over the active-base twice is OK as the tag check prevents it being handled twice. */
|
2022-09-14 21:33:51 +02:00
|
|
|
for (Base *base = BKE_view_layer_active_base_get(view_layer),
|
2023-01-23 00:32:39 +01:00
|
|
|
*base_next = static_cast<Base *>(BKE_view_layer_object_bases_get(view_layer)->first);
|
2022-09-14 21:33:51 +02:00
|
|
|
base;
|
2023-01-23 00:32:39 +01:00
|
|
|
base = base_next, base_next = base_next ? base_next->next : nullptr)
|
|
|
|
|
{
|
2020-02-04 18:26:57 +11:00
|
|
|
Object *ob = base->object;
|
|
|
|
|
if ((ob->type == object_type) && (ob->mode & OB_MODE_EDIT)) {
|
2024-03-22 16:24:30 +01:00
|
|
|
if (object_data.add(static_cast<const ID *>(ob->data))) {
|
|
|
|
|
bases.append(base);
|
2020-02-04 18:26:57 +11:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2021-03-16 18:36:34 +11:00
|
|
|
|
2024-03-24 13:11:01 +01:00
|
|
|
BLI_assert(!object_data.is_empty());
|
2024-03-22 16:24:30 +01:00
|
|
|
BLI_assert(bases[0] == baseact);
|
|
|
|
|
return bases;
|
2020-02-04 18:26:57 +11:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** \} */
|