On Tue, Jun 11, 2013 at 8:49 PM, Brecht Van Lommel <[email protected]> wrote: > Hi, > > On Tue, Jun 11, 2013 at 8:35 AM, Campbell Barton <[email protected]> wrote: >> - Asking to reload a file is OK, but what if you haven't saved the >> file? (eg, you load a new file and append an object with a driver). >> Currently the reload button is just removed in this case and you can >> only choose to ignore the warning. > > I think this message should disappear as soon as you do any operation, > same as other messages from operator. Then it can be ignored it > without having to do anything.
This message intentionally expects a user action because the blend file may behave totally broken if scripts don't run. Some users click around aimlessly. they might immediately perform some action on load that cancels the message, or for some reason another message replaces it so fast they are unaware scripts are disabled. We risk users overlooking the warning message, then thinking blender is broken or whoever made the blend-file made a mistake. For most reports this is OK, but for rigs I worry it means the difference between blender working or not. > The red (X) button also looks more "threatening" than the reload > button to me. Further I think the message should be changed, "Script > failed to auto-run" makes it sound like it actually tried to run the > script but there was some error? I suggest: > > [ (i) Auto-run script 'some_script.py' disabled | Reload Trusted | Ignore ] > > It would also be nice if this could follow the same styling as operator > reports. Good suggestions, committed r57384. it looks like this now: [ (i) Auto-run disabled: Text 'some_script.py' | Reload Trusted | Ignore ] Changed a little because the text may be a driver expression which can be very long and makes the message not read so clearly. >> Note, many reasonable suggestions have been made in this thread, but >> at this point I don't think its useful to reply to all. >> >> Next Ill check on ways for users to selectively trust blend files for >> their own projects so this behavior isn't annoying users. > > Perhaps what we could do is store a list of .blend file hashes that > were trusted or created by the user somewhere. Main disadvantage with hashes is if you work with others on a shared repo, changed hashes will be common then you also have to manage clearing old hashes - its doable but would like something thats easier for users to manage if possible. > Brecht. > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
