blender
/
blender
129
398
Fork 572
Code Issues 6.2k Pull Requests 750 Projects 19 Wiki Activity

UI: File Save Incremental Operator #104678

Merged
Harley Acheson merged 1 commits from Harley/blender:SaveIncremental into main 2023-06-01 17:35:06 +02:00
Conversation 40 Commits 1 Files Changed 6 +73 -2
Harley Acheson commented 2023-02-13 02:59:15 +01:00
Member
Copy Link

Operator for the TopBar File Menu that saves the currently open file
with a numerically incremented name.

This is just an addition to the File Menu for "Save Incremental" that immediately saves the current file with a numerically-incremented file name. So if "example.blend" it will save as "example1.blend", "test0099.blend" will save as "test0100.blend", etc. So the same as if you selected File / Save As, then clicked "+" until you found the first available filename. The poll function will leave it disabled if the current file has never been saved.

SaveIncremental.png

This is an implementation of a Right-Click Select request with 66 votes

It could be argued that this makes the File menu longer but there are ways of reducing that, and I have proposed a few myself. But I don't think it is too long anyway:

SaveIncremental2.png

This adds shortcut Ctrl-Alt-S for this in both the regular and Industry Standard keymaps. This conflicts with transform.bbone_resize, so that is changed to Shift-Ctrl-Alt-S

