[Bf-funboard] Auto-key indicator

[Bol Bib]

I think perhaps i like matjaz's solution more.
If I'm not mistaken the difference is mainly in the place where it shows? (on top of 3D view of near mouse)


Near the mouse is more useful to me.
This because I have already experienced that I REALLY don't notice it when I accidentally start the "play" button.
 The rapidly changing numbers do nothing to capture my attention when I am focussed on the center of the screen. 
And in the mean time I could be making all sorts of autokeys without me ever noticing.

So near the cursor would be a better warning for me.

> Date: Wed, 17 Oct 2012 23:13:39 +0200
> From: pawellyczkowski at gmail.com
> To: bf-funboard at blender.org
> Subject: Re: [Bf-funboard] Auto-key indicator
> 
> The version you used in your UI Playground is equally good if not better 
> than the version proposed by Matjaz. The things I like about both of 
> them: no window border used, and appearing and disappearing of UI 
> elements to attract attention used, without being intrusive.
> 
> You'd recive more feedback if you asked for it here or forums, I think.
> 
> W dniu 17-10-2012 22:59, Nicholas Rishel pisze:
> > The largest issue with this is that it is an entirely new concept to add to
> > the UI. There are a couple merits I like to judge new UI elements on -
> > please bear with me as I'm trying to collect thoughts as I write.
> >
> > 1. Is this a one-off addition?
> > One off elements are the name of the object in the corner, the 3D cursor,
> > the axis in the corner, etc. These elements clutter the frame but convey
> > enough information at any given time that they are essential to have - and
> > are usually persistent or at least showing 99% of the time. This proposal
> > would not fit into this category, so moving along...
> >
> > 2. Is it an extendable addition?
> > In effect this is asking if we can use this new element in similar ways to
> > communicate other things to the user. I would expect your proposal to fall
> > more into this category, and before adding it there would need to be a
> > discussion on what other elements could be communicated in this fashion.
> > But, I tend to not believe that this specific proposal would not work well
> > for this because...
> >
> > 3. Is it in the way or obtrusive?
> > This is where the most flags come up when this proposal. Even little
> > elements can be very distracting, flicker is nearly unacceptable for
> > anything but passive communication. The reason we accept a flickering
> > "record" image with video recorders is because there is no more effective
> > way to communicate that we are now recording: from the perspective of a
> > camera we just have a 2D image where any collection of pixels might be the
> > focus. That is why it is out of the way, but flickering to grab attention.
> > In our 3D package we do not have this constraint, we have mounds of
> > information about the scene and explicitly stated user focus based on
> > selection. To introduce new elements into the frame close to the area the
> > user works with will be effective at communicating what is happening, but
> > at a cost of gathering too much attention to itself.
> >
> > I keep meaning to do a formal write up on why I'm making the decisions I'm
> > making in UI Playground, but I haven't had a solid block of time to invest
> > into it. But in gist, the main points I tried to hit were:
> >
> > 1. Precedence: We already communicate to the user via object bounding
> > lines: selected, unselected, grouped, transforming, etc. In gist, this adds
> > no "new" elements to the UI.
> >
> > 2. Out of the way: Since no new UI elements are added, it is not in the way.
> >
> > 3. Not distracting: Since there is a precedence to communicate to the user
> > via the object outline, this should not be any more distracting that
> > existing elements of the UI.
> >
> > These are just musings on my part, I am certainly not - yet - an expert on
> > the subject. Also, I have not received ANY feedback on my work, so letting
> > me know if my assumptions are correct would be greatly appreciated. :)
> >
> > On Wed, Oct 17, 2012 at 3:22 PM, Pietro Grandi
> > <pietro.grandi.3d at gmail.com>wrote:
> >
> >> Why not? I like it!
> >> Will it be showed only when a transformation is occurring? Like
> >> translation/rotation/scale?
> >>
> >> ciao!
> >> pietro
> >>
> >> On Wed, Oct 17, 2012 at 8:22 PM, Paweł Łyczkowski <
> >> pawellyczkowski at gmail.com
> >>> wrote:
> >>> +1 to this proposal. It's less intrusive than the border option, being
> >>> more noticeable at the same time (due to appearing and disappearing),
> >>> and looks nice.
> >>>
> >>> W dniu 17-10-2012 19:20, Matjaz Lamut pisze:
> >>>> Hello,
> >>>>
> >>>> I read on the committers mailing list the red window outline and
> >> blinking
> >>>> to indicate enabled auto-key is a no go. I also noticed a graphicall
> >>> build
> >>>> called UI playground to test a possible solution, so this appears to be
> >>>> still a problem. Do you think a solution like the below proposals could
> >>>> work?
> >>>>
> >>>> https://dl.dropbox.com/u/1482587/Blender%20UI/Record-indicator.png
> >>>> https://dl.dropbox.com/u/1482587/Blender%20UI/Record-indicator1.png
> >>>>
> >>>> During translate, rotate, scale or other transform in the 3d window an
> >>>> additional icon/thingy is displayed at the mouse cursor to indicate
> >>>> auto-keyframe is enabled. It doesn't show when no transform is being
> >>> done.
> >>>> The indicator is thus out of the way most of the time, except when it
> >>>> should be visible. It is also a very small visual change to the UI,
> >> while
> >>>> always being right in front of the user, at the cursor.
> >>>>
> >>>> Matjaž
> >>>> _______________________________________________
> >>>> Bf-funboard mailing list
> >>>> Bf-funboard at blender.org
> >>>> http://lists.blender.org/mailman/listinfo/bf-funboard
> >>> _______________________________________________
> >>> Bf-funboard mailing list
> >>> Bf-funboard at blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-funboard
> >>>
> >> _______________________________________________
> >> Bf-funboard mailing list
> >> Bf-funboard at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-funboard
> >>
> > _______________________________________________
> > Bf-funboard mailing list
> > Bf-funboard at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-funboard
> 
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard