Friebel escribióPlease add a default framerate in settings
Confusing location and incomplete name for fps
A default framerate setting makes sense, we'll add it. Renaming the setting also makes sense.
It is saved per project because projects may want different framerates. The setting is on the playback view because the settings dialog does not contain any project specific settings. The setting applies to the graph, dopesheet, timeline, and audio views, so doesn't make sense to place on only one of those. It could be on all, but having so many places for the same setting isn't great. I think it's OK on the playback view. It's also relatively rare to change it, even more so once there is a default.
Friebel escribióPlease change Alt behaviour while moving handle!!!
Rather than only being separated when alt is held, once separated the handles stay separated because it is otherwise quite annoying to work with separated handles. We had it that way to begin with but it's very easy to forget to hold alt when moving a handle, causing the other handle to match the angle, then you have to undo and drag again holding alt. When that happens repeatedly it disrupts workflows. When a key has separated handles you almost always want them to stay separated when moving a handle later, so that is what we do.
Alt is a shortcut to separate the handles for a key. The discoverable way to do the same is to click a key or handle, then click the separate button in the toolbar. Note that separated handles have a slightly different icon so you can tell they are separated, and also the separate button is highlighted when the key or handles are selected.
If handles are already separated, alt is a shortcut to synchronize them again, the same as the separate button. Since we want separated handles to stay separated, I think this makes sense. If alt were to always separate and have no effect if already separated, there would be no shortcut to synchronize the handles.
Friebel escribióPlease revert this while not everybody is used to this to me weird counterintuitive behaviour to: toggling SINGLE HANDLE on alt down and BOTH HANDLES AGAIN on alt up!
Keeping separated handles separated is a feature that we want for the reasons above. I do not think it is a problem that alt is also used to synchronize the handles again. Exploring the UI is a bit different from using it for real workflows. A typical workflow is to drag handles around and when you need to separate handles you press alt. That is what gets used most of the time. I don't see it as a problem that you can press alt again to synchronize the handles.
Friebel escribióPlease keep relation between handles while synching both
I understand it works as you described in other software, however that is insufficient to convince us the feature is needed. Note that will always be the case for any feature, as we do not make decisions based solely on what other software does. Can you describe the use cases where keeping the angle is helpful? It may have uses for vector graphics but I have never been able to come up with a good reason for this behavior in Spine's graph.
Friebel escribióIs it possible to save looppoints?
Note that Spine supports multiple skeletons in the same project. That means the same timeline can be used for multiple animations at once, so some timeline related features can be trickier than they look at first.
We've considered features to mark a middle portion of an animation as looping, but it currently isn't possible. A workaround is to create an animation with the start, middle, and end parts, then when done copy each of those to other animations. I understand that is not ideal, of course. Another workaround is to use the Spine Runtimes API, which can loop a portion of an animation. I do understand it would be more convenient to define in the editor.
Friebel escribióFaster tooltips? Or delay setting for tooltips?
You can press F1 to get tooltips right away. You can also turn off tooltips in the settings and then you'll only get tooltips when pressing F1.
Friebel escribióIt would be nice if either the tooltips would have the same speed as Windows tooltips in other programs (that's what I'd expect and feels natural now) or that we could set the delay for tooltips ourselves in the settings.
A lot of software shows tooltips too soon and it can be frustrating to have unwanted tooltips over your work. A lot of software also resets the timer when you mouse over a new object. Eg, you mouse over something, wait, the tooltip shows, oops it's not what you want, you mouse over the next thing, wait again
this takes a lot of time to explore the UI. In Spine you wait longer initially (because wanting to see tooltips is relatively rare), but once shown you can mouse over everything else to see the tooltips right away. Once you know about F1 the initial wait is no longer an issue.
Thanks for all the feedback! Feel free to continue discussion where we don't agree. By sharing our reasoning it's not my intent to shoot down your ideas, but rather to be transparent and allow you to make the appropriate arguments. If something is really better we'll do that, we just need to be shown why it's better. We're always opened to be convinced! If we don't have the bandwidth to get it done right away, we'll create an issue so it doesn't get lost. BTW, have you seen our roadmap?