Operator for the TopBar File Menu that saves the currently open file with a numerically incremented name. --- This is just an addition to the File Menu for "Save Incremental" that immediately saves the current file with a numerically-incremented file name. So if "example.blend" it will save as "example1.blend", "test0099.blend" will save as "test0100.blend", etc. So the same as if you selected File / Save As, then clicked "+" until you found the first available filename. The poll function will leave it disabled if the current file has never been saved. ![SaveIncremental.png](/attachments/0a48f9cb-73f4-4954-aed7-6f4a9739efaf) This is an implementation of a [Right-Click Select request](https://blender.community/c/rightclickselect/RRcbbc) with 66 votes It could be argued that this makes the File menu longer but there are ways of reducing that, and I have proposed a few myself. But I don't think it is too long anyway: ![SaveIncremental2.png](/attachments/1877fc95-0f70-4a83-9536-486c690fbabb) This adds shortcut Ctrl-Alt-S for this in both the regular and Industry Standard keymaps. This conflicts with `transform.bbone_resize`, so that is changed to Shift-Ctrl-Alt-S
SaveIncremental2.png
148 KiB
SaveIncremental.png
47 KiB
❤️ 9
Brecht Van Lommel added this to the User Interface project 2023-02-13 09:06:29 +01:00
Harley Acheson force-pushed SaveIncremental from a26798b1cd to 7963b82fb1 2023-02-24 02:48:23 +01:00 Compare
Harley Acheson commented 2023-02-24 02:49:32 +01:00
Author
Member
Copy Link

@blender-bot build

@blender-bot build
Pablo Vazquez commented 2023-03-01 15:47:15 +01:00
Member
Copy Link

+1 !

A shortcut for this would be handy, such as Ctrl+Alt+S (similar to other software).

+1 ! A shortcut for this would be handy, such as `Ctrl+Alt+S` (similar to other software).
Harley Acheson force-pushed SaveIncremental from 7963b82fb1 to dbc2b8651b 2023-03-01 17:20:57 +01:00 Compare
Harley Acheson commented 2023-03-01 17:23:20 +01:00
Author
Member
Copy Link

@pablovazquez -A shortcut...such as Ctrl+Alt+S

Thanks! Added Ctrl+Alt+S as shortcut

> @pablovazquez -A shortcut...such as `Ctrl+Alt+S` Thanks! Added Ctrl+Alt+S as shortcut
🎉 2
Pablo Vazquez commented 2023-03-02 16:23:19 +01:00
Member
Copy Link

Dropping here the results of a discussion over in blender.chat

Currently, using Ctrl+Alt+S would conflict with:

  1. Scale B-Bone transform.bbone_resize
  2. Save Copy (Blender 2.7x keymap)

A solution could be to:

  1. Change Scale B-Bone shortcut to something else, for example Ctrl+Alt+Shift+S (which is used in mesh editing for Shear transform.shear).
  2. Don't add this shortcut to the Blender 2.7x keymap.

@dr.sybren do you think this topic (changing shortcut) could be brought up in the next Animation & Rigging module meeting?

Dropping here the results of a discussion over in blender.chat Currently, using `Ctrl+Alt+S` would conflict with: 1. **Scale B-Bone** `transform.bbone_resize` 2. **Save Copy** (Blender 2.7x keymap) A solution could be to: 1. Change **Scale B-Bone** shortcut to something else, for example `Ctrl+Alt+Shift+S` (which is used in mesh editing for Shear `transform.shear`). 2. Don't add this shortcut to the Blender 2.7x keymap. @dr.sybren do you think this topic (changing shortcut) could be brought up in the next Animation & Rigging module meeting?
Luciano Muñoz Sessarego commented 2023-03-02 19:32:33 +01:00
Member
Copy Link

This is a great adition, its in fact so good, that I normally replace Ctrl+S to do incremental and Ctrl+Shift+S to do regular save because in production you rarely want to overrwrite a file unless youre absolutely sure of it.

This is a great adition, its in fact so good, that I normally replace Ctrl+S to do incremental and Ctrl+Shift+S to do regular save because in production you rarely want to overrwrite a file unless youre absolutely sure of it.
Sybren A. Stüvel commented 2023-03-03 11:04:29 +01:00
Member
Copy Link

This was discussed in yesterday's module meeting. The conclusions were:

  • Everybody loves the proposed incremental save feature.
  • B-Bone Scale can be done with a widget as well as from the bone properties panel.
  • The Ctrl+Alt+S hotkey was hard to remember anyway, so easily traded for the anticipated incremental save.
  • Ctrl+Alt+Shift+S is okay to keep, but the response was mostly neutral.
  • @cessen proposed to add more functionality to the regular bone scale operator: while scaling, in the same way that you can limit the axis with the x/y/z keys, use r to switch to scaling the bone radius, e to scale the envelope, and b to scale the B-Bone. This can be done in a separate patch, of course.
This was discussed in [yesterday's module meeting](https://devtalk.blender.org/t/2023-03-02-animation-rigging-module-meeting/28059). The conclusions were: - Everybody loves the proposed incremental save feature. - B-Bone Scale can be done with a widget as well as from the bone properties panel. - The Ctrl+Alt+S hotkey was hard to remember anyway, so easily traded for the anticipated incremental save. - Ctrl+Alt+Shift+S is okay to keep, but the response was mostly neutral. - @cessen proposed to add more functionality to the regular bone scale operator: while scaling, in the same way that you can limit the axis with the `x`/`y`/`z` keys, use `r` to switch to scaling the bone radius, `e` to scale the envelope, and `b` to scale the B-Bone. This can be done in a separate patch, of course.
❤️ 1 🎉 1
Sybren A. Stüvel added the
Interest
Animation & Rigging
 label 2023-03-03 11:04:58 +01:00
Harley Acheson requested review from Campbell Barton 2023-03-03 17:32:04 +01:00
Harley Acheson force-pushed SaveIncremental from 59958b2fe0 to aaa5c1a46d 2023-03-06 21:28:30 +01:00 Compare
Harley Acheson commented 2023-03-06 21:36:18 +01:00
Author
Member
Copy Link

This version now uses Ctrl-Alt-S for this in the standard and Industry Standard keymaps. It also changes bbone_resize to use Shift-Ctrl-Alt-S.

This version now uses Ctrl-Alt-S for this in the standard and Industry Standard keymaps. It also changes `bbone_resize` to use Shift-Ctrl-Alt-S.
👍 2
Campbell Barton requested changes 2023-03-08 06:11:07 +01:00
source/blender/windowmanager/intern/wm_files.cc Outdated
@ -3358,0 +3360,4 @@
*
* \{ */
static int wm_save_mainfile_incremental_exec(bContext *C, wmOperator *op)
Campbell Barton commented 2023-03-08 06:10:45 +01:00
Owner
Copy Link

Couldn't this be implemented as an option for the existing save operator?

A new boolean option can be added (HIDDEN and SKIP_SAVE flags set).
This can then be set in the menu and via the keymap.

This has the advantage that we wont end up needing to expose options currently found in WM_OT_save_mainfile such as compression or relative remapping.

Couldn't this be implemented as an option for the existing save operator? A new boolean option can be added (HIDDEN and SKIP_SAVE flags set). This can then be set in the menu and via the keymap. This has the advantage that we wont end up needing to expose options currently found in `WM_OT_save_mainfile` such as compression or relative remapping.
Harley Acheson commented 2023-03-08 07:00:25 +01:00
Author
Member
Copy Link

@ideasman42 - Couldn't this be implemented as an option for the existing save operator?

Yes, that sounds like a great idea.

> @ideasman42 - Couldn't this be implemented as an option for the existing save operator? Yes, that sounds like a great idea.
Harley Acheson changed title from UI: File Save Incremental Operator to WIP: UI: File Save Incremental Operator 2023-03-08 07:00:38 +01:00
Harley Acheson force-pushed SaveIncremental from aaa5c1a46d to 172cc1d387 2023-03-09 22:03:38 +01:00 Compare
Harley Acheson changed title from WIP: UI: File Save Incremental Operator to UI: File Save Incremental Operator 2023-03-09 22:05:04 +01:00
Harley Acheson commented 2023-03-09 22:05:48 +01:00
Author
Member
Copy Link

@ideasman42 - You are right, this is much simpler.

@ideasman42 - You are right, this is much simpler.
Campbell Barton requested changes 2023-03-10 01:40:12 +01:00
Campbell Barton left a comment
Owner
Copy Link

Noted issues inline.

Noted issues inline.
scripts/startup/bl_ui/space_topbar.py Outdated
@ -284,2 +284,4 @@
layout.operator("wm.save_mainfile", text="Save", icon='FILE_TICK')
sub = layout.row()
sub.active = context.blend_data.is_saved
Campbell Barton commented 2023-03-10 00:54:49 +01:00
Owner
Copy Link

Use enabled otherwise this is still clickable (which isn't expected for greyed out menu items).

Use `enabled` otherwise this is still clickable (which isn't expected for greyed out menu items).
Harley marked this conversation as resolved
source/blender/windowmanager/intern/wm_files.cc Outdated
@ -3231,0 +3231,4 @@
if (RNA_boolean_get(op->ptr, "incremental")) {
char head[FILE_MAXFILE], tail[FILE_MAXFILE];
ushort digits;
int num = BLI_path_sequence_decode(filepath, head, tail, &digits);
Campbell Barton commented 2023-03-10 01:38:34 +01:00
Owner
Copy Link

Numbers greater than INT_MAX currently behave strangely. Instead of incrementing the number they return 0 for num and add a 1 to the end of the current name.

This is my recent-files.txt after saving incremental multiple times.

/tmp/test_2147483648111111111.blend
/tmp/test_214748364811111111.blend
/tmp/test_21474836481111111.blend
/tmp/test_2147483648111111.blend
/tmp/test_214748364811111.blend
/tmp/test_21474836481111.blend
/tmp/test_2147483648111.blend
/tmp/test_214748364811.blend
/tmp/test_21474836481.blend
/tmp/test_2147483648.blend

While 2147483648 is contrived (INT_MAX+1), users may run into this with files that include some UUID at the end which happen to be very large numbers.

In this particular case it's simplest to reset the value to zero.

This can be done by stripping digits.

    /* Account for a number that exceeds INT_MAX, without this check `1`
     * is always added to the end of a large number (creating an increasingly long filename). */
    if (num == 0 && digits == 0) {
      /* Does nothing if there are no numbers at the end of the head. */
      BLI_str_rstrip_digits(head);
    }

Strip digits utility.

diff --git a/source/blender/blenlib/BLI_string.h b/source/blender/blenlib/BLI_string.h
index 87749e90e77..bf0a15f3220 100644
--- a/source/blender/blenlib/BLI_string.h
+++ b/source/blender/blenlib/BLI_string.h
@@ -419,6 +419,15 @@ void BLI_str_rstrip(char *str) ATTR_NONNULL();
  */
 int BLI_str_rstrip_float_zero(char *str, char pad) ATTR_NONNULL();
 
+/**
+ * Strip trailing digits.
+ *   ABC123 -> ABC
+ *
+ * \param str:
+ * \return The number of digits stripped.
+ */
+int BLI_str_rstrip_digits(char *str) ATTR_NONNULL();
+
 /**
  * Return index of a string in a string array.
  *
diff --git a/source/blender/blenlib/intern/string.c b/source/blender/blenlib/intern/string.c
index afb1a92c02a..4cd64fd0c11 100644
--- a/source/blender/blenlib/intern/string.c
+++ b/source/blender/blenlib/intern/string.c
@@ -991,6 +991,17 @@ int BLI_str_rstrip_float_zero(char *str, const char pad)
   return totstrip;
 }
 
+int BLI_str_rstrip_digits(char *str)
+{
+  int totstrip = 0;
+  int str_len = strlen(str);
+  while (str_len > 0 && isdigit(str[--str_len])) {
+    str[str_len] = '\0';
+    totstrip++;
+  }
+  return totstrip;
+}
+
 /** \} */
 
 /* -------------------------------------------------------------------- */
Numbers greater than `INT_MAX` currently behave strangely. Instead of incrementing the number they return 0 for `num` and add a `1` to the end of the current name. This is my `recent-files.txt` after saving incremental multiple times. ``` /tmp/test_2147483648111111111.blend /tmp/test_214748364811111111.blend /tmp/test_21474836481111111.blend /tmp/test_2147483648111111.blend /tmp/test_214748364811111.blend /tmp/test_21474836481111.blend /tmp/test_2147483648111.blend /tmp/test_214748364811.blend /tmp/test_21474836481.blend /tmp/test_2147483648.blend ``` While 2147483648 is contrived (INT_MAX+1), users may run into this with files that include some UUID at the end which happen to be very large numbers. In this particular case it's simplest to reset the value to zero. This can be done by stripping digits. ``` /* Account for a number that exceeds INT_MAX, without this check `1` * is always added to the end of a large number (creating an increasingly long filename). */ if (num == 0 && digits == 0) { /* Does nothing if there are no numbers at the end of the head. */ BLI_str_rstrip_digits(head); } ``` Strip digits utility. ``` diff --git a/source/blender/blenlib/BLI_string.h b/source/blender/blenlib/BLI_string.h index 87749e90e77..bf0a15f3220 100644 --- a/source/blender/blenlib/BLI_string.h +++ b/source/blender/blenlib/BLI_string.h @@ -419,6 +419,15 @@ void BLI_str_rstrip(char *str) ATTR_NONNULL(); */ int BLI_str_rstrip_float_zero(char *str, char pad) ATTR_NONNULL(); +/** + * Strip trailing digits. + * ABC123 -> ABC + * + * \param str: + * \return The number of digits stripped. + */ +int BLI_str_rstrip_digits(char *str) ATTR_NONNULL(); + /** * Return index of a string in a string array. * diff --git a/source/blender/blenlib/intern/string.c b/source/blender/blenlib/intern/string.c index afb1a92c02a..4cd64fd0c11 100644 --- a/source/blender/blenlib/intern/string.c +++ b/source/blender/blenlib/intern/string.c @@ -991,6 +991,17 @@ int BLI_str_rstrip_float_zero(char *str, const char pad) return totstrip; } +int BLI_str_rstrip_digits(char *str) +{ + int totstrip = 0; + int str_len = strlen(str); + while (str_len > 0 && isdigit(str[--str_len])) { + str[str_len] = '\0'; + totstrip++; + } + return totstrip; +} + /** \} */ /* -------------------------------------------------------------------- */ ```
Harley marked this conversation as resolved
source/blender/windowmanager/intern/wm_files.cc Outdated
@ -3231,0 +3232,4 @@
char head[FILE_MAXFILE], tail[FILE_MAXFILE];
ushort digits;
int num = BLI_path_sequence_decode(filepath, head, tail, &digits);
int tries = 0;
Campbell Barton commented 2023-03-10 01:09:29 +01:00
Owner
Copy Link

picky avoiding int-overflow be done at the same time as avoiding too many attempts.

const int tries_limit = 1000;
const int num_max = num < (INT_MAX - tries_limit) ? (num + tries_limit) : (INT_MAX - tries_limit);

do {
  ..
} while (num < num_max);
*picky* avoiding int-overflow be done at the same time as avoiding too many attempts. ``` const int tries_limit = 1000; const int num_max = num < (INT_MAX - tries_limit) ? (num + tries_limit) : (INT_MAX - tries_limit); do { .. } while (num < num_max); ```
Harley marked this conversation as resolved
source/blender/windowmanager/intern/wm_files.cc Outdated
@ -3361,6 +3377,24 @@ static int wm_save_mainfile_invoke(bContext *C, wmOperator *op, const wmEvent *
return ret;
}
static const char *wm_save_mainfile_get_name(wmOperatorType *ot, PointerRNA *ptr)
Campbell Barton commented 2023-03-10 01:11:38 +01:00
Owner
Copy Link

This could be removed? (as far as I can see this isn't used), if it is used it could follow the operator name. Save Blender File (Incremental).

This could be removed? (as far as I can see this isn't used), if it is used it could follow the operator name. `Save Blender File (Incremental)`.
Harley marked this conversation as resolved
source/blender/windowmanager/intern/wm_files.cc Outdated
@ -3364,0 +3390,4 @@
PointerRNA *ptr)
{
if (RNA_boolean_get(ptr, "incremental")) {
return BLI_strdup(TIP_("Save the current Blender file with an incremented name"));
Campbell Barton commented 2023-03-10 01:12:21 +01:00
Owner
Copy Link

Misses an important point that the name is incremented to the next unused file, never overwriting existing files.

Misses an important point that the name is incremented to the next *unused* file, never overwriting existing files.
Harley marked this conversation as resolved
source/blender/windowmanager/intern/wm_files.cc Outdated
@ -3392,0 +3430,4 @@
"incremental",
false,
"Incremental",
"Save the current Blender file with an incremented name");
Campbell Barton commented 2023-03-10 01:12:48 +01:00
Owner
Copy Link

Again, doesn't mention incrementing doesn't overwrite.

Again, doesn't mention incrementing doesn't overwrite.
Harley marked this conversation as resolved
Harley Acheson force-pushed SaveIncremental from 172cc1d387 to 8c503ba904 2023-03-10 05:13:58 +01:00 Compare
Harley Acheson commented 2023-03-10 05:26:56 +01:00
Author
Member
Copy Link

@ideasman42 - Use enabled

Whoops, thanks!

Numbers greater than INT_MAX currently behave strangely...can be done by stripping digits.

The idea of stripping digits makes me nervous as we might have a filename with nothing but digits.

When I looked into our BLI_path_sequence_decode it uses strtoll and we have been clamping it at integer. So I widened it to allow int64_t.

If I start with:

9223372036854775805.blend

I get:

9223372036854775806.blend
9223372036854775807.blend
0000000000000000000.blend
0000000000000000001.blend

This "rolling over" (if the file is available) seems okay. If I then open up the first one, 9223372036854775805.blend, and try to increment I then get the Error: "Unable to find an available incremented file name". So it does no harm.

avoiding int-overflow be done at the same time as avoiding too many attempts

I might be a bit dense, but I found that line to be a difficult quick read. I did re-work that section though so it does check overflow and does a better job of detecting failure (by using the return of BLI_exists, not the number of tries).

> @ideasman42 - Use enabled Whoops, thanks! > Numbers greater than INT_MAX currently behave strangely...can be done by stripping digits. The idea of stripping digits makes me nervous as we might have a filename with nothing but digits. When I looked into our `BLI_path_sequence_decode` it uses `strtoll` and we have been clamping it at integer. So I widened it to allow int64_t. If I start with: ``` 9223372036854775805.blend ``` I get: ``` 9223372036854775806.blend 9223372036854775807.blend 0000000000000000000.blend 0000000000000000001.blend ``` This "rolling over" (if the file is available) seems okay. If I then open up the first one, 9223372036854775805.blend, and try to increment I then get the Error: "Unable to find an available incremented file name". So it does no harm. > avoiding int-overflow be done at the same time as avoiding too many attempts I might be a bit dense, but I found that line to be a difficult quick read. I did re-work that section though so it does check overflow and does a better job of detecting failure (by using the return of BLI_exists, not the number of tries).
Campbell Barton commented 2023-03-11 02:21:13 +01:00
Owner
Copy Link

  • Prefer to keep BLI_path_sequence_decode using int, using int64_t may have unintended implication for image sequences/rendering. And however large the value can be - there is still the chance that limit is exceeded. Even if this is changed, I'd rather it be part of a separate patch.

  • When I got roll-over it was adding a number to the end of the name each time, I'd need to double check if this is possible with your update. I don't see stripping numbers as especially bad, even if the entire name is a number, it wraps back to 1.blend which seems acceptable (AFAICS).

- Prefer to keep `BLI_path_sequence_decode` using `int`, using int64_t may have unintended implication for image sequences/rendering. And however large the value can be - there is still the chance that limit is exceeded. Even if this is changed, I'd rather it be part of a separate patch. - When I got roll-over it was adding a number to the end of the name each time, I'd need to double check if this is possible with your update. I don't see stripping numbers as especially bad, even if the entire name is a number, it wraps back to `1.blend` which seems acceptable (AFAICS).
Harley Acheson commented 2023-03-11 03:21:05 +01:00
Author
Member
Copy Link

No worries, it was just a fun exercise. Will get in there again over the weekend.

No worries, it was just a fun exercise. Will get in there again over the weekend.
Harley Acheson changed title from UI: File Save Incremental Operator to WIP: UI: File Save Incremental Operator 2023-03-11 03:21:29 +01:00
Harley Acheson force-pushed SaveIncremental from 8c503ba904 to 6ebb41a218 2023-03-12 01:40:12 +01:00 Compare
Harley Acheson commented 2023-03-12 01:45:58 +01:00
Author
Member
Copy Link

@ideasman42, now in the shape that you requested earlier...

  • Prefer to keep BLI_path_sequence_decode using int...

Yes, back to using int there.

I don't see stripping numbers as especially bad, even if the entire name is a number, it wraps back to 1.blend which seems acceptable (AFAICS).

Yes it seems okay.

0000000000000000000.blend → 0000000000000000001.blend
9223372036854775807.blend → 1.blend → 2.blend

@ideasman42, now in the shape that you requested earlier... > - Prefer to keep `BLI_path_sequence_decode` using `int`... Yes, back to using int there. > I don't see stripping numbers as especially bad, even if the entire name is a number, it wraps back to `1.blend` which seems acceptable (AFAICS). Yes it seems okay. 0000000000000000000.blend → 0000000000000000001.blend 9223372036854775807.blend → 1.blend → 2.blend
Harley Acheson changed title from WIP: UI: File Save Incremental Operator to UI: File Save Incremental Operator 2023-03-12 01:46:11 +01:00
Campbell Barton approved these changes 2023-03-12 02:46:31 +01:00
Campbell Barton left a comment
Owner
Copy Link

Looks good, minor request noted inline.

Looks good, minor request noted inline.
source/blender/windowmanager/intern/wm_files.cc Outdated
@ -3361,6 +3386,16 @@ static int wm_save_mainfile_invoke(bContext *C, wmOperator *op, const wmEvent *
return ret;
}
static char *wm_save_mainfile_get_description(bContext * /*C*/,
Campbell Barton commented 2023-03-12 02:43:42 +01:00
Owner
Copy Link

The description still doesn't mention incrementing never overwrites files (skips existing files).

The description still doesn't mention incrementing never overwrites files (skips existing files).
Harley marked this conversation as resolved
Campbell Barton requested changes 2023-03-12 02:51:41 +01:00
Campbell Barton left a comment
Owner
Copy Link

The issue with recent files remains. Where saving incremental files quickly replaces many/all items in the recent file lists with each increment.

In this case I think it's best to remove the current file from the recent-file-list and add the newly incremented file.

The issue with recent files remains. Where saving incremental files quickly replaces many/all items in the recent file lists with each increment. In this case I think it's best to remove the current file from the recent-file-list and add the newly incremented file.
TheRedWaxPolice commented 2023-03-12 04:40:16 +01:00
First-time contributor
Copy Link

saving incremental files quickly replaces many/all items in the recent file lists with each increment.

In this case I think it's best to remove the current file from the recent-file-list and add the newly incremented file.

Hi @ideasman42 in most software I use that has incremental save, this is how it actually works. Each incremental save stays in the recent file list, not just the newly incremented file. And it's more handy that way, imo. I wish blender worked the same as well...

I'm surprised that this behavior is being considered an issue... 😕

> saving incremental files quickly replaces many/all items in the recent file lists with each increment. > > In this case I think it's best to remove the current file from the recent-file-list and add the newly incremented file. > Hi @ideasman42 in most software I use that has incremental save, this is how it actually works. Each incremental save stays in the recent file list, not just the newly incremented file. And it's more handy that way, imo. I wish blender worked the same as well... I'm surprised that this behavior is being considered an issue... 😕
Harley Acheson commented 2023-03-12 06:51:02 +01:00
Author
Member
Copy Link

Hi @ideasman42 in most software I use that has incremental save, this is how it actually works. Each incremental save stays in the recent file list, not just the newly incremented file. And it's more handy that way, imo. I wish blender worked the same as well...

I'm surprised that this behavior is being considered an issue... 😕

@TheRedWaxPolice - No laughing, because I have probably had too much wine, but I've read your comment quite a few times and I remain uncertain of whether you are agreeing with Campbell or not. Please excuse my denseness and be very explicit on how you would like the "recent files" list to be behave, especially since it will get so much easier to make many. I appreciate your opinion.

> Hi @ideasman42 in most software I use that has incremental save, this is how it actually works. Each incremental save stays in the recent file list, not just the newly incremented file. And it's more handy that way, imo. I wish blender worked the same as well... > > I'm surprised that this behavior is being considered an issue... 😕 @TheRedWaxPolice - No laughing, because I have probably had too much wine, but I've read your comment quite a few times and I remain uncertain of whether you are agreeing with Campbell or not. Please excuse my denseness and be very explicit on how you would like the "recent files" list to be behave, especially since it will get so much easier to make many. I appreciate your opinion.
TheRedWaxPolice commented 2023-03-12 18:28:06 +01:00
First-time contributor
Copy Link

@TheRedWaxPolice - No laughing, because I have probably had too much wine, but I've read your comment quite a few times and I remain uncertain of whether you are agreeing with Campbell or not. Please excuse my denseness and be very explicit on how you would like the "recent files" list to be behave, especially since it will get so much easier to make many. I appreciate your opinion.

@Harley Damn, now I know my english sucks lol...
But no, I'm not agreeing.
From what I could understand from ideasman42's post, is that he want's the recent files list to have just one entry of the incremented file saved (the last saved one), instead of populating the list with every version of the files saved.

Let me give you an example:
This is what we get in the recent files list of most apps after incremental saving a few times:

Project 4.blend
Project 3.blend
Project 2.blend
Project 1.blend
Project.blend
xxx.blend
yyy.blend
etc

With ideasman42's suggestion we would get just one entry of the incremented file saved in the recent list, which is always replaced by the last version every time we save incremental. No old versions on the list anymore. something like:

Project 4.blend
xxx.blend
yyy.blend
etc

Does that makes sense?

> @TheRedWaxPolice - No laughing, because I have probably had too much wine, but I've read your comment quite a few times and I remain uncertain of whether you are agreeing with Campbell or not. Please excuse my denseness and be very explicit on how you would like the "recent files" list to be behave, especially since it will get so much easier to make many. I appreciate your opinion. @Harley Damn, now I know my english sucks lol... But no, I'm not agreeing. From what I could understand from ideasman42's post, is that he want's the recent files list to have just one entry of the incremented file saved (the last saved one), instead of populating the list with every version of the files saved. Let me give you an example: This is what we get in the recent files list of most apps after incremental saving a few times: Project 4.blend Project 3.blend Project 2.blend Project 1.blend Project.blend xxx.blend yyy.blend etc With ideasman42's suggestion we would get just one entry of the incremented file saved in the recent list, which is always replaced by the last version every time we save incremental. No old versions on the list anymore. something like: Project 4.blend xxx.blend yyy.blend etc Does that makes sense?
Harley Acheson commented 2023-03-12 19:15:36 +01:00
Author
Member
Copy Link

@TheRedWaxPolice - Does that makes sense?

Yes, thanks for clarifying.

But are there any alternatives?

A simple thing would be to increase the default length of the recent files list, now 10, to something larger. What is reasonable? Is there an upper bound that is too long?

Do any other applications deal with this in any better way? Can the recent list do grouping? So that any items that share a common root get a submenu? So in your example all of the items that start with "Project" are grouped together in a submenu? That sounds like a mess, but maybe there is some better way.

> @TheRedWaxPolice - Does that makes sense? Yes, thanks for clarifying. But are there any alternatives? A simple thing would be to increase the default length of the recent files list, now 10, to something larger. What is reasonable? Is there an upper bound that is too long? Do any other applications deal with this in any better way? Can the recent list do grouping? So that any items that share a common root get a submenu? So in your example all of the items that start with "Project" are grouped together in a submenu? That sounds like a mess, but maybe there is some better way.
TheRedWaxPolice commented 2023-03-12 19:40:28 +01:00
First-time contributor
Copy Link

But are there any alternatives?

A simple thing would be to increase the default length of the recent files list, now 10, to something larger. What is reasonable? Is there an upper bound that is too long?

Do any other applications deal with this in any better way? Can the recent list do grouping? So that any items that share a common root get a submenu? So in your example all of the items that start with "Project" are grouped together in a submenu? That sounds like a mess, but maybe there is some better way.

Never saw anything else other than a bigger list of recent files.
20 seems to be the golden standard everywhere. The default 10 in blender always felt not enough.

Grouping sounds interesting tho, but a longer list by default seems to be good enough and it's what most people would expect...

> But are there any alternatives? > > A simple thing would be to increase the default length of the recent files list, now 10, to something larger. What is reasonable? Is there an upper bound that is too long? > > Do any other applications deal with this in any better way? Can the recent list do grouping? So that any items that share a common root get a submenu? So in your example all of the items that start with "Project" are grouped together in a submenu? That sounds like a mess, but maybe there is some better way. Never saw anything else other than a bigger list of recent files. 20 seems to be the golden standard everywhere. The default 10 in blender always felt not enough. Grouping sounds interesting tho, but a longer list by default seems to be good enough and it's what most people would expect...
Harley Acheson commented 2023-03-12 20:28:25 +01:00
Author
Member
Copy Link

20 seems to be the golden standard everywhere. The default 10 in blender always felt not enough.

Yes, I've had someone else say that 20 was a nice "just right" length. I should admit that I did not notice until yesterday that this was something that I could change in Preferences (Save & Load / Blend File / "Recent Files".

Easy to change the default for this, but a bit ruder to change a user's current setting. Maybe we could do a version (one-time) bump to 20 if it is currently exactly 10.

> 20 seems to be the golden standard everywhere. The default 10 in blender always felt not enough. Yes, I've had someone else say that 20 was a nice "just right" length. I should admit that I did not notice until yesterday that this was something that I could change in Preferences (Save & Load / Blend File / "Recent Files". Easy to change the default for this, but a bit ruder to change a user's current setting. Maybe we could do a version (one-time) bump to 20 if it is currently *exactly* 10.
👍 1
Harley Acheson force-pushed SaveIncremental from 6ebb41a218 to 087cd3383c 2023-03-12 21:21:03 +01:00 Compare
Pablo Vazquez commented 2023-03-12 22:36:22 +01:00
Member
Copy Link

The issue with recent files remains. Where saving incremental files quickly replaces many/all items in the recent file lists with each increment.

In this case I think it's best to remove the current file from the recent-file-list and add the newly incremented file.

+1

Much better than losing the list of files I've been working on just because of incrementals. I'd be interesting to investigate grouping incrementals in a sub-menu of the current file but that'd be for another patch.

For this patch I'd go with replacing only the current file's entry in the list of recent files, with the incremented one.

> The issue with recent files remains. Where saving incremental files quickly replaces many/all items in the recent file lists with each increment. > > In this case I think it's best to remove the current file from the recent-file-list and add the newly incremented file. > +1 Much better than losing the list of files I've been working on just because of incrementals. I'd be interesting to investigate grouping incrementals in a sub-menu of the current file but that'd be for another patch. For this patch I'd go with replacing only the current file's entry in the list of recent files, with the incremented one.
Harley Acheson commented 2023-03-12 23:26:35 +01:00
Author
Member
Copy Link

@pablovazquez - ...replacing only the current file's entry in the list of recent files, with the incremented one.

You and Campbell are on the same page there, and I am always happy to implement whatever behavior you prefer.

But I worry about getting bug reports along the lines of: "I can manually save a file called 'Blend2.blend' or do so using the 'increment' buttons in File Browser and I will then see both it and the original file in 'Recent'. But doing so from this operator does not." Then we have to reply that this is "by design" but I'd struggle to explain the different behavior in these very similar circumstances.

Some programs only put the names of files opened in their "recent" lists. So if I open "filename1" and then save it as "filename2" their recent list will only show the first name. So the feature could be called "Recently Opened Files".

Some programs, like Blender, put both the names of files opened and saved on the list. So if I open "filename1" then save it as "filename2" then both names will be on their lists. This could be called "Recently Accessed Files"

Both of the above have their merits, but I haven't (yet) found any other programs behaving as suggested here, including those that implement "Save Incremental". So this would be introducing a non-standard behavior that I'd have a hard time describing succinctly.

> @pablovazquez - ...replacing only the current file's entry in the list of recent files, with the incremented one. You and Campbell are on the same page there, and I am always happy to implement whatever behavior you prefer. But I worry about getting bug reports along the lines of: "I can manually save a file called 'Blend2.blend' or do so using the 'increment' buttons in File Browser and I will then see both it and the original file in 'Recent'. But doing so from this operator does not." Then we have to reply that this is "by design" but I'd struggle to explain the different behavior in these very similar circumstances. Some programs only put the names of files *opened* in their "recent" lists. So if I open "filename1" and then save it as "filename2" their recent list will only show the first name. So the feature could be called "Recently Opened Files". Some programs, like Blender, put both the names of files opened and saved on the list. So if I open "filename1" then save it as "filename2" then both names will be on their lists. This could be called "Recently Accessed Files" Both of the above have their merits, but I haven't (yet) found any other programs behaving as suggested here, including those that implement "Save Incremental". So this would be introducing a non-standard behavior that I'd have a hard time describing succinctly.
TheRedWaxPolice commented 2023-03-13 00:46:59 +01:00
First-time contributor
Copy Link

@pablovazquez For this patch I'd go with replacing only the current file's entry in the list of recent files, with the incremented one.

I honestly never saw any application do that, and I don't see why blender should do that and go against the standards, really.

> @pablovazquez For this patch I'd go with replacing only the current file's entry in the list of recent files, with the incremented one. I honestly never saw any application do that, and I don't see why blender should do that and go against the standards, really.
Harley Acheson commented 2023-03-13 01:10:30 +01:00
Author
Member
Copy Link

Apologies if this is half-baked, but we could think about making larger changes to make everything fit better:

Change the behavior of "Open Recent" so that it only ever contains recently opened files, not any saved names. This way you could make all the backups and incrementals you want and that list would still contain only the items that you opened.

Combine File / Revert with File / Recover into a single submenu that also includes revisions that are specific to the currently-opened file (only).

What I mean is that when we open a file we do BLI_path_sequence_decode to get the file parts. Then get the list of matching revisions by file listing filepath + head + * + ".blend", sorted by date (newest first). Those get added to the File / Revert list like this:

🗎 sample3.blend
🗎 sample2.blend
🗎 sample.blend
----------------
   Last Session
   Auto-Save...

Any Save As, or Save Incremental names, until the next file opened, is appended to that "Revert" list.

I think that would get you the "recent" list you want that doesn't get quickly diluted with incrementals, but also gives us quick access to prior versions. With the added ability of seeing the list of prior versions immediately and in a static location, and not diluted by unrelated recent files opened.

Apologies if this is half-baked, but we could think about making larger changes to make everything fit better: Change the behavior of "Open Recent" so that it only ever contains recently opened files, not any saved names. This way you could make all the backups and incrementals you want and that list would still contain only the items that you opened. Combine File / Revert with File / Recover into a single submenu that also includes revisions that are specific to the currently-opened file (only). What I mean is that when we open a file we do `BLI_path_sequence_decode` to get the file parts. Then get the list of matching revisions by file listing filepath + head + * + ".blend", sorted by date (newest first). Those get added to the File / Revert list like this: ``` 🗎 sample3.blend 🗎 sample2.blend 🗎 sample.blend ---------------- Last Session Auto-Save... ``` Any Save As, or Save Incremental names, until the next file opened, is appended to that "Revert" list. I think that would get you the "recent" list you want that doesn't get quickly diluted with incrementals, but also gives us quick access to prior versions. With the added ability of seeing the list of prior versions immediately and in a static location, and not diluted by unrelated recent files opened.
Jer Bot commented 2023-03-14 07:20:55 +01:00
First-time contributor
Copy Link

For my own workflow, I don't like the idea if hiding revisions from the recent file list. That said, I do jump around between projects and do wish recent file list could be a bit longer, as incrementals can push other files off the list... though this is not terribly frequently for my workflow. perhaps a preference setting?

A revert list is interesting, but how touchy will it be? What happens if I happened to jump back to a version number and start incrementing sub-versions, i.e

myfile_004
myfile_005
myfile_005B
myfile_005C

or
myfile_004
myfile_005
myfile_005_001
myfile_005_002
myfile_005_003

If things are going to get fancy, it would be handy to specify patterns (regex in preference)... and I realize this opens a can of worms, but I didn't start it. ;)

For my own workflow, I don't like the idea if hiding revisions from the recent file list. That said, I do jump around between projects and do wish recent file list could be a bit longer, as incrementals can push other files off the list... though this is not terribly frequently for my workflow. perhaps a preference setting? A revert list is interesting, but how touchy will it be? What happens if I happened to jump back to a version number and start incrementing sub-versions, i.e myfile_004 myfile_005 myfile_005B myfile_005C or myfile_004 myfile_005 myfile_005_001 myfile_005_002 myfile_005_003 If things are going to get fancy, it would be handy to specify patterns (regex in preference)... and I realize this opens a can of worms, but I didn't start it. ;)
Sybren A. Stüvel commented 2023-03-14 10:37:24 +01:00
Member
Copy Link

As an alternative idea (feel free to it shoot down), how's this?

  • When doing another incremental save, it replaces the entry of the current file. So if you have abc_def_001.blend open and do an incremental save to abc_def_002.blend, that filename replaces abc_def_001.blend in the recent files list.
  • The File Open dialogue box gets an extra feature to select (but not open) a file from the recent files list. That way you can quickly navigate to a recent file, and from there open any of the previous versions.
  • Optional extra, might go against some UI rules: with the shift key pressed, selecting a file from the Open Recent menu will trigger the above feature of the File Open dialogue box to browse to that file.

(emphasis for ease of quickly scanning the text)

Change the behavior of "Open Recent" so that it only ever contains recently opened files, not any saved names. This way you could make all the backups and incrementals you want and that list would still contain only the items that you opened.

I wouldn't like this. I often use Ctrl+Shift+O, Enter to reload the current file. If that opens an older version under certain conditions, I may have a little heart attack.

As an alternative idea (feel free to it shoot down), how's this? - When doing another incremental save, it **replaces the entry of the current file**. So if you have `abc_def_001.blend` open and do an incremental save to `abc_def_002.blend`, that filename replaces `abc_def_001.blend` in the recent files list. - The File Open dialogue box gets an extra feature to **select (but not open) a file from the recent files list**. That way you can quickly navigate to a recent file, and from there open any of the previous versions. - Optional extra, might go against some UI rules: with the **shift** key pressed, selecting a file from the Open Recent menu will trigger the above feature of the File Open dialogue box to **browse to that file**. *(emphasis for ease of quickly scanning the text)* > Change the behavior of "Open Recent" so that it only ever contains recently opened files, not any saved names. This way you could make all the backups and incrementals you want and that list would still contain only the items that you opened. I wouldn't like this. I often use `Ctrl+Shift+O`, `Enter` to reload the current file. If that opens an older version under certain conditions, I may have a little heart attack.
Hadrien commented 2023-03-14 13:41:17 +01:00
First-time contributor
Copy Link
  • @cessen proposed to add more functionality to the regular bone scale operator: while scaling, in the same way that you can limit the axis with the x/y/z keys, use r to switch to scaling the bone radius, e to scale the envelope, and b to scale the B-Bone. This can be done in a separate patch, of course.

r is part of the transform modal map and is used to switch from translation or scale to rotation during the transform. Same goes for s and g. Just something to consider

> - @cessen proposed to add more functionality to the regular bone scale operator: while scaling, in the same way that you can limit the axis with the `x`/`y`/`z` keys, use `r` to switch to scaling the bone radius, `e` to scale the envelope, and `b` to scale the B-Bone. This can be done in a separate patch, of course. > r is part of the transform modal map and is used to switch from translation or scale to rotation during the transform. Same goes for s and g. Just something to consider
Harley Acheson commented 2023-03-14 19:42:09 +01:00
Author
Member
Copy Link

Another idea off the top of my head...

We increase the default number of Recent items shown to 20 from 10. But we also disconnect that setting from the number of items we actually read and save to the history file. We currently only read U.recent_files items into memory from the file, which truncates it the next time it is saved.

For example we could change it so that we always read, and save, 100 history items even though we continue to show only the recent_files amount. There would be no real change, except now if someone changes that preference from 10 to 20 they'd see 20 immediately, not 10 until they create more entries.

With more items saved we could then get more creative. We could treat all files with the same head as the current file specially and only show a subset. So if you open "test.blend" it could look exactly as it does now:

test.blend
yesterday5.blend
lastweek2.blend

But if you then do 50 incremental saves we could show just a subset of them like this:

test50.blend
test48.blend
test47.blend
test46.blend
------------
yesterday5.blend
lastweek2.blend

Then if load "yesterday5.blend" we then look for files in the recent list that matches that head and we also exclude items that are multiples of other files, showing only the newest, like this:

yesterday5.blend
yesterday4.blend
yesterday3.blend
----------------
test50.blend
lastweek2.blend

A nice balance might be to use no more than half of the recent list for variations of the currently-loaded file.

Re-reading this though, some of this could be done by reading the directory that the currently-loaded file is in and looking for variations rather than using the history file. Needs more thought.

Another idea off the top of my head... We increase the default number of Recent items **shown** to 20 from 10. But we also *disconnect* that setting from the number of items we actually read and save to the history file. We currently only read U.recent_files items into memory from the file, which truncates it the next time it is saved. For example we could change it so that we always read, and save, 100 history items even though we continue to show only the `recent_files` amount. There would be no real change, except now if someone changes that preference from 10 to 20 they'd see 20 immediately, not 10 until they create more entries. With more items saved we could then get more creative. We could treat all files with the same head as the current file specially and only show a subset. So if you open "test.blend" it could look exactly as it does now: ``` test.blend yesterday5.blend lastweek2.blend ``` But if you then do 50 incremental saves we could show just a subset of them like this: ``` test50.blend test48.blend test47.blend test46.blend ------------ yesterday5.blend lastweek2.blend ``` Then if load "yesterday5.blend" we then look for files in the recent list that matches that head and we also exclude items that are multiples of other files, showing only the newest, like this: ``` yesterday5.blend yesterday4.blend yesterday3.blend ---------------- test50.blend lastweek2.blend ``` A nice balance might be to use no more than half of the recent list for variations of the currently-loaded file. Re-reading this though, some of this could be done by reading the directory that the currently-loaded file is in and looking for variations rather than using the history file. Needs more thought.
Harley Acheson commented 2023-03-14 21:14:45 +01:00
Author
Member
Copy Link

@ideasman42 - For above, roughly what I am suggesting:

wm_history_file_write deduplicates. We send the items through BLI_path_sequence_decode and skip subsequent items if matching filepath, head, and tail. It would also need a maximum for total lines written (might be able to use U.recent_files).

wm_history_file_read would need to be called on file load, now only done so on program start. It would not only read the entire file, but would then prepend to g->recent_files the currently-loaded file, followed by file system items in the same directory as the loaded file that match head and tail in date order, newest first.

recent_files_menu_draw could then get fancier about drawing the G.recent_files. The first item (the currently loaded file) then some number of the following that match (if different), then a horizontal rule, then a number of other items not matching.

@ideasman42 - For above, roughly what I am suggesting: `wm_history_file_write` deduplicates. We send the items through BLI_path_sequence_decode and skip subsequent items if matching filepath, head, and tail. It would also need a maximum for total lines written (might be able to use U.recent_files). `wm_history_file_read` would need to be called on file load, now only done so on program start. It would not only read the *entire* file, but would then prepend to g->recent_files the currently-loaded file, followed by file system items in the same directory as the loaded file that match head and tail in date order, newest first. `recent_files_menu_draw` could then get fancier about drawing the G.recent_files. The first item (the currently loaded file) then some number of the following that match (if different), then a horizontal rule, then a number of other items not matching.
TheRedWaxPolice commented 2023-03-14 21:15:35 +01:00
First-time contributor
Copy Link

Wouldn't it be better to land the feature as it is, and then later on see if it's really worth it to change the standard behavior?

Wouldn't it be better to land the feature as it is, and then later on see if it's really worth it to change the standard behavior?
Harley Acheson commented 2023-03-14 21:18:55 +01:00
Author
Member
Copy Link

Wouldn't it be better to land the feature as it is, and then later on see if it's really worth it to change the standard behavior?

Yes, that would be my hope too. But addressing this issue is currently a blocker on it.

> Wouldn't it be better to land the feature as it is, and then later on see if it's really worth it to change the standard behavior? Yes, that would be my hope too. But addressing this issue is currently a blocker on it.
Jer Bot commented 2023-03-15 00:44:04 +01:00
First-time contributor
Copy Link

Just brainstorming here, as I can understand (relate) to adding some logic to manage the file list, though I think this is messing with something that everyone expected to be kept stupid simple (no filtering, no resorting, etc)

A larger list is simple solution... though this starts to emulate the full file browser, which can be distracting and/or difficult to scan.

If wanting to expand the capability (displaying more files) while keeping file loading efficient... perhaps color coding like files w/ randomly chosen colors? Or maybe thin line seprarators?

Just brainstorming here, as I can understand (relate) to adding some logic to manage the file list, though I think this is messing with something that everyone expected to be kept stupid simple (no filtering, no resorting, etc) A larger list is simple solution... though this starts to emulate the full file browser, which can be distracting and/or difficult to scan. If wanting to expand the capability (displaying more files) while keeping file loading efficient... perhaps color coding like files w/ randomly chosen colors? Or maybe thin line seprarators?
2023-03-14_2357_Blender.jpg
62 KiB
2023-03-14_2357_Blender.jpg
Campbell Barton commented 2023-03-15 01:15:00 +01:00
Owner
Copy Link

@ideasman42 - For above, roughly what I am suggesting:

wm_history_file_write deduplicates. We send the items through BLI_path_sequence_decode and skip subsequent items if matching filepath, head, and tail. It would also need a maximum for total lines written (might be able to use U.recent_files).

This has the down-side that it could de-duplicate names that happen to incidentally be detected as duplicates e.g. (anim_shot_01.blend, anim_shot_02.blend).

wm_history_file_read would need to be called on file load, now only done so on program start. It would not only read the entire file, but would then prepend to g->recent_files the currently-loaded file, followed by file system items in the same directory as the loaded file that match head and tail in date order, newest first.

This could run into awkward cases where large numbers of versions could flood the menu, there could be hard limits to the number of versions added but this seems arbitrary - making it seem as of those versions don't exist.

recent_files_menu_draw could then get fancier about drawing the G.recent_files. The first item (the currently loaded file) then some number of the following that match (if different), then a horizontal rule, then a number of other items not matching.

The "open recent" menu behavior could be changed without such disruptive changes to recent-files. The reason I requested to de-duplicate on incremental save - is at this point we know the file is intended to be handled incrementally. Attempting to detect incremental-versions can easily back-fire if files happen to be detected as incremental-versions when this wasn't the users intent.

> @ideasman42 - For above, roughly what I am suggesting: > > `wm_history_file_write` deduplicates. We send the items through BLI_path_sequence_decode and skip subsequent items if matching filepath, head, and tail. It would also need a maximum for total lines written (might be able to use U.recent_files). This has the down-side that it could de-duplicate names that happen to _incidentally_ be detected as duplicates e.g. (`anim_shot_01.blend`, `anim_shot_02.blend`). > `wm_history_file_read` would need to be called on file load, now only done so on program start. It would not only read the *entire* file, but would then prepend to g->recent_files the currently-loaded file, followed by file system items in the same directory as the loaded file that match head and tail in date order, newest first. This could run into awkward cases where large numbers of versions could flood the menu, there could be hard limits to the number of versions added but this seems arbitrary - making it seem as of those versions don't exist. > `recent_files_menu_draw` could then get fancier about drawing the G.recent_files. The first item (the currently loaded file) then some number of the following that match (if different), then a horizontal rule, then a number of other items not matching. The "open recent" menu behavior could be changed without such disruptive changes to recent-files. The reason I requested to de-duplicate on incremental save - is at this point we know the file is intended to be handled incrementally. Attempting to detect incremental-versions can easily back-fire if files happen to be detected as incremental-versions when this wasn't the users intent.
Campbell Barton commented 2023-03-15 01:24:01 +01:00
Owner
Copy Link

@JulianEisel & @pablovazquez (feedback from others in the UI team welcome too).

To avoid bike-shedding this topic, suggest the following.

Either:

  • No-deduplication:

    • Increase "Open Recent" limit to 20.
    • Commit this PR as-is.

  • De-duplicate:

    • De-duplicate incremental versions on save.
    • (Increasing "Open Recent" limit might still be done - but can be handled separately).

Personally I'd prefer de-duplicating on incremental-save but I don't consider it a blocker.

From what I can see most alternative options suggested have merit but would be best handled as separate design tasks.

@JulianEisel & @pablovazquez (feedback from others in the UI team welcome too). To avoid bike-shedding this topic, suggest the following. Either: - No-deduplication: - Increase "Open Recent" limit to 20. - Commit this PR as-is. - De-duplicate: - De-duplicate incremental versions on save. - _(Increasing "Open Recent" limit might still be done - but can be handled separately)._ Personally I'd prefer de-duplicating on incremental-save but I don't consider it a blocker. From what I can see most alternative options suggested have merit but would be best handled as separate design tasks.
Harley Acheson commented 2023-03-15 01:28:13 +01:00
Author
Member
Copy Link

@ideasman42 - The reason I requested to de-duplicate on incremental save - is at this point we know the file is intended to be handled incrementally. Attempting to detect incremental-versions can easily back-fire if files happen to be detected as incremental-versions when this wasn't the users intent.

For sure, just struggling to find something that makes everyone happy.

Unless I am misunderstanding you, your suggestion would only show one "recent" entry if the user only uses this feature. I open a file like "sample.blend" and it is added to the top of my list. Four incremental saves later I'd only have "sample4.blend" at the top of my list and none of the prior names.

We first have the issue that some users in this thread have said that they want to see those prior revision names in the list.

But we also have the issue that choosing "save as" and manually saving with an incremented name, or using the "+" button, will result in different behavior and will put all names on the list. I think this difference would get us bug reports and it would be hard to explain why this is intended behavior.

> @ideasman42 - The reason I requested to de-duplicate on incremental save - is at this point we know the file is intended to be handled incrementally. Attempting to detect incremental-versions can easily back-fire if files happen to be detected as incremental-versions when this wasn't the users intent. For sure, just struggling to find something that makes everyone happy. Unless I am misunderstanding you, your suggestion would only show one "recent" entry if the user only uses this feature. I open a file like "sample.blend" and it is added to the top of my list. Four incremental saves later I'd only have "sample4.blend" at the top of my list and none of the prior names. We first have the issue that some users in this thread have said that they want to see those prior revision names in the list. But we also have the issue that choosing "save as" and manually saving with an incremented name, or using the "+" button, will result in different behavior and will put all names on the list. I think this difference would get us bug reports and it would be hard to explain why this is intended behavior.
Campbell Barton commented 2023-03-15 01:57:39 +01:00
Owner
Copy Link

@ideasman42 - The reason I requested to de-duplicate on incremental save - is at this point we know the file is intended to be handled incrementally. Attempting to detect incremental-versions can easily back-fire if files happen to be detected as incremental-versions when this wasn't the users intent.

For sure, just struggling to find something that makes everyone happy.

Unless I am misunderstanding you, your suggestion would only show one "recent" entry if the user only uses this feature. I open a file like "sample.blend" and it is added to the top of my list. Four incremental saves later I'd only have "sample4.blend" at the top of my list and none of the prior names.

Right.

We first have the issue that some users in this thread have said that they want to see those prior revision names in the list.

Yes, users might want either behavior, it's possible we can default to one and have a preference for the other (although I'd rather avoid a preference).

But we also have the issue that choosing "save as" and manually saving with an incremented name, or using the "+" button, will result in different behavior and will put all names on the list. I think this difference would get us bug reports and it would be hard to explain why this is intended behavior.

I don't see this as a problem, mainly because the increment option for the filename is an alternative to manually re-numbering and I don't think other kinds of behavior are expected (such as skipping existing files). Further, with "Save Incremental" as a menu item & Shortcut, users who want to save many versions are unliekly to be manually opening the file selector to save, pressing the + - then expect the same behavior as "Save Incremental".

> > @ideasman42 - The reason I requested to de-duplicate on incremental save - is at this point we know the file is intended to be handled incrementally. Attempting to detect incremental-versions can easily back-fire if files happen to be detected as incremental-versions when this wasn't the users intent. > > For sure, just struggling to find something that makes everyone happy. > > Unless I am misunderstanding you, your suggestion would only show one "recent" entry if the user only uses this feature. I open a file like "sample.blend" and it is added to the top of my list. Four incremental saves later I'd only have "sample4.blend" at the top of my list and none of the prior names. Right. > We first have the issue that some users in this thread have said that they want to see those prior revision names in the list. Yes, users might want either behavior, it's possible we can default to one and have a preference for the other _(although I'd rather avoid a preference)_. > But we also have the issue that choosing "save as" and manually saving with an incremented name, or using the "+" button, will result in different behavior and will put all names on the list. I think this difference would get us bug reports and it would be hard to explain why this is intended behavior. I don't see this as a problem, mainly because the increment option for the filename is an alternative to manually re-numbering and I don't think other kinds of behavior are expected (such as skipping existing files). Further, with "Save Incremental" as a menu item & Shortcut, users who want to save many versions are unliekly to be manually opening the file selector to save, pressing the `+` - then expect the same behavior as "Save Incremental".
Campbell Barton requested review from Pablo Vazquez 2023-03-16 02:41:55 +01:00
Campbell Barton requested review from Julian Eisel 2023-03-16 02:41:56 +01:00
Campbell Barton approved these changes 2023-03-16 02:44:04 +01:00
Campbell Barton left a comment
Owner
Copy Link

Accepting, as we can consider the issue of recent files filling up the "Open Recent" separately from this PR.

@JulianEisel / @pablovazquez can double check with artists in the studio if this is worth considering a blocking issue or not.

Accepting, as we can consider the issue of recent files filling up the "Open Recent" separately from this PR. @JulianEisel / @pablovazquez can double check with artists in the studio if this is worth considering a blocking issue or not.
Harley Acheson commented 2023-03-21 17:38:42 +01:00
Author
Member
Copy Link

So, dear friends, what's the hold up?

Its being discussed by the members of the studio and the Modeling module. Mostly to make sure that we are all okay with it stealing the bbone scaling shortcut, and also for them to try it to make sure we don't have to change the Recent Files behavior first.

There's no real rush as this is only a possibility for 3.6 and we have quite a while to sort any complications out.

> So, dear friends, what's the hold up? Its being discussed by the members of the studio and the Modeling module. Mostly to make sure that we are all okay with it stealing the bbone scaling shortcut, and also for them to try it to make sure we don't have to change the Recent Files behavior first. There's no real rush as this is only a possibility for 3.6 and we have quite a while to sort any complications out.
Harley Acheson commented 2023-03-21 19:20:03 +01:00
Author
Member
Copy Link

@ThinkingPolygons ...it's 2023 after all...expecting more common sense...nonsensical delays

Although I appreciate your kind words, note that this thread is meant for technical comments about a possible new feature. This is definitely not a place to imply a lack of common sense for anyone involved in creating, evaluating, testing, or approving this feature.

> @ThinkingPolygons ...it's 2023 after all...expecting more common sense...nonsensical delays Although I appreciate your kind words, note that this thread is meant for technical comments about a possible new feature. This is definitely not a place to imply a lack of common sense for anyone involved in creating, evaluating, testing, or approving this feature.
Pablo Vazquez approved these changes 2023-04-04 12:13:14 +02:00
Pablo Vazquez left a comment
Member
Copy Link

Accepting this since the animation module has already approved the BBone shortcut change.

Accepting this since the animation module has already approved the BBone shortcut change.
Torrent commented 2023-04-07 00:14:46 +02:00
First-time contributor
Copy Link

Approved by two reviewers, is that not enough?
Perhaps I don't know how the politics work here. 🤔

Really eager to have that functionality. 🙏

Approved by two reviewers, is that not enough? Perhaps I don't know how the politics work here. 🤔 Really eager to have that functionality. 🙏
Harley Acheson commented 2023-04-07 00:23:47 +02:00
Author
Member
Copy Link

Approved by two reviewers, is that not enough?
Perhaps I don't know how the politics work here

No politics. It can just take a while to get sign off from all interested stakeholders.

Really eager to have that functionality. 🙏

It'll probably get in. Don't worry.

> Approved by two reviewers, is that not enough? > Perhaps I don't know how the politics work here No politics. It can just take a while to get sign off from all interested stakeholders. > Really eager to have that functionality. 🙏 It'll probably get in. Don't worry.
Harley Acheson force-pushed SaveIncremental from a7feeaa4eb to ac7bd05b2e 2023-05-17 22:36:28 +02:00 Compare
Harley Acheson commented 2023-06-01 17:22:55 +02:00
Author
Member
Copy Link

Noting that @pablovazquez has confirmed with the Studio that this can go in. "Gathered one last round of feedback just now. Everyone agrees the patch is good as it is now, and that (as a separate patch) would be nice to think of improvements to the Recent Files list, but not a showstopper."

So will probably merge later today.

Noting that @pablovazquez has confirmed with the Studio that this can go in. "Gathered one last round of feedback just now. Everyone agrees the patch is good as it is now, and that (as a separate patch) would be nice to think of improvements to the Recent Files list, but not a showstopper." So will probably merge later today.
Harley Acheson merged commit a58e5ccdec into main 2023-06-01 17:35:06 +02:00
Harley Acheson deleted branch SaveIncremental 2023-06-01 17:35:07 +02:00
Lsscpp commented 2023-06-08 01:23:34 +02:00
First-time contributor
Copy Link

my 2c about my workflow and incremental backup file management.
I'm used to have my wip file named something like MyAwesomeScene.blend. Anytime I want a milestone I do a "Save copy" and I name it MyAwesomeScene_1.blend
Next time it will be MyAwesomeScene_2 then MyAwesomeScene_3, 4 ,5 etc.
So, my main file will always keep the original name MyAwesomeScene.blend and I have milestones/backups copies named incrementally ordered from old (1) to newer. Still the latest file is the original MyAwesomeScene.blend

So in the end, my suggestion (based on my personal experience) would be, make an operator to both save the file and an incremental copy.

my 2c about my workflow and incremental backup file management. I'm used to have my wip file named something like MyAwesomeScene.blend. Anytime I want a milestone I do a "Save copy" and I name it MyAwesomeScene_1.blend Next time it will be MyAwesomeScene_2 then MyAwesomeScene_3, 4 ,5 etc. So, my main file will always keep the original name MyAwesomeScene.blend and I have milestones/backups copies named incrementally ordered from old (1) to newer. Still the latest file is the original MyAwesomeScene.blend So in the end, my suggestion (based on my personal experience) would be, make an operator to both save the file _and_ an incremental copy.
❤️ 1
Sign in to join this conversation.
Reviewers
No reviewers
Julian Eisel
Campbell Barton
Pablo Vazquez
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset Browser

  
Interest
Asset Browser Project Overview

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
This issue affects/is about backward or forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
EEVEE & Viewport

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Issues relating to Wayland windowing support.

  
Interest
Workbench

  
Interest: X11

Issues relating to Xorg/X11 support.

  
Legacy
Blender 2.8 Project

  
Legacy
Milestone 1: Basic, Local Asset Browser

  
Legacy
OpenGL Error

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
EEVEE & Viewport

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

  
Type
Report

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
User Interface
Assignees
Clear assignees
No Assignees
10 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#104678
No description provided.
Delete Branch "Harley/blender:SaveIncremental"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?