This setting is useful if you use a conventional multi-pass "pose-to-pose" method for animating, where after blocking in all your key poses, you might start creating breakdowns, then doing other in-between stuff. With this setting, once you've finished your initial pass, you can just click on the next keyframe type that you'll be using for your next pass, and all the keyframes you insert from that point onwards will be the right colour.
I've been meaning to add this little feature for a few years now. It's just that everytime I've come to implementing it, I've come up against the "oh crap, you can't get access toolsettings like you can with the userprefs, as it's not a handy global", and just gone on to deal with other easier stuff. Yeah, yeah... excuses ;)
Now, if you look carefully, you may notice that the menu shows what each keyframe type looks like. I'm quite pleased to announce that was all made possible by some pretty nifty/evil voodoo that I had some fun playing around with tonight.
Proof - The Keyframe icons are dynamically generated, and are immediately updated in response to theme changes
Basically, to get it so that the icons for these look as the keyframes will in the Dope Sheet, complete with whatever theme colours you may be using), I ended up having to make these get rendered procedurally (i.e. these are dynamically generated, using the same code used to render them in the Dope Sheet timeline to render them as icons). But then, how did I manage to get these icons to be rendered procedurally instead of just being images like the rest of them?
Well, apparently Blender's UI toolkit has quite a lot of tricks up its sleeve, including some little known ancient magic/voodoo known as "VIcons" (or Vector Icons). If you're curious, these can be found in editors/interface/interface_icons.c (Note: This file also deals with loading the Brush and Matcap icons). The "VIcon" system basically makes it possible to define some icon types which can be used whereever the normal icons can be used, but with the key difference being that they are drawn at runtime using whatever theme settings are in play. This means that for things like sharp/fine lines, the resulting icons could potentially be much sharper than the raster icons that got blown up.
I also documented the steps for adding new Vector Icons like this, since it's unlikely that you'd stumble across them unless you knew where to look. (That said, they're not really something that most people should be trying to use... just in special cases like this, where a little auto-generated magic might go a long way)
Other Keyframe Type Features - On the horizon
A few weeks ago, over the course of an interesting weekend, I had a few interesting discussions with a few users and devs about keyframe type stuff. All that was started off by the following teaser:
Dalai Felinto (dalai)'s hacky prototypes of some new functionality for keyframe types
Some interesting things to come out of those discussions were that there is apparently demand for several particular things:
1) The ability to define Custom Keyframe Types - with the ability to specify the name, colour, and perhaps size too. (Realistically, most people probably only want to define about 2-5 types of these anyway I'm guessing.... Am I right? Please leave some examples of what you may use this for below in the comments :)
2) The ability to "lock" keyframes - Apparently, it's useful to be able to "lock down" sets of keyframes, so that instead of only locking on a channel by channel basis, you're able to lock down say all the keyframes from frames 100-400 where you're already happy with what you've done, while continuing to work on the stuff from 500-800. (For example, you've already blocked + polished all of the animation in the earlier section, but now the director changed their mind and wants 500-800 reblocked... To avoid losing/clobbering work, the keyframe locking functionality would come in handy). I'm currently thinking that such keyframes will probably need a different shape to make it clearer that they're "locked" - I was originally thinking of just adding a bar across them somehow, but now I'm beginning to ponder using crosses for those instead... hmm...
3) The ability to hide/filter keyframes by type - For example, hiding all your breakdowns again so that you can focus again on the timing of your key frames (or maybe to just make it easier to see where they are, and to jump between them). (There are of course some tricky interaction questions to answer here about what happens when you start moving the visible keyframes around, and whether the invisible ones should "adapt" or not to avoid being clobbered and/or getting out of sync... but that's another discussion altogether)
4) Greater awareness of keyframe types for various tools - e.g. An old request from Beorn (freen - most recently, "Glass Half" director) was that the breakdown keyframes should move proportionally to the keyframes around them. (This probably ties into the previous points about what we do when keyframes are invisible, etc.)
While I may not actually get around to working on these right now/for a few months yet (things are quite busy atm... I'm currently a bit pressed for time trying to get a study for my research work finalised, so Blender dev time has been a bit short as of late), these are some examples of things that may soon be coming to Blender.
IMO, with the greater Blender 2.8 project, I think it's time that we take a look at some other things like this where we can well start taking a second look at where we can try to push the state of the art of animation editing tools further than what's currently offered across the rest of the industry. There's a lot of interesting and potentially very powerful little stuff like this that a lot of people tend to overlook, in their pursuit of the glossy bright lights of "chasing-your-own-tail-fashion-hype-treadmills" such as creating yet another "me too" attempt at a "social media" site to gain another improbable slice of the "get rich fast" fictional pie...
(I've seen far too often that a lot of CS/SE people, when asked what they want to work on or include in their systems starting work on their Login, User Profile + Profile Management pages, and friend/contact lists attached to those, than on the real beefy issues such as how sensible it is to have tiny 6pt links on a touch screen device attached to a shaking+vibrating+swaying vehicle being operated by a stressed user under a high workload.... "we did create user personas, etc."... yeah right you did! </end sarcasm>)
Anyway, this was just a quick update on some new dev stuff heading your way. Thoughts, discussions about how these things could work?