Feedback on this UI tweak to communicate that autokey is enabled would be appreciated: http://www.graphicall.org/1009
On Sun, Oct 14, 2012 at 10:44 PM, Nathan Vegdahl <[email protected]> wrote: > Fair enough. > > I only ever use autokey with "only key available" enabled, so unless > something already has animation on it, it doesn't insert keys. I find > it preferable, because even in scenes that I am animating, there are > often objects that shouldn't be animated but still may need to be > adjusted (especially in layout phase). > > I forget that a lot of people don't work with that option enabled, > though. For me, personally, I would love for these settings to not be > carried with blend files. But I can see that's pretty specific to the > settings I use. > > --Nathan > > > On Sun, Oct 14, 2012 at 5:24 AM, Bol Bib <[email protected]> wrote: > > I hope I'm forgiven for adding my 2 cents in a mainly developper centric > mailing list. > > > > as an animator I will tell you that is a bad idea. > > for 2 reasons > > 1)The > > default preferences file is at the moment not versatile enough to > > tinker with User preferences on this level (not unless the GSOC > > concerning user preferences by vino gets included in trunk) > > > > plus it would not be apparent that this saves with the preferences as it > is an ACTION not a preference (imo) > > > > > > 2) > > if I were to have a default of autokey on in my settings then that > > means that even when I'm modeling,texture painting or other stuff before > > I even get near animating ,I will have to close the autokey every time I > > open a blend. (If I understand you well enough,I might be mistaken) > > > > This seems counterproductive even if it's a wellmeaning idea. > > > > Autokey should only be activated when you are in animating stage,and > that means imo it should be a blend preference,not a default in User > preferences. > > > > > > > > A decent way of communicating/displaying that autokey is on should be > good enough...whatever way the blender devs agree upon....IMO > > > > > > pardon my intrusion ^^ > > > > > > > > > >> Message: 10 > >> Date: Sun, 14 Oct 2012 00:40:33 -0700 > >> From: Nathan Vegdahl <[email protected]> > >> Subject: Re: [Bf-committers] Autokey and 3D viewport outline > >> To: bf-blender developers <[email protected]> > >> Message-ID: > >> < > cae91w2vuiohe8gbsd8nnrbkjdrdvskxlamf+zyhq4hrce6p...@mail.gmail.com> > >> Content-Type: text/plain; charset=ISO-8859-1 > >> > >> > I would be very opposed to disabling auto-key on load > >> > >> I think you may have misunderstood me. I am not suggesting that > >> autokey be disabled every time you load Blender or a new file. I'm > >> suggesting that autokey and related settings should be a setting that > >> does not get carried around by blend files. > >> > >> So, for example, an animator that uses autokey would turn it on and > >> save it as part of their default settings. Then it would always be on > >> for them, even if they open someone else's file. > >> > >> Similarly, an animator (or other user) that does not use autokey would > >> turn it off, and save _that_ as part of their default settings. Then > >> it would always be off for them, even if they open someone else's > >> file. > >> > >> In short, I think that autokey and related settings may be a poor > >> thing for normal blend files to carry around. Some (most?) settings > >> are great for blend files to carry around. But I'm thinking autokey > >> may not be one of them. > >> > >> --Nathan > >> > >> > >> On Fri, Oct 12, 2012 at 9:31 PM, Daniel Salazar - 3Developer.com > >> <[email protected]> wrote: > >> > I would be very opposed to disabling auto-key on load, in the past it > >> > was like that and resulted in lost work for animators all the time. If > >> > an animator is activly working on a shot he should not have to > >> > remember to activate autokey every time he/she goes for a coffee break > >> > or switches files. > >> > > >> > I think the way it is current is getting quite close to what it should > >> > be. Maybe a bit of a stronger hint wont hurt but it's certainly more > >> > flashy than a static icon on the timeline > >> > > >> > Daniel Salazar > >> > patazstudio.com > >> > > >> > > >> > On Fri, Oct 12, 2012 at 10:20 PM, Nathan Vegdahl <[email protected]> > wrote: > >> >> Maybe we should take an entirely different approach to this. > >> >> > >> >> What if we just make auto-key settings not loaded from blend files by > >> >> default? That way people keep the auto-key prefs they're used to. > It > >> >> doesn't seem like this is the kind of setting that makes sense to > >> >> carry along with blend files anyway. It's very specific to people's > >> >> own workflows. > >> >> > >> >> Then there is no need for an indicator in the first place. > >> >> > >> >> --Nathan > >> >> > >> >> > >> >> On Fri, Oct 12, 2012 at 9:17 PM, Nathan Vegdahl <[email protected]> > wrote: > >> >>>> It's fine to have an indicator that autokey is on, > >> >>>> it just doesn't need to look as if something bad is happening. > >> >>> > >> >>> Just keep in mind that the original motivation of all of this was > that > >> >>> the auto-key toggle in the timeline was not visually obvious enough. > >> >>> > >> >>> In general, there is going to be a conflict between the purpose of > the > >> >>> feature and people who are annoyed by its non-subtley. We already > >> >>> have a subtle indicator: the auto-key toggle button. The entire > point > >> >>> of this is to _not_ be subtle. > >> >>> > >> >>> (And incidentally, now that you mention it, I agree, red should be > >> >>> reserved for errors.) > >> >>> > >> >>> --Nathan > >> >>> > >> >>> > >> >>> On Mon, Oct 8, 2012 at 11:43 PM, Brecht Van Lommel > >> >>> <[email protected]> wrote: > >> >>>> It was made optional now in svn, but I think that does not really > >> >>>> address the issue. It's fine to have an indicator that autokey is > on, > >> >>>> it just doesn't need to look as if something bad is happening. Red > >> >>>> should be reserved for errors. There is no need for a warning/error > >> >>>> here, just good feedback about what is happening. > >> >>>> > >> >>>> For example improve the blinking so that it's more like the report > >> >>>> message blinking in the info header (which is better visible), show > >> >>>> the autokey icon in the 3D view header or next to the object name, > >> >>>> color the header a bit yellow, or show a report that X keyframes > were > >> >>>> inserted after transform is done. I don't know which combination > works > >> >>>> best but the red border is just too much and the current blinking > is > >> >>>> not very visible by itself. > >> >>>> > >> >>>> Brecht. > >> >>>> > >> >>>> On Mon, Oct 8, 2012 at 3:19 PM, Francesco Siddi > >> >>>> <[email protected]> wrote: > >> >>>>> Hello, > >> >>>>> > >> >>>>> a new feature has recently been introduced in Blender: when > Autokey is > >> >>>>> turned on and some object/armature transformation is performed, > every 3D > >> >>>>> viewport gets a red outline and a message reminding the user of > the fact > >> >>>>> the a keyframe will be created at the end of the transformation. > >> >>>>> > >> >>>>> After talking with other users, it seems clear that this feature > should at > >> >>>>> least be optional, if not off by default. It's quite distracting > to work > >> >>>>> with a flashing outline all the time. > >> >>>>> > >> >>>>> Thank you! > >> >>>>> Francesco > >> >>>>> _______________________________________________ > >> >>>>> Bf-committers mailing list > >> >>>>> [email protected] > >> >>>>> http://lists.blender.org/mailman/listinfo/bf-committers > >> >>>> _______________________________________________ > >> >>>> Bf-committers mailing list > >> >>>> [email protected] > >> >>>> http://lists.blender.org/mailman/listinfo/bf-committers > >> >> _______________________________________________ > >> >> Bf-committers mailing list > >> >> [email protected] > >> >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > _______________________________________________ > >> > Bf-committers mailing list > >> > [email protected] > >> > http://lists.blender.org/mailman/listinfo/bf-committers > >> > >> > >> ------------------------------ > >> > >> _______________________________________________ > >> Bf-committers mailing list > >> [email protected] > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > >> > >> End of Bf-committers Digest, Vol 99, Issue 14 > >> ********************************************* > > > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
