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
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
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
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.
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
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
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
> 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
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
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
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'
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
> 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
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.
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
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
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,
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
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
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-
--
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
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
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
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
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
26 matches
Mail list logo
