Re: [Bf-committers] Handling of user data.
Hi Ray, Thanks for the reminder. At least I'd like to hear what the status if this issue is. However, I don't have (or want) that kind of control over individual tasks in ongoing development. The various modules in Blender should be able to act autonomously on this. What I can do is to help the module teams to function optimally, for example by finding new talent and/or allocate additional budgets. -Ton- -- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation, CEO Blender Institute / Studio Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On 09/04/2023 23:25, Ray Molenkamp via Bf-committers wrote: Ton, It's been nearly a year and we're seemingly still hurting people [1] you're a clever one! you only said it deserved priority, not that it would actually get priority, i fell for that one! I don't see this realistically happening for 3.6, but please I beg you, make it a prio for 4.0 this really has got to stop. Greetings, Ray [1]https://www.reddit.com/r/blender/comments/12f8nh9/omg_spent_hours_texture_painting_and_its_gone_any/ On 2022-05-13 7:09 a.m., Ton Roosendaal via Bf-committers wrote: Hi Ray, deleting the users data without their consent isn't OK, has never been OK, will never be OK, Fully agree with that. The list of critical issues is way too long. But this deserves top priority for fixing. -Ton- -- Ton Roosendaal -t...@blender.org -www.blender.org Chairman Blender Foundation, CEO Blender Institute / Studio Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On 12/05/2022 22:17, Ray Molenkamp via Bf-committers wrote: I don't think there's any disagreement between me and bastien we both agree it's a problem that just isn't getting the attention it deserves. The disagreement is with the people who set the priorities. Most of the priories are seemingly set by the needs of the blender studio, they have learned a long long time ago, how to "not lose data" to the point it has seemingly become a out of sight out of heart style problem. My somewhat cheeky prod on the mailing list was meant as a reminder, deleting the users data without their consent isn't OK, has never been OK, will never be OK, and we should be fixing it rather than waving it away going "it's fiiine, work on this instead" it's very much not "fine" --Ray On 2022-05-10 2:12 p.m., Zack Brown via Bf-committers wrote: Hi, I'm also curious about this issue. It seems like Ray is giving one side of the argument, but I'm not clear on the other side. This can't simply be a debate between one group that is in favor of destroying user data, and another group that opposes it. Looking at the developer task, it seems like one concern is that any solution to the problem would need to take account of workflow issues, so that production workflows won't be slowed down. I'd like to hear an example of a production workflow that relies on blender's current behavior, and how it might be slowed down if the data were simply not deleted instead. There definitely seems to be something to what Ray says, about saving users from a data-loss baptism of fire. And there also seems to be something to what Bastien says, about various big projects that currently have a higher priority than fixing a standard blender behavior that has always been this way. I know there are a lot of features I eagerly look forward to, more than fixes for some of the known misfeatures. But I also know that I got bit by the inexplicable data-loss issue myself at first, and it was a pain in the butt. Could someone take a stab at explaining what this debate really is about, in such a way that both sides would feel fairly represented? All I know right now is that there's a disagreement about something that currently feels over my head. Be well, Zack On Tue, May 10, 2022 at 9:05 PM Ray Molenkamp via Bf-committers < bf-committers@blender.org> wrote: That task is over 3 years old though, it mostly reconfirms the notion that the people who set the priorities just don't see silently destroying end user data being a problem. I hope this short thread serves as a wake-up call and this and the other core improvements you mentioned will be made more of a priority and time will actually be allocated for it in the next release cycle. But I'm not getting my hopes up here. --Ray On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote: Hi Ray, We already have a task to address this issue: https://developer.blender.org/T61209 But this needs time to be properly handled, and these days we spend everything besides regular maintenance on 'big projects', so... this one and several other relatively small core improvements and fixes keep being delayed from one release to the other. -- Bastien On 5/9/22 21:12, Ray Molenkamp via Bf-committers wrote: All, It's been years
Re: [Bf-committers] Handling of user data.
I mean the thread doesn't specify did they crash but I assume they must have since the save prompts for unsaved modified image files are on by default now? On Mon, 10 Apr 2023 at 00:27, Ray Molenkamp via Bf-committers < bf-committers@blender.org> wrote: > Ton, > > It's been nearly a year and we're seemingly still hurting people [1] > you're a clever one! > you only said it deserved priority, not that it would actually get > priority, i fell for that one! > > I don't see this realistically happening for 3.6, but please I beg you, > make it a prio for 4.0 > this really has got to stop. > > Greetings, > Ray > > [1] > https://www.reddit.com/r/blender/comments/12f8nh9/omg_spent_hours_texture_painting_and_its_gone_any/ > > On 2022-05-13 7:09 a.m., Ton Roosendaal via Bf-committers wrote: > > Hi Ray, > > > >> deleting the users data without their consent > >> isn't OK, has never been OK, will never be OK, > > > > Fully agree with that. > > > > The list of critical issues is way too long. But this deserves top > priority for fixing. > > > > -Ton- > > > > -- > > Ton Roosendaal - t...@blender.org - www.blender.org > > Chairman Blender Foundation, CEO Blender Institute / Studio > > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > > > > > On 12/05/2022 22:17, Ray Molenkamp via Bf-committers wrote: > >> I don't think there's any disagreement between me and bastien > >> we both agree it's a problem that just isn't getting the > >> attention it deserves. The disagreement is with the people who > >> set the priorities. > >> > >> Most of the priories are seemingly set by the needs of the > >> blender studio, they have learned a long long time ago, how > >> to "not lose data" to the point it has seemingly become a > >> out of sight out of heart style problem. > >> > >> My somewhat cheeky prod on the mailing list was meant as > >> a reminder, deleting the users data without their consent > >> isn't OK, has never been OK, will never be OK, and we should > >> be fixing it rather than waving it away going "it's fiiine, > >> work on this instead" it's very much not "fine" > >> > >> --Ray > >> > >> > >> > >> On 2022-05-10 2:12 p.m., Zack Brown via Bf-committers wrote: > >>> Hi, > >>> > >>> I'm also curious about this issue. It seems like Ray is giving one > side of > >>> the argument, but I'm not clear on the other side. This can't simply > be a > >>> debate between one group that is in favor of destroying user data, and > >>> another group that opposes it. > >>> > >>> Looking at the developer task, it seems like one concern is that any > >>> solution to the problem would need to take account of workflow issues, > so > >>> that production workflows won't be slowed down. I'd like to hear an > example > >>> of a production workflow that relies on blender's current behavior, > and how > >>> it might be slowed down if the data were simply not deleted instead. > >>> > >>> There definitely seems to be something to what Ray says, about saving > users > >>> from a data-loss baptism of fire. And there also seems to be something > to > >>> what Bastien says, about various big projects that currently have a > higher > >>> priority than fixing a standard blender behavior that has always been > this > >>> way. I know there are a lot of features I eagerly look forward to, more > >>> than fixes for some of the known misfeatures. But I also know that I > got > >>> bit by the inexplicable data-loss issue myself at first, and it was a > pain > >>> in the butt. > >>> > >>> Could someone take a stab at explaining what this debate really is > about, > >>> in such a way that both sides would feel fairly represented? All I know > >>> right now is that there's a disagreement about something that currently > >>> feels over my head. > >>> > >>> Be well, > >>> Zack > >>> > >>> > >>> > >>> > >>> > >>> On Tue, May 10, 2022 at 9:05 PM Ray Molenkamp via Bf-committers < > >>> bf-committers@blender.org> wrote: > >>> > That task is over 3 years old though, it mostly reconfirms > the notion that the people who set the priorities just > don't see silently destroying end user data being a problem. > > I hope this short thread serves as a wake-up call and this > and the other core improvements you mentioned will be made > more of a priority and time will actually be allocated for > it in the next release cycle. > > But I'm not getting my hopes up here. > > --Ray > On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote: > > Hi Ray, > > > > We already have a task to address this issue: > > > > https://developer.blender.org/T61209 > > > > But this needs time to be properly handled, and these days we spend > everything besides regular maintenance on 'big projects', so... this > one > and several other relatively small core improvements and fixes keep > being > delayed
Re: [Bf-committers] Handling of user data.
Ton, It's been nearly a year and we're seemingly still hurting people [1] you're a clever one! you only said it deserved priority, not that it would actually get priority, i fell for that one! I don't see this realistically happening for 3.6, but please I beg you, make it a prio for 4.0 this really has got to stop. Greetings, Ray [1] https://www.reddit.com/r/blender/comments/12f8nh9/omg_spent_hours_texture_painting_and_its_gone_any/ On 2022-05-13 7:09 a.m., Ton Roosendaal via Bf-committers wrote: > Hi Ray, > >> deleting the users data without their consent >> isn't OK, has never been OK, will never be OK, > > Fully agree with that. > > The list of critical issues is way too long. But this deserves top priority > for fixing. > > -Ton- > > -- > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation, CEO Blender Institute / Studio > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > > On 12/05/2022 22:17, Ray Molenkamp via Bf-committers wrote: >> I don't think there's any disagreement between me and bastien >> we both agree it's a problem that just isn't getting the >> attention it deserves. The disagreement is with the people who >> set the priorities. >> >> Most of the priories are seemingly set by the needs of the >> blender studio, they have learned a long long time ago, how >> to "not lose data" to the point it has seemingly become a >> out of sight out of heart style problem. >> >> My somewhat cheeky prod on the mailing list was meant as >> a reminder, deleting the users data without their consent >> isn't OK, has never been OK, will never be OK, and we should >> be fixing it rather than waving it away going "it's fiiine, >> work on this instead" it's very much not "fine" >> >> --Ray >> >> >> >> On 2022-05-10 2:12 p.m., Zack Brown via Bf-committers wrote: >>> Hi, >>> >>> I'm also curious about this issue. It seems like Ray is giving one side of >>> the argument, but I'm not clear on the other side. This can't simply be a >>> debate between one group that is in favor of destroying user data, and >>> another group that opposes it. >>> >>> Looking at the developer task, it seems like one concern is that any >>> solution to the problem would need to take account of workflow issues, so >>> that production workflows won't be slowed down. I'd like to hear an example >>> of a production workflow that relies on blender's current behavior, and how >>> it might be slowed down if the data were simply not deleted instead. >>> >>> There definitely seems to be something to what Ray says, about saving users >>> from a data-loss baptism of fire. And there also seems to be something to >>> what Bastien says, about various big projects that currently have a higher >>> priority than fixing a standard blender behavior that has always been this >>> way. I know there are a lot of features I eagerly look forward to, more >>> than fixes for some of the known misfeatures. But I also know that I got >>> bit by the inexplicable data-loss issue myself at first, and it was a pain >>> in the butt. >>> >>> Could someone take a stab at explaining what this debate really is about, >>> in such a way that both sides would feel fairly represented? All I know >>> right now is that there's a disagreement about something that currently >>> feels over my head. >>> >>> Be well, >>> Zack >>> >>> >>> >>> >>> >>> On Tue, May 10, 2022 at 9:05 PM Ray Molenkamp via Bf-committers < >>> bf-committers@blender.org> wrote: >>> That task is over 3 years old though, it mostly reconfirms the notion that the people who set the priorities just don't see silently destroying end user data being a problem. I hope this short thread serves as a wake-up call and this and the other core improvements you mentioned will be made more of a priority and time will actually be allocated for it in the next release cycle. But I'm not getting my hopes up here. --Ray On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote: > Hi Ray, > > We already have a task to address this issue: > > https://developer.blender.org/T61209 > > But this needs time to be properly handled, and these days we spend everything besides regular maintenance on 'big projects', so... this one and several other relatively small core improvements and fixes keep being delayed from one release to the other. > -- Bastien > > On 5/9/22 21:12, Ray Molenkamp via Bf-committers wrote: >> All, >> >> It's been years [1] (2018) since I last was rather >> vocal on this subject, but how is this [2] still >> happening? "Yes, blender deleted your data (and silently >> at that), that means it's working correctly!" cannot >> possibly be the best we can do, is it? >> >> While I'm excited with all the directions blender >> development is
Re: [Bf-committers] Handling of user data.
Hi Harley, > I have heard the argument that "OMG, this will make our files bloat". But you can turn such a "bloated file" into one without saved orphans with the currently existing "purge orphans" operator. You can run this all the time, make it an option to run on save, or never run it. But it leaves this to you to deal with when you want, not done *for *you. This is only a solution if you are the *only* one to ever work on that file. No one will ever risk taking responsibility for purging everyone else's data in a team/corporate setting. And having preferences for saving everything vs auto-purging will also result in data loss in a team setting or if you're working with blend files from an outside source. [1] > With the thought of (slowly) moving toward saving orphan data, the following experimental patch replaces the current File / Clean Up menu of items with a single "Clean Up" dialog that can be used remove orphans, set all orphans to fake user, or to bring up a window with Outliner set to "Orphan Data" mode so you can manage them granularly. > > https://developer.blender.org/D14030 Your patch adding improved management abilities is of course welcome, but it is not a magic bullet that can be used in all circumstances. Ryan Inch (Imaginer) [1] https://developer.blender.org/T61209#1303007 ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
Hi Dan, > Ah yes, sorry. I meant the unlinked stuff, not fake users. You know what I mean ;) Yep, I know what you mean :) > I suppose the question really comes down to what the exact problem is: the user being forgetful, or not aware of impending loss of data upon reload. > > Dialogs would certainly help in the former case, but in the latter case, I think a safety net might be more beneficial. I think they can actually work well for both those cases[1] and they do serve as a safety net. Ryan Inch (Imaginer) [1] https://www.nngroup.com/articles/confirmation-dialog/ ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
Hi Sander, > The thing with Blender is - to me as a casual user - that it's really a high end piece of software that's very flexible, but also very hard to comprehend. I think that maybe for 90%-95% of users the only things that they will ever miss are non-saved created images, materials in the shading editor and maybe actions or geometry nodes setup. > > The whole fake user concept is very useful, but also very hard to get your mind around as a casual user. > It takes quite a lot of discipline from the user to check the 'fake user shield' box for everything that you *might* want to keep when reopening the file. It's really easy to forget and overlook, because it's not easy for people to understand either. You're right that a large portion of users wouldn't mind Blender saving everything and would in fact welcome it, but a small portion of users would be very negatively impacted by that change. I don't see why we shouldn't accommodate both of their needs. While users always want easy, that's not always what they need; the main problems here are data loss at one end and too much garbage data at the other, so we need to make sure both these problems are addressed, and if the result is that users end up learning better data management practices along the way, so much the better. > It would be great if there was some sort of smart way to seperate 'intentional' user data from dat 'leftovers' i.e. stuff that might be useful when reopening a file and stuff that is essentially garbage data. Because if you don't know what the data blocks are *while* using it, going over a list upon saving and closing won't make things better. I find that usually when programs try to be "smart" and think they know better than the users, they end up causing more problems than they solve. Plus, a lot of the proposals for improved data managers include previews of the data so that you'll know exactly what you're keeping/discarding, and it's one of these improved data managers that I would expect to ultimately be shown on quit (although a simple list may be used at first while it's being developed). > https://devtalk.blender.org/t/proposal-explicit-management-of-data-blocks-and-possible-deprecation-of-fake-user/22852 > > This is a proposal that appears to be on the right track in thinking about these things. I think it's a really good idea to try and make the distinction between things you'd like to keep and the things that are fine to lose as easy as possible for the user. The easier this becomes, the less likely accidental data loss will occur. > I think that maybe for 90%-95% of users the only things that they will ever miss are non-saved created images, materials in the shading editor and maybe actions or geometry nodes setup. Actually, there are lots of cases where I don't want materials to be auto-kept, especially when you get a lot of duplicates from appending objects from other blend files. Ryan Inch (Imaginer) ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
Hi Julian, > The more dialog prompts we use in Blender, the more we make users get into the habit of just “clicking them away”, even in the wrong moments. As far as I'm concerned, the only dialog prompt would still be at quit. Yes, the habitual dialog clicking is a well recognized design issue with well recognized solutions, what comes to my mind is using specific user actions as opposed to generic OK/Cancel, being specific about what is happening (so perhaps it would be better to incorporate the data manager into the prompt, rather than just listing what types of data would be discarded), and not overusing them[1]. However, the articles you list seem to address a slightly different issue than we have here. The first one suggests to avoid them when you could implement a recovery via undo, however closing the program is not generally undo-able and even if you do save the unused data into quit.blend for a persistent session/session recovery, it still wouldn't help if you open a save. The second article seems to actually be in favor of well designed confirmation dialogs and a well designed UI in general, and of course that's what we all strive for, and well designed confirmation dialogs are a part of that (see link[1]) > The dialog box design also doesn’t cover the case of auto-save: Would we just always keep unused data in these? For the case of auto-save, yes, I would just always keep unused data there because it is a temporary file that is only used in session recovery and unlikely to be shared (once loaded from the auto-save the unused data would not be saved to a regular blend file). > Honestly, this feels like one of the cases where dialog boxes are just lazy design. We need a proper design to manage unused data in Blender. Honestly, I disagree that using a dialog box to address the issue is lazy design. We have a well designed, base system, the problem being that it isn't common, people don't know about it, and it needs some guard rails. Prompting on quit, especially if the prompt is non-standard will enlighten people to the fact that they're dealing with a different system than they're used to and provide a guard rail. > There are some ideas for this. Pretty much all of the proposed ideas in T61209, except for the ones like Mike Drake's proposal that start off with a confirmation dialog, seem to revolve around removing the garbage collection system, but if there are some that don't I would be interested to read them. > So we don’t have to rewrite things really, but develop a new data-block management UI and tools. Further management tools are definitely welcome, but the current system of purging unused data on quit is very useful and a requirement for high level workflows where you are working with blend files from outside, non-controllable sources[1]. Ryan Inch (Imaginer) [1] https://www.nngroup.com/articles/confirmation-dialog/ [2] https://devtalk.blender.org/t/blender-deleted-my-un-assigned-materials-how-is-that-a-feature-fake-user/22715/55 ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
> The core team has brought blender to where it is today, they seem to have a pretty good handle on > things...Just give 'm time, guys, they got this...I'm not sure design by committee on bf-c is what > this problem was lacking. We could revisit the topic the next time you are scheduled to bring this up again... in 2026? LOL Harley ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
The core team has bought blender to where it is today, they seem to have a pretty good handle on things. I'm not sure design by committee on bf-c is what this problem was lacking. Just give 'm time, guys, they got this. --Ray On 2022-05-17 6:19 p.m., Harley Acheson via Bf-committers wrote: >> The Idea being to put all of the unlinked stuff into some trash can of > sorts... > > That is what we would have if we would simply just save everything, with > your "trash can" > just being the items that have zero users. Then you can choose, at any > time, to remove > those items. > > These two approaches to data - only save things that are in use except for > items the user > has explicitly marked, versus saving all user data and allowing them to > delete what they > want - are not symmetrical. The former creates an emergency at the point > of exit that we > will not be able to fix with warnings. The latter removes that emergency > and allows the user > to deal with it at leisure. > > I have heard the argument that "OMG, this will make our files bloat". But > you can turn such > a "bloated file" into one without saved orphans with the currently existing > "purge orphans" > operator. You can run this all the time, make it an option to run on save, > or never run it. But > it leaves this to you to deal with when you want, not done *for *you. > > With the thought of (slowly) moving toward saving orphan data, the > following experimental > patch replaces the current File / Clean Up menu of items with a single > "Clean Up" dialog > that can be used remove orphans, set all orphans to fake user, or to bring > up a window > with Outliner set to "Orphan Data" mode so you can manage them granularly. > > https://developer.blender.org/D14030 > > Harley > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
> The Idea being to put all of the unlinked stuff into some trash can of sorts... That is what we would have if we would simply just save everything, with your "trash can" just being the items that have zero users. Then you can choose, at any time, to remove those items. These two approaches to data - only save things that are in use except for items the user has explicitly marked, versus saving all user data and allowing them to delete what they want - are not symmetrical. The former creates an emergency at the point of exit that we will not be able to fix with warnings. The latter removes that emergency and allows the user to deal with it at leisure. I have heard the argument that "OMG, this will make our files bloat". But you can turn such a "bloated file" into one without saved orphans with the currently existing "purge orphans" operator. You can run this all the time, make it an option to run on save, or never run it. But it leaves this to you to deal with when you want, not done *for *you. With the thought of (slowly) moving toward saving orphan data, the following experimental patch replaces the current File / Clean Up menu of items with a single "Clean Up" dialog that can be used remove orphans, set all orphans to fake user, or to bring up a window with Outliner set to "Orphan Data" mode so you can manage them granularly. https://developer.blender.org/D14030 Harley ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
Hi, On Tue, May 17, 2022 at 8:27 AM Ryan Inch via Bf-committers < bf-committers@blender.org> wrote: > Dan, That's an interesting suggestion about warning users ahead of time, > but it isn't the fake users that will get discarded, it's those that > aren't marked with fake user (and don't have any real users). What you > say would probably work for the first time you unlink a data-block though > :) > Ah yes, sorry. I meant the unlinked stuff, not fake users. You know what I mean ;) > I too agree that some simple indications would be much better than > rewriting the garbage collection system and I think that even just > warning the users and providing a link to documentation would be a huge > help; I don't think you would even need to include a Manage Data button > in the first iteration to see a large increase in usability. > I suppose the question really comes down to what the exact problem is: the user being forgetful, or not aware of impending loss of data upon reload. Dialogs would certainly help in the former case, but in the latter case, I think a safety net might be more beneficial. As an example, you could have some form of one time, dismissible dialog that goes into the preferences, but I'm not sure the concept of updating preferences constantly with booleans on which tooltips are dismissed would be ideal. Power users would no doubt be annoyed. I honestly wasn't going to waste any more of the thread's time on this, but a thought did cross my mind that I figured I would toss it out there for the guru's to consider, taken (conceptually) from about every OS out there: the recycle bin. The Idea being to put all of the unlinked stuff into some trash can of sorts, GUI representation I leave to your imagination, that will collect and save all unlinked objects in it, perhaps even sorted or grouped by type. From there, you could maybe implicitly save it by default with the blend file, based on a default preference so that power users could easily turn it off. Then you just need a button or action to "empty" the trash can. It would even have the secondary benefit of not requiring a full file reload to remove the unlinked options (is this already a command yet?), which I'm sure power users would love. Anyway, just some thoughts. Take care o/ ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
Maybe it's an idea before thinking about solutions, to find out what people's problems actually are that cause this to happen. I've transitioned to Blender from 3DSMax as a very casual 3D user, so my memory might be a bit rusty. But I seem to remember that if you created a material in Max' material editor it got saved even it wasn't applied to an object. So if you opened up a file whatever was present in the material editor was still present when reopening. (at least that's how I remember it) The thing with Blender is - to me as a casual user - that it's really a high end piece of software that's very flexible, but also very hard to comprehend. I think that maybe for 90%-95% of users the only things that they will ever miss are non-saved created images, materials in the shading editor and maybe actions or geometry nodes setup. The whole fake user concept is very useful, but also very hard to get your mind around as a casual user. If you're working on something you might want to try various options - say a black and white chessboard or a red and blue chessboard. It takes quite a lot of discipline from the user to check the 'fake user shield' box for everything that you *might* want to keep when reopening the file. It's really easy to forget and overlook, because it's not easy for people to understand either. It would be great if there was some sort of smart way to seperate 'intentional' user data from dat 'leftovers' i.e. stuff that might be useful when reopening a file and stuff that is essentially garbage data. Because if you don't know what the data blocks are *while* using it, going over a list upon saving and closing won't make things better. Conceptually to me there's a big overlap between 'fake users' and 'assets' They're both ways to mark data that can be used at a later time, between sessions. Reading this all back, it seems I'm basically rehashing a lot of points mentioned in https://devtalk.blender.org/t/proposal-explicit-management-of-data-blocks-and-possible-deprecation-of-fake-user/22852 This is a proposal that appears to be on the right track in thinking about these things. I think it's a really good idea to try and make the distinction between things you'd like to keep and the things that are fine to lose as easy as possible for the user. The easier this becomes, the less likely accidental data loss will occur. Sander de Regt Op 17-5-2022 om 13:38 schreef Julian Eisel via Bf-committers: Neither are great for forgetful users, but it sounds like some indications could go a long way here, compared to rewriting the garbage collection system. There is no garbage collector that would have to be rewritten really. There’s nothing that actively searches for garbage. Blender just keeps track of how often each data-block is used (important functionality to keep, regardless of this discussion), and skips saving unused ones (that don’t have a fake user). It’s more of a garbage dumper than a garbage collector :) So we don’t have to rewrite things really, but develop a new data-block management UI and tools. ——— Julian Eisel - jul...@blender.org - www.blender.org Software Developer Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On 17. May 2022, at 04:20, Dan McGrath via Bf-committers wrote: Hi, Perhaps you could add a count of things to be tossed out during quit in the save dialog, such as "If you quit, you will lose XXX number of fake user objects!". Or maybe, similar to how you warn about unsafe python scripts during start, you could give users a one time "WARNING! Fake users will be lost on quit or crash!" when they create the first fake user object. Neither are great for forgetful users, but it sounds like some indications could go a long way here, compared to rewriting the garbage collection system. On Mon, May 16, 2022 at 4:59 PM Zack Brown via Bf-committers < bf-committers@blender.org> wrote: Hi again, I feel like I have a better understanding of the debate now. On the one hand, we want to protect user data; and on the other hand, we have a garbage collector that eliminates data that the user in theory doesn't care about. And in the grey zone, we have data that the user *does* care about, but that gets garbage collected anyway. And the problem is, how to prevent the user from losing data they want to keep, while avoiding keeping data the user doesn't want to keep. It seems like one primary suggestion is to simply throw out the garbage collector -- no more garbage collector, no more problem. If the user doesn't want a piece of data in their file, they would delete it by hand. The counter-argument being that the garbage collector is actually really great and helps us keep our blend files clean and useful. Another primary suggestion seems to be issuing a warning if the user tries to quit blender with data that will be garbage collected. The
Re: [Bf-committers] Handling of user data.
Hi All, A lot of really good work on the design has already been done in T61209, and there is a very in-depth proposal on this subject with some interesting ideas and mockups for data managers, and allowing unlinked data to be edited, in this thread by LudvikKoutny on devtalk[1] (although there are a number of things in the proposal I don't agree with). Disclaimer: Most of what I say in this email comes from the discussions and mockups by the community and aren't my ideas, I'm just outlining them here to facilitate discussion :) You can see mockups of the "warning on quit" idea here[2][3] and there is actually already a precedent for doing this with unsaved images, so from what I understand, it would basically be an improvement to that system. The quit dialog would have 1. a warning icon and title that "Unused data will be lost.", 2. a line (or two) that gives a short overview of what would be discarded e.g. (13 textures, 17 materials, 12 node groups, 5 unsaved renders, etc.), 3. (optional/undecided) a link to more information on why this data is unsaved[4], 4. a button to manage data that would either bring up a data management window (such as in D14030), the asset browser in data management mode (see T61209 and the devtalk thread[1]), or (as Jacob Merrill said) show you to the outliner in it's Orphan Data mode, so that you can review and save any needed data, 5. a button to cancel quitting, and 6. a button to quit anyway and discard the data. Harley, you bring up an interesting point about how this would work when the file is also unsaved. I don't think this has been discussed yet, but currently I would expect that if the blend file is unsaved that a dialog would pop up mentioning this, without mention of the unused data, and allow you to cancel, quit anyway, or save the blend file. If you cancel, everything's good; if you quit anyway, everything's good because you don't care about unsaved data; if you save, Blender will save the file and not quit, then, when you try to quit again, Blender will pop up the dialog about unused data. If Blender changes to a Save & Quit operator then I would suggest that it just pop up the second prompt about unused data after pressing Save & Quit. The one potential problem I can see with the above is if you have just saved recently, but then altered something temporal, like the selection, then in that case the warning wouldn't come up and you could potentially lose data. To account for that case, it might be better to combine the dialogs into one with a title like "Warning: Your blend file is unsaved and also contains unused data that will be purged on quit", the short overview of unsaved data, the Manage Data button (centered), and then on the bottom row, the three normal quit dialog buttons (Don't Save (or Discard All?), Cancel, and Save). Or perhaps there would be a good way to integrate a checkbox for reviewing data, that if checked would bring up the data manager on both save and don't save? However, as Julien Eisel said, this part of the discussion should probably be moved to T61209. Zack, I'm glad you're getting a better understanding of the issues, and I agree it is a fascinating and complex problem. Your suggestion is interesting, however I don't think it's technically possible to display orphaned data in a collection. Maybe instead it would work to add an additional outliner to the default layout in Orphan Data mode? I still think warning on quit is the way to go, but more awareness of unused data throughout a creative session is potentially a good idea. Dan, That's an interesting suggestion about warning users ahead of time, but it isn't the fake users that will get discarded, it's those that aren't marked with fake user (and don't have any real users). What you say would probably work for the first time you unlink a data-block though :) I too agree that some simple indications would be much better than rewriting the garbage collection system and I think that even just warning the users and providing a link to documentation would be a huge help; I don't think you would even need to include a Manage Data button in the first iteration to see a large increase in usability. Julien, You bring up some good points, and I want to think about them more before writing an in-depth reply, but I want to say that I think the dialog prompt is more to educate/remind people of the garbage collection system, rather than to make it habit-proof. Also, I'm pretty sure that Blender's reference counting is an implementation of garbage collection[5], although not the most common :) Ryan Inch (Imaginer) [1] https://devtalk.blender.org/t/proposal-explicit-management-of-data-blocks-and-possible-deprecation-of-fake-user/22852 [2] https://developer.blender.org/T61209#1303789 [3] https://developer.blender.org/T61209#1303846 [4]
Re: [Bf-committers] Handling of user data.
> Neither are great for forgetful users, but it sounds like some indications > could go a long way here, compared to rewriting the garbage collection system. There is no garbage collector that would have to be rewritten really. There’s nothing that actively searches for garbage. Blender just keeps track of how often each data-block is used (important functionality to keep, regardless of this discussion), and skips saving unused ones (that don’t have a fake user). It’s more of a garbage dumper than a garbage collector :) So we don’t have to rewrite things really, but develop a new data-block management UI and tools. ——— Julian Eisel - jul...@blender.org - www.blender.org Software Developer Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > On 17. May 2022, at 04:20, Dan McGrath via Bf-committers > wrote: > > Hi, > > Perhaps you could add a count of things to be tossed out during quit in the > save dialog, such as "If you quit, you will lose XXX number of fake user > objects!". > > Or maybe, similar to how you warn about unsafe python scripts during start, > you could give users a one time "WARNING! Fake users will be lost on quit > or crash!" when they create the first fake user object. > > Neither are great for forgetful users, but it sounds like some indications > could go a long way here, compared to rewriting the garbage collection > system. > > On Mon, May 16, 2022 at 4:59 PM Zack Brown via Bf-committers < > bf-committers@blender.org> wrote: > >> Hi again, >> >> I feel like I have a better understanding of the debate now. On the one >> hand, we want to protect user data; and on the other hand, we have a >> garbage collector that eliminates data that the user in theory doesn't care >> about. And in the grey zone, we have data that the user *does* care about, >> but that gets garbage collected anyway. And the problem is, how to prevent >> the user from losing data they want to keep, while avoiding keeping data >> the user doesn't want to keep. >> >> It seems like one primary suggestion is to simply throw out the garbage >> collector -- no more garbage collector, no more problem. If the user >> doesn't want a piece of data in their file, they would delete it by hand. >> The counter-argument being that the garbage collector is actually really >> great and helps us keep our blend files clean and useful. >> >> Another primary suggestion seems to be issuing a warning if the user tries >> to quit blender with data that will be garbage collected. The counter >> argument being that it would be complicated and bizarre to present the user >> with a potentially dizzying array of data and options for that data before >> they could quit the software. >> >> It's a fascinating problem, in a piece of software that seems to specialize >> in presenting the most unbelievably brilliant solutions for apparently >> unsolvable problems, like how to render 3D images in glorious detail in >> real time. Obviously impossible. Yet there it is! >> >> Here's a suggestion from a non-expert who knows nuttin about nuttin: Don't >> kill the garbage collector, and don't warn on exit. Instead, why not give >> all orphaned data their own prominent collection in the outliner? Maybe >> something called "Garbage Data". With a nice set of tooltips that appear >> when the user hovers over the various relevant bits. Things that say >> something like "Data in this collection has no user and will be deleted >> when you exit blender. To prevent deletion, follow the instructions at >> http://usefuldocs.blender.org/garbage_data.php to give the data a 'fake >> user'." >> >> But I'm sure you guys will figure out something 100x better than that idea. >> Can't wait to see it! >> >> Be well, >> Zack >> >> >> >> >> >> On Mon, May 16, 2022 at 6:40 PM Jacob Merrill via Bf-committers < >> bf-committers@blender.org> wrote: >> >>> What about popping up the outliner / orphan data window in quit, and >>> showing exclamation icon somewhere if there is a orphan >>> >>> On Mon, May 16, 2022, 9:15 AM Harley Acheson via Bf-committers < >>> bf-committers@blender.org> wrote: >>> I’d love to have someone flesh out this “warning on quit” idea, >> because I can’t imagine it actually working in practice. Mostly because of confusion on what “saving” >> really means. Users should rightfully only consider that “saving their data” does exactly that, >> not that some of their data might differ and have to be “saved” in different ways. As its simplest, imagine that you have no unsaved changes in your file >>> (you just did a File/Save) yet there is orphaned data at the time you select “Quit”. What exactly does the warning say? “You have unlinked data that will be lost”? How do you communicate to >>> the user what they should do now? Is there a way to offer to do it for them
Re: [Bf-committers] Handling of user data.
Hi, Some general input. 1. Regarding the priority of addressing this: Agreed about the need to make this a high priority. Unfortunately such core design issues (there are plenty of them) are often overlooked in development planning. There is just too much other stuff that’s also important. 2. Regarding possible design solutions: I don’t want to go into a design discussion here, but since this always comes up, I want to point out that a dialog prompt isn’t a solution to me. A big issue is, it’s too easy to dismiss them: one wrong click and your data is still lost — and there’s no way to undo this. The more dialog prompts we use in Blender, the more we make users get into the habit of just “clicking them away”, even in the wrong moments. These are well recognized issues in UI design (e.g. see [1] & [2]). Additionally, we already have the “Save file on quit” dialog (which I think is a good thing), I have a hard time imagining how we could combine that with an “unused data” dialog without making things confusing and unpleasant. The dialog box design also doesn’t cover the case of auto-save: Would we just always keep unused data in these? Honestly, this feels like one of the cases where dialog boxes are just lazy design. We need a proper design to manage unused data in Blender. There are some ideas for this. [1] https://alistapart.com/article/neveruseawarning/ [2] https://www.nngroup.com/articles/error-prevention/ ——— Julian Eisel - jul...@blender.org - www.blender.org Software Developer Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > On 17. May 2022, at 04:20, Dan McGrath via Bf-committers > wrote: > > Hi, > > Perhaps you could add a count of things to be tossed out during quit in the > save dialog, such as "If you quit, you will lose XXX number of fake user > objects!". > > Or maybe, similar to how you warn about unsafe python scripts during start, > you could give users a one time "WARNING! Fake users will be lost on quit > or crash!" when they create the first fake user object. > > Neither are great for forgetful users, but it sounds like some indications > could go a long way here, compared to rewriting the garbage collection > system. > > On Mon, May 16, 2022 at 4:59 PM Zack Brown via Bf-committers < > bf-committers@blender.org> wrote: > >> Hi again, >> >> I feel like I have a better understanding of the debate now. On the one >> hand, we want to protect user data; and on the other hand, we have a >> garbage collector that eliminates data that the user in theory doesn't care >> about. And in the grey zone, we have data that the user *does* care about, >> but that gets garbage collected anyway. And the problem is, how to prevent >> the user from losing data they want to keep, while avoiding keeping data >> the user doesn't want to keep. >> >> It seems like one primary suggestion is to simply throw out the garbage >> collector -- no more garbage collector, no more problem. If the user >> doesn't want a piece of data in their file, they would delete it by hand. >> The counter-argument being that the garbage collector is actually really >> great and helps us keep our blend files clean and useful. >> >> Another primary suggestion seems to be issuing a warning if the user tries >> to quit blender with data that will be garbage collected. The counter >> argument being that it would be complicated and bizarre to present the user >> with a potentially dizzying array of data and options for that data before >> they could quit the software. >> >> It's a fascinating problem, in a piece of software that seems to specialize >> in presenting the most unbelievably brilliant solutions for apparently >> unsolvable problems, like how to render 3D images in glorious detail in >> real time. Obviously impossible. Yet there it is! >> >> Here's a suggestion from a non-expert who knows nuttin about nuttin: Don't >> kill the garbage collector, and don't warn on exit. Instead, why not give >> all orphaned data their own prominent collection in the outliner? Maybe >> something called "Garbage Data". With a nice set of tooltips that appear >> when the user hovers over the various relevant bits. Things that say >> something like "Data in this collection has no user and will be deleted >> when you exit blender. To prevent deletion, follow the instructions at >> http://usefuldocs.blender.org/garbage_data.php to give the data a 'fake >> user'." >> >> But I'm sure you guys will figure out something 100x better than that idea. >> Can't wait to see it! >> >> Be well, >> Zack >> >> >> >> >> >> On Mon, May 16, 2022 at 6:40 PM Jacob Merrill via Bf-committers < >> bf-committers@blender.org> wrote: >> >>> What about popping up the outliner / orphan data window in quit, and >>> showing exclamation icon somewhere if there is a orphan >>> >>> On Mon, May 16, 2022, 9:15 AM Harley Acheson via Bf-committers < >>>
Re: [Bf-committers] Handling of user data.
Hi, Perhaps you could add a count of things to be tossed out during quit in the save dialog, such as "If you quit, you will lose XXX number of fake user objects!". Or maybe, similar to how you warn about unsafe python scripts during start, you could give users a one time "WARNING! Fake users will be lost on quit or crash!" when they create the first fake user object. Neither are great for forgetful users, but it sounds like some indications could go a long way here, compared to rewriting the garbage collection system. On Mon, May 16, 2022 at 4:59 PM Zack Brown via Bf-committers < bf-committers@blender.org> wrote: > Hi again, > > I feel like I have a better understanding of the debate now. On the one > hand, we want to protect user data; and on the other hand, we have a > garbage collector that eliminates data that the user in theory doesn't care > about. And in the grey zone, we have data that the user *does* care about, > but that gets garbage collected anyway. And the problem is, how to prevent > the user from losing data they want to keep, while avoiding keeping data > the user doesn't want to keep. > > It seems like one primary suggestion is to simply throw out the garbage > collector -- no more garbage collector, no more problem. If the user > doesn't want a piece of data in their file, they would delete it by hand. > The counter-argument being that the garbage collector is actually really > great and helps us keep our blend files clean and useful. > > Another primary suggestion seems to be issuing a warning if the user tries > to quit blender with data that will be garbage collected. The counter > argument being that it would be complicated and bizarre to present the user > with a potentially dizzying array of data and options for that data before > they could quit the software. > > It's a fascinating problem, in a piece of software that seems to specialize > in presenting the most unbelievably brilliant solutions for apparently > unsolvable problems, like how to render 3D images in glorious detail in > real time. Obviously impossible. Yet there it is! > > Here's a suggestion from a non-expert who knows nuttin about nuttin: Don't > kill the garbage collector, and don't warn on exit. Instead, why not give > all orphaned data their own prominent collection in the outliner? Maybe > something called "Garbage Data". With a nice set of tooltips that appear > when the user hovers over the various relevant bits. Things that say > something like "Data in this collection has no user and will be deleted > when you exit blender. To prevent deletion, follow the instructions at > http://usefuldocs.blender.org/garbage_data.php to give the data a 'fake > user'." > > But I'm sure you guys will figure out something 100x better than that idea. > Can't wait to see it! > > Be well, > Zack > > > > > > On Mon, May 16, 2022 at 6:40 PM Jacob Merrill via Bf-committers < > bf-committers@blender.org> wrote: > > > What about popping up the outliner / orphan data window in quit, and > > showing exclamation icon somewhere if there is a orphan > > > > On Mon, May 16, 2022, 9:15 AM Harley Acheson via Bf-committers < > > bf-committers@blender.org> wrote: > > > > > I’d love to have someone flesh out this “warning on quit” idea, > because I > > > can’t imagine it actually > > > working in practice. Mostly because of confusion on what “saving” > really > > > means. Users should > > > rightfully only consider that “saving their data” does exactly that, > not > > > that some of their data might > > > differ and have to be “saved” in different ways. > > > > > > As its simplest, imagine that you have no unsaved changes in your file > > (you > > > just did a File/Save) > > > yet there is orphaned data at the time you select “Quit”. What exactly > > > does the warning say? > > > “You have unlinked data that will be lost”? How do you communicate to > > the > > > user what they should > > > do now? Is there a way to offer to do it for them somehow, or is this > > > warning going to just have an > > > “Ignore” and “Cancel” button? Text that says “please mark anything you > > want > > > to keep by marking > > > the data with ‘fake user’”? That will not help a typical person being > > > caught out by this > > > > > > Now imagine there are both unsaved changes and orphan data at the point > > of > > > “quit”. We now > > > have to warn about unsaved changes that can be “saved” and there are > > other > > > things that should > > > be “saved” in a different way before you “save” so that they are > actually > > > “saved”. So we have a > > > button to cancel, one to save the unsaved changes while ignoring orphan > > > data, and what else > > > is on the dialog? > > > > > > I'm not sure there is sufficient lipstick that can be put on this pig. > > > > > > Harley > > > ___ > > > Bf-committers mailing list > > > Bf-committers@blender.org > > > List details, subscription details or unsubscribe: > > >
Re: [Bf-committers] Handling of user data.
Hi again, I feel like I have a better understanding of the debate now. On the one hand, we want to protect user data; and on the other hand, we have a garbage collector that eliminates data that the user in theory doesn't care about. And in the grey zone, we have data that the user *does* care about, but that gets garbage collected anyway. And the problem is, how to prevent the user from losing data they want to keep, while avoiding keeping data the user doesn't want to keep. It seems like one primary suggestion is to simply throw out the garbage collector -- no more garbage collector, no more problem. If the user doesn't want a piece of data in their file, they would delete it by hand. The counter-argument being that the garbage collector is actually really great and helps us keep our blend files clean and useful. Another primary suggestion seems to be issuing a warning if the user tries to quit blender with data that will be garbage collected. The counter argument being that it would be complicated and bizarre to present the user with a potentially dizzying array of data and options for that data before they could quit the software. It's a fascinating problem, in a piece of software that seems to specialize in presenting the most unbelievably brilliant solutions for apparently unsolvable problems, like how to render 3D images in glorious detail in real time. Obviously impossible. Yet there it is! Here's a suggestion from a non-expert who knows nuttin about nuttin: Don't kill the garbage collector, and don't warn on exit. Instead, why not give all orphaned data their own prominent collection in the outliner? Maybe something called "Garbage Data". With a nice set of tooltips that appear when the user hovers over the various relevant bits. Things that say something like "Data in this collection has no user and will be deleted when you exit blender. To prevent deletion, follow the instructions at http://usefuldocs.blender.org/garbage_data.php to give the data a 'fake user'." But I'm sure you guys will figure out something 100x better than that idea. Can't wait to see it! Be well, Zack On Mon, May 16, 2022 at 6:40 PM Jacob Merrill via Bf-committers < bf-committers@blender.org> wrote: > What about popping up the outliner / orphan data window in quit, and > showing exclamation icon somewhere if there is a orphan > > On Mon, May 16, 2022, 9:15 AM Harley Acheson via Bf-committers < > bf-committers@blender.org> wrote: > > > I’d love to have someone flesh out this “warning on quit” idea, because I > > can’t imagine it actually > > working in practice. Mostly because of confusion on what “saving” really > > means. Users should > > rightfully only consider that “saving their data” does exactly that, not > > that some of their data might > > differ and have to be “saved” in different ways. > > > > As its simplest, imagine that you have no unsaved changes in your file > (you > > just did a File/Save) > > yet there is orphaned data at the time you select “Quit”. What exactly > > does the warning say? > > “You have unlinked data that will be lost”? How do you communicate to > the > > user what they should > > do now? Is there a way to offer to do it for them somehow, or is this > > warning going to just have an > > “Ignore” and “Cancel” button? Text that says “please mark anything you > want > > to keep by marking > > the data with ‘fake user’”? That will not help a typical person being > > caught out by this > > > > Now imagine there are both unsaved changes and orphan data at the point > of > > “quit”. We now > > have to warn about unsaved changes that can be “saved” and there are > other > > things that should > > be “saved” in a different way before you “save” so that they are actually > > “saved”. So we have a > > button to cancel, one to save the unsaved changes while ignoring orphan > > data, and what else > > is on the dialog? > > > > I'm not sure there is sufficient lipstick that can be put on this pig. > > > > Harley > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > List details, subscription details or unsubscribe: > > https://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers > -- Zack Brown ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
What about popping up the outliner / orphan data window in quit, and showing exclamation icon somewhere if there is a orphan On Mon, May 16, 2022, 9:15 AM Harley Acheson via Bf-committers < bf-committers@blender.org> wrote: > I’d love to have someone flesh out this “warning on quit” idea, because I > can’t imagine it actually > working in practice. Mostly because of confusion on what “saving” really > means. Users should > rightfully only consider that “saving their data” does exactly that, not > that some of their data might > differ and have to be “saved” in different ways. > > As its simplest, imagine that you have no unsaved changes in your file (you > just did a File/Save) > yet there is orphaned data at the time you select “Quit”. What exactly > does the warning say? > “You have unlinked data that will be lost”? How do you communicate to the > user what they should > do now? Is there a way to offer to do it for them somehow, or is this > warning going to just have an > “Ignore” and “Cancel” button? Text that says “please mark anything you want > to keep by marking > the data with ‘fake user’”? That will not help a typical person being > caught out by this > > Now imagine there are both unsaved changes and orphan data at the point of > “quit”. We now > have to warn about unsaved changes that can be “saved” and there are other > things that should > be “saved” in a different way before you “save” so that they are actually > “saved”. So we have a > button to cancel, one to save the unsaved changes while ignoring orphan > data, and what else > is on the dialog? > > I'm not sure there is sufficient lipstick that can be put on this pig. > > Harley > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
I’d love to have someone flesh out this “warning on quit” idea, because I can’t imagine it actually working in practice. Mostly because of confusion on what “saving” really means. Users should rightfully only consider that “saving their data” does exactly that, not that some of their data might differ and have to be “saved” in different ways. As its simplest, imagine that you have no unsaved changes in your file (you just did a File/Save) yet there is orphaned data at the time you select “Quit”. What exactly does the warning say? “You have unlinked data that will be lost”? How do you communicate to the user what they should do now? Is there a way to offer to do it for them somehow, or is this warning going to just have an “Ignore” and “Cancel” button? Text that says “please mark anything you want to keep by marking the data with ‘fake user’”? That will not help a typical person being caught out by this Now imagine there are both unsaved changes and orphan data at the point of “quit”. We now have to warn about unsaved changes that can be “saved” and there are other things that should be “saved” in a different way before you “save” so that they are actually “saved”. So we have a button to cancel, one to save the unsaved changes while ignoring orphan data, and what else is on the dialog? I'm not sure there is sufficient lipstick that can be put on this pig. Harley ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
In this case I find myself agreeing with Blender's definition of a bug, so: "Thanks for the report, but the issue reported here is a request for modified/improved behavior and not a bug in current behavior." But joking aside, what we have currently is a garbage collection system, it does not delete data on save, it simply doesn't save the unused data. This system works very well and allows for easy interlinking of different data to objects while keeping everything clean, provided you are aware of it and know how to use it. The major problem of why people are losing data is because they aren't aware of the system and/or forget to mark an unused data-block for saving. The easiest way to prevent data loss would be to warn users on quit of the data that won't be saved (as mentioned in Mike Drake (LichenDigital)'s proposal, although his proposal goes much further than that). If a warning on the quit dialog is implemented, along with better tools to review unused data, I think this will go a long way towards preventing data loss, educating new users, and instilling them with good data management practices, i.e. they will use the system as it's supposed to be used instead of marking everything with fake user out of fear. Perhaps this is the solution everyone has been talking about all along, but it's sounded like the prevailing opinion has been to just fake user everything which would completely break the garbage collection system. Just because everything else does it one way doesn't mean that is the best way and that we should follow suit. We currently have a very useful system that is missing safeguards, but just because it's missing the safeguards doesn't mean the whole system should be scrapped, it means that the safeguards should be implemented. Don't get me wrong, I agree that users losing data is a very bad thing, but please don't throw the baby out with the bathwater. Ryan Inch (Imaginer) P.S. I would like this to be in reply to the whole thread as of today and include all the quotes, but gmail isn't letting me, so you'll just have to imagine them. ;) ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
Hi Ray, deleting the users data without their consent isn't OK, has never been OK, will never be OK, Fully agree with that. The list of critical issues is way too long. But this deserves top priority for fixing. -Ton- -- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation, CEO Blender Institute / Studio Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On 12/05/2022 22:17, Ray Molenkamp via Bf-committers wrote: I don't think there's any disagreement between me and bastien we both agree it's a problem that just isn't getting the attention it deserves. The disagreement is with the people who set the priorities. Most of the priories are seemingly set by the needs of the blender studio, they have learned a long long time ago, how to "not lose data" to the point it has seemingly become a out of sight out of heart style problem. My somewhat cheeky prod on the mailing list was meant as a reminder, deleting the users data without their consent isn't OK, has never been OK, will never be OK, and we should be fixing it rather than waving it away going "it's fiiine, work on this instead" it's very much not "fine" --Ray On 2022-05-10 2:12 p.m., Zack Brown via Bf-committers wrote: Hi, I'm also curious about this issue. It seems like Ray is giving one side of the argument, but I'm not clear on the other side. This can't simply be a debate between one group that is in favor of destroying user data, and another group that opposes it. Looking at the developer task, it seems like one concern is that any solution to the problem would need to take account of workflow issues, so that production workflows won't be slowed down. I'd like to hear an example of a production workflow that relies on blender's current behavior, and how it might be slowed down if the data were simply not deleted instead. There definitely seems to be something to what Ray says, about saving users from a data-loss baptism of fire. And there also seems to be something to what Bastien says, about various big projects that currently have a higher priority than fixing a standard blender behavior that has always been this way. I know there are a lot of features I eagerly look forward to, more than fixes for some of the known misfeatures. But I also know that I got bit by the inexplicable data-loss issue myself at first, and it was a pain in the butt. Could someone take a stab at explaining what this debate really is about, in such a way that both sides would feel fairly represented? All I know right now is that there's a disagreement about something that currently feels over my head. Be well, Zack On Tue, May 10, 2022 at 9:05 PM Ray Molenkamp via Bf-committers < bf-committers@blender.org> wrote: That task is over 3 years old though, it mostly reconfirms the notion that the people who set the priorities just don't see silently destroying end user data being a problem. I hope this short thread serves as a wake-up call and this and the other core improvements you mentioned will be made more of a priority and time will actually be allocated for it in the next release cycle. But I'm not getting my hopes up here. --Ray On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote: Hi Ray, We already have a task to address this issue: https://developer.blender.org/T61209 But this needs time to be properly handled, and these days we spend everything besides regular maintenance on 'big projects', so... this one and several other relatively small core improvements and fixes keep being delayed from one release to the other. -- Bastien On 5/9/22 21:12, Ray Molenkamp via Bf-committers wrote: All, It's been years [1] (2018) since I last was rather vocal on this subject, but how is this [2] still happening? "Yes, blender deleted your data (and silently at that), that means it's working correctly!" cannot possibly be the best we can do, is it? While I'm excited with all the directions blender development is currently going, it's utterly depressing that users are still losing data on a daily basis because we can't quite get the basics right like "do not delete the users data without their consent". These are *NOT* isolated incidents [3]. Losing your data and learning about "the fake user" shouldn't be a right of passage to become "a real blender user". Users shouldn't be silently *losing* data in an operation ironically called *saving*. That's crazy, no other application behaves like this! Yes, I know this is how we have always done it. No, this is not OK, never was. Ton: Please make protecting the user’s data a priority, as it doesn’t seem this will happen otherwise. --Ray [1]https://devtalk.blender.org/t/oh-no/505/2 [2]https://developer.blender.org/T97968 [3]https://devtalk.blender.org/t/more/22715 ___ Bf-committers mailing list Bf-committers@blender.org List details,
Re: [Bf-committers] Handling of user data.
I don't think there's any disagreement between me and bastien we both agree it's a problem that just isn't getting the attention it deserves. The disagreement is with the people who set the priorities. Most of the priories are seemingly set by the needs of the blender studio, they have learned a long long time ago, how to "not lose data" to the point it has seemingly become a out of sight out of heart style problem. My somewhat cheeky prod on the mailing list was meant as a reminder, deleting the users data without their consent isn't OK, has never been OK, will never be OK, and we should be fixing it rather than waving it away going "it's fiiine, work on this instead" it's very much not "fine" --Ray On 2022-05-10 2:12 p.m., Zack Brown via Bf-committers wrote: > Hi, > > I'm also curious about this issue. It seems like Ray is giving one side of > the argument, but I'm not clear on the other side. This can't simply be a > debate between one group that is in favor of destroying user data, and > another group that opposes it. > > Looking at the developer task, it seems like one concern is that any > solution to the problem would need to take account of workflow issues, so > that production workflows won't be slowed down. I'd like to hear an example > of a production workflow that relies on blender's current behavior, and how > it might be slowed down if the data were simply not deleted instead. > > There definitely seems to be something to what Ray says, about saving users > from a data-loss baptism of fire. And there also seems to be something to > what Bastien says, about various big projects that currently have a higher > priority than fixing a standard blender behavior that has always been this > way. I know there are a lot of features I eagerly look forward to, more > than fixes for some of the known misfeatures. But I also know that I got > bit by the inexplicable data-loss issue myself at first, and it was a pain > in the butt. > > Could someone take a stab at explaining what this debate really is about, > in such a way that both sides would feel fairly represented? All I know > right now is that there's a disagreement about something that currently > feels over my head. > > Be well, > Zack > > > > > > On Tue, May 10, 2022 at 9:05 PM Ray Molenkamp via Bf-committers < > bf-committers@blender.org> wrote: > >> That task is over 3 years old though, it mostly reconfirms >> the notion that the people who set the priorities just >> don't see silently destroying end user data being a problem. >> >> I hope this short thread serves as a wake-up call and this >> and the other core improvements you mentioned will be made >> more of a priority and time will actually be allocated for >> it in the next release cycle. >> >> But I'm not getting my hopes up here. >> >> --Ray >> On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote: >>> Hi Ray, >>> >>> We already have a task to address this issue: >>> >>> https://developer.blender.org/T61209 >>> >>> But this needs time to be properly handled, and these days we spend >> everything besides regular maintenance on 'big projects', so... this one >> and several other relatively small core improvements and fixes keep being >> delayed from one release to the other. >>> -- Bastien >>> >>> On 5/9/22 21:12, Ray Molenkamp via Bf-committers wrote: All, It's been years [1] (2018) since I last was rather vocal on this subject, but how is this [2] still happening? "Yes, blender deleted your data (and silently at that), that means it's working correctly!" cannot possibly be the best we can do, is it? While I'm excited with all the directions blender development is currently going, it's utterly depressing that users are still losing data on a daily basis because we can't quite get the basics right like "do not delete the users data without their consent". These are *NOT* isolated incidents [3]. Losing your data and learning about "the fake user" shouldn't be a right of passage to become "a real blender user". Users shouldn't be silently *losing* data in an operation ironically called *saving*. That's crazy, no other application behaves like this! Yes, I know this is how we have always done it. No, this is not OK, never was. Ton: Please make protecting the user’s data a priority, as it doesn’t seem this will happen otherwise. --Ray [1] https://devtalk.blender.org/t/oh-no/505/2 [2] https://developer.blender.org/T97968 [3] https://devtalk.blender.org/t/more/22715 ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>>
Re: [Bf-committers] Handling of user data.
Hi, I'm also curious about this issue. It seems like Ray is giving one side of the argument, but I'm not clear on the other side. This can't simply be a debate between one group that is in favor of destroying user data, and another group that opposes it. Looking at the developer task, it seems like one concern is that any solution to the problem would need to take account of workflow issues, so that production workflows won't be slowed down. I'd like to hear an example of a production workflow that relies on blender's current behavior, and how it might be slowed down if the data were simply not deleted instead. There definitely seems to be something to what Ray says, about saving users from a data-loss baptism of fire. And there also seems to be something to what Bastien says, about various big projects that currently have a higher priority than fixing a standard blender behavior that has always been this way. I know there are a lot of features I eagerly look forward to, more than fixes for some of the known misfeatures. But I also know that I got bit by the inexplicable data-loss issue myself at first, and it was a pain in the butt. Could someone take a stab at explaining what this debate really is about, in such a way that both sides would feel fairly represented? All I know right now is that there's a disagreement about something that currently feels over my head. Be well, Zack On Tue, May 10, 2022 at 9:05 PM Ray Molenkamp via Bf-committers < bf-committers@blender.org> wrote: > That task is over 3 years old though, it mostly reconfirms > the notion that the people who set the priorities just > don't see silently destroying end user data being a problem. > > I hope this short thread serves as a wake-up call and this > and the other core improvements you mentioned will be made > more of a priority and time will actually be allocated for > it in the next release cycle. > > But I'm not getting my hopes up here. > > --Ray > On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote: > > Hi Ray, > > > > We already have a task to address this issue: > > > > https://developer.blender.org/T61209 > > > > But this needs time to be properly handled, and these days we spend > everything besides regular maintenance on 'big projects', so... this one > and several other relatively small core improvements and fixes keep being > delayed from one release to the other. > > > > -- Bastien > > > > On 5/9/22 21:12, Ray Molenkamp via Bf-committers wrote: > >> All, > >> > >> It's been years [1] (2018) since I last was rather > >> vocal on this subject, but how is this [2] still > >> happening? "Yes, blender deleted your data (and silently > >> at that), that means it's working correctly!" cannot > >> possibly be the best we can do, is it? > >> > >> While I'm excited with all the directions blender > >> development is currently going, it's utterly depressing that > >> users are still losing data on a daily basis because > >> we can't quite get the basics right like "do not delete the > >> users data without their consent". > >> > >> These are *NOT* isolated incidents [3]. Losing your > >> data and learning about "the fake user" shouldn't be > >> a right of passage to become "a real blender user". > >> Users shouldn't be silently *losing* data in an operation > >> ironically called *saving*. That's crazy, no other > >> application behaves like this! > >> > >> Yes, I know this is how we have always done it. No, > >> this is not OK, never was. > >> Ton: Please make protecting the user’s data a > >> priority, as it doesn’t seem this will happen otherwise. > >> > >> --Ray > >> > >> > >> [1] https://devtalk.blender.org/t/oh-no/505/2 > >> [2] https://developer.blender.org/T97968 > >> [3] https://devtalk.blender.org/t/more/22715 > >> > >> ___ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> List details, subscription details or unsubscribe: > >> https://lists.blender.org/mailman/listinfo/bf-committers > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > List details, subscription details or unsubscribe: > > https://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers > -- Zack Brown ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
That task is over 3 years old though, it mostly reconfirms the notion that the people who set the priorities just don't see silently destroying end user data being a problem. I hope this short thread serves as a wake-up call and this and the other core improvements you mentioned will be made more of a priority and time will actually be allocated for it in the next release cycle. But I'm not getting my hopes up here. --Ray On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote: > Hi Ray, > > We already have a task to address this issue: > > https://developer.blender.org/T61209 > > But this needs time to be properly handled, and these days we spend > everything besides regular maintenance on 'big projects', so... this one and > several other relatively small core improvements and fixes keep being delayed > from one release to the other. > > -- Bastien > > On 5/9/22 21:12, Ray Molenkamp via Bf-committers wrote: >> All, >> >> It's been years [1] (2018) since I last was rather >> vocal on this subject, but how is this [2] still >> happening? "Yes, blender deleted your data (and silently >> at that), that means it's working correctly!" cannot >> possibly be the best we can do, is it? >> >> While I'm excited with all the directions blender >> development is currently going, it's utterly depressing that >> users are still losing data on a daily basis because >> we can't quite get the basics right like "do not delete the >> users data without their consent". >> >> These are *NOT* isolated incidents [3]. Losing your >> data and learning about "the fake user" shouldn't be >> a right of passage to become "a real blender user". >> Users shouldn't be silently *losing* data in an operation >> ironically called *saving*. That's crazy, no other >> application behaves like this! >> >> Yes, I know this is how we have always done it. No, >> this is not OK, never was. >> Ton: Please make protecting the user’s data a >> priority, as it doesn’t seem this will happen otherwise. >> >> --Ray >> >> >> [1] https://devtalk.blender.org/t/oh-no/505/2 >> [2] https://developer.blender.org/T97968 >> [3] https://devtalk.blender.org/t/more/22715 >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> List details, subscription details or unsubscribe: >> https://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
Hi Ray, I agree that this is a serious issue and would like to see this resolved. The good news is that it's actively being discussed[1][2][3] and there is, what seems to me, a good proposal[4] by Mike Drake (LichenDigital) that has had no major objections and seems to show an understanding of both sides of this, complex, contentious, issue. If this proposal does not have one already, I propose that it be given an official branch to allow development and testing, at least to some basic degree of functionality (some parts of the proposal would require significant development time and so are impractical to include), so that it can be practically determined if it would meet the needs of peoples' diverse workflows. From what I've seen Mike Drake (LichenDigital) seems to be working hard with the community on this issue, and I think would be open to implementing his proposal as a branch, if asked. Ryan Inch (Imaginer) [1] https://devtalk.blender.org/t/blender-deleted-my-un-assigned-materials-how-is-that-a-feature-fake-user/22715 [2] https://devtalk.blender.org/t/proposal-explicit-management-of-data-blocks-and-possible-deprecation-of-fake-user/22852 [3] https://developer.blender.org/T61209 [4] https://developer.blender.org/T61209#1304227 On 2022-05-10 06:00 AM, bf-committers-requ...@blender.org wrote: Message: 2 Date: Mon, 9 May 2022 13:12:09 -0600 From: Ray Molenkamp To: bf-blender developers Subject: [Bf-committers] Handling of user data. Message-ID:<016967e8-df31-886c-1e33-4dfef0c3e...@lazydodo.com> Content-Type: text/plain; charset=UTF-8 All, It's been years [1] (2018) since I last was rather vocal on this subject, but how is this [2] still happening? "Yes, blender deleted your data (and silently at that), that means it's working correctly!" cannot possibly be the best we can do, is it? While I'm excited with all the directions blender development is currently going, it's utterly depressing that users are still losing data on a daily basis because we can't quite get the basics right like "do not delete the users data without their consent". These are*NOT* isolated incidents [3]. Losing your data and learning about "the fake user" shouldn't be a right of passage to become "a real blender user". Users shouldn't be silently*losing* data in an operation ironically called*saving*. That's crazy, no other application behaves like this! Yes, I know this is how we have always done it. No, this is not OK, never was. Ton: Please make protecting the user’s data a priority, as it doesn’t seem this will happen otherwise. --Ray [1]https://devtalk.blender.org/t/oh-no/505/2 [2]https://developer.blender.org/T97968 [3]https://devtalk.blender.org/t/more/22715 ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Handling of user data.
Hi Ray, We already have a task to address this issue: https://developer.blender.org/T61209 But this needs time to be properly handled, and these days we spend everything besides regular maintenance on 'big projects', so... this one and several other relatively small core improvements and fixes keep being delayed from one release to the other. -- Bastien On 5/9/22 21:12, Ray Molenkamp via Bf-committers wrote: All, It's been years [1] (2018) since I last was rather vocal on this subject, but how is this [2] still happening? "Yes, blender deleted your data (and silently at that), that means it's working correctly!" cannot possibly be the best we can do, is it? While I'm excited with all the directions blender development is currently going, it's utterly depressing that users are still losing data on a daily basis because we can't quite get the basics right like "do not delete the users data without their consent". These are *NOT* isolated incidents [3]. Losing your data and learning about "the fake user" shouldn't be a right of passage to become "a real blender user". Users shouldn't be silently *losing* data in an operation ironically called *saving*. That's crazy, no other application behaves like this! Yes, I know this is how we have always done it. No, this is not OK, never was. Ton: Please make protecting the user’s data a priority, as it doesn’t seem this will happen otherwise. --Ray [1] https://devtalk.blender.org/t/oh-no/505/2 [2] https://developer.blender.org/T97968 [3] https://devtalk.blender.org/t/more/22715 ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
