According to Bongo Help, I should be able to right click on a keyframe marker, and then enter a dialog to copy the marker (and the keyframe) to another location on the timeline. However, when I right click on the marker, as instructed, I get a menu panel that does not include the option to Copy the marker. Experimenting, I find I can surface this menu by right clicking anywhere on the timeline panel.
I also tried to move the marker by holding down Cntrl and dragging. No luck.
Maybe there is some pre-condition for copying the marker that has not been met?
You must first select an object which is associated with a (that) marker on the timeline.
Youâll notice that any associated markers get full-blooded read when selecting any object being associated with that marker. But if the associated object isnât selected, the marker on the timeline isnât even selectable.
I select and copy markers all the time (but itâs really silly that you need to select any object first, instead of clicking the maker directly and seeing a list of objects if more than one of that markerâŚ)
The drill is to select all objects (Ctrl-A), right click on the targeted keyframe and find a list of concerning object under the âSelectâ.
Object(s) being selected or not makes the difference in which context menu pops up: Object(s) or Timeline in general.
The âsearchâ can be refined by selecting only objects on a specific layer, or object type, or color⌠before opening the context menu.
⌠and then, if need be, further drill down to selecting an associated object (if more than one is associated with a keyframe, but only if so), selecting from the existing menu.
Exactly so. In that order. That is, in the opposite order of how it works now, The rest of the action sequence is OK (after the selection menu is started). No matter what McNeal developers think about it.
Why would one have to start with selecting ALL objects in order to even get started? (⌠when it is the frigin keyframe that the user wanted to deal with?). Typical developer logic which thinks backwards compared to users. Developers wants to âfeedâ the logic with info. User wants to do stuff in the order in which you spontaneously think about things.
The way it works now is a perfect example of how professional and intuitive UIâs are NOT designed. A tutorial of anti-patterns, sort of.
My humble plea: Fix it (addressing Bongo developers)
Thank you for your help. The problem was that I had not selected any of the onscreen objects included in the keyframe.
As Rolf remarked, it is not clear to a beginner why it is necessary to initially select an object on the screen, when the Copy or Move command, once invoked, will actually operate on a different object â i.e., a keyframe. Possibly this will sort itself out, or just become a reflex, as I get deeper into Bongo.
In any event, it would be useful if the âUsing Keyframesâ narrative in the Help section could mention and identify the first step: To Copy or Move a keyframe, one should first select an onscreen object or objects.
Many thanks for your help in pointing this out. The animation works now. Michael
But after they have fixed that annoyance, that is, made the Right Mouse Button selection menu available on a direct click on a keyframe, then the current functionality will prove to be useful as well. Namely in cases when many objects are involved in a keyframe, because in such cases it may become difficult to sort out (in the pop-up menu) which objects should be included in the selection. But in most cases that is no problem, so therefore starting the selection menu directly at the keyframe is most useful. And intuitive. And lowering the steep learning curve.
Bongo is actually a very nice piece of software. If they would just fix the user interface which is effectively hiding itâs true beauty.
In my option a keyframe is an attribute of an object (or a view, a layer, âŚ) not the other way around. A keyframe exist by the grace of his owner. Delete an object and observe his keyframes being deleted at the same time. So itâs fairly logic one has to select the object in order to change its attribute (just as an object needs to be selected to change its name, display color, texture mapping âŚ).
It must be kept in mind that a keyframe marker on the timeline at a certain tick can be a multiple of keyframes belonging to various objects. It must also be kept in mind that users may want to select various keyframes (even on various objects) eventually using a marquee.
Direct selection would need a rather elaborate (possibly confusing) right mouse button dialog to build the desired selection of object(s). The process would become laborious when multiple keyframes are at stake. I personally feel the current setup â primary select one or more objects, then pick one or more keyframe and edit â is very convenient. I myself often use the Animation manager (giving an overview of animated items) as a selection tool.
The commands BongoMoveKeyframe, BongoCopyKeyframe, Bongo DeleteKeyframe all start with an item-selection session when prior no item is selected.
BTW The technique (âdrillâ) selecting all objects I described above is only useful (in complex models) to find out which object is owner of a curious mysterious keyframe one has lost track of (âwho the f⌠do you belong to?!â). In that particular case one wishes for direct selection. The Ctrl-A trick is the solution.
You conflate what a user wants to DO with the keyframe and what the keyframe IS (technically).
User interfaces is about what you want to do with stuff, not about the class diagram relations between the objects under the hood.
The user thinks like this: âKeyframe, I want to copy a keyframe.â Then he selects the keyframe and in most cases thatâs it, he just copies it. But sometimes he realizes that "ops, more than one object has placed a keyframe at this tick - which one do I want to copy?
See? The are two thoughts here. And the two thoughts come in a certain ORDER.
And that very order is most significant, and therefore the order should dictate the approach you allow the user to take when designing the UI.
