spineappletree wroteThe thing is that this way we could never set a keyframe further than the last keyframe we currently have and have to deal with this zoom issue EVERY NEW KEYFRAME when animating from start to finish
You simply pan to the end of your keys and set new keys. Many animators use the Next Frame (R) hotkey to move the timeline position +1 frame.
spineappletree wroteIt's not very intuitive to need to drag to put a keyframe further away. I'm used to zoom out and place keyframes where I need to. I do that in other design- and animation tools, but can't do it in Spine because of a limitiation I don't get in the first place.
When you have a long animation, why would you want to see all the keys from frame zero to the end when setting keys? To do so you'd need to zoom out a lot. That looks like this (worse if we allowed more zoom out):
Loading Image
When zoomed out like this, you can't easily set the timeline to a particular frame. Dragging the timeline position just 1 pixel makes the timeline jump by 3 or more frames. That's not accurate enough to be able to set the timeline position in most cases.
Further, if you do set keys zoomed out so far, you can't see the keys well because they are so close together:
Loading Image
To be able to work reasonably you'd need to zoom in so you can set the timeline position and see the keys:
Loading Image
spineappletree wroteWhy can't we zoom just 'endlessly'?
As mentioned, the zoom slider has a start and an end which are mapped to a minimum and maximum zoom. We could allow farther the zoom, but then the slider would no longer indicate the zoom level. While dragging the slider may not be terribly useful, looking at it to see the current zoom level can be.
The main reason however is simply because it hasn't been shown how it would be useful to zoom out farther than we currently allow. It is not useful for setting keys or the timeline position, as shown above. Navigation is the best argument in favor of a higher maximum zoom level. Not being able to zoom out to see the whole animation means panning is required to jump to a particular section. Maybe we can make the zoom out limit dynamic, so the maximum is always enough to see the entire animation.
spineappletree wroteI'm sorry, but this doesn't solve things and make things worse.
Setting the timeline FPS is the only reasonable way to make zooming out so far usable for setting keys or timeline position. When each frame has a longer duration, you can still see keys on frames when zoomed way out.
spineappletree wroteSorry if this comes across as harsh. I like Spine very much, but I don't want to lie and want and need to work with Spine a lot. This is such a crucial part of the workflow and navigation. IMO the interface on zooming is just lacking the way it is build now IMO. After posting this here I found out what you wrote here; that we can drag past the last frame, but it's so unintuitive and just feels weird and as I wrote above, like being trapped in a cage, instead of feeling free, fast, in control and creative. I can't get used to it, it slows things down, it's a frustrating workflow and it's completely unnecesary IMO.
There any number of things about the Spine UI you could claim are unintuitive and you don't like how they work because you want or expect it to work some other way. Much about building UI is about defining limits for reasonable behavior. That is done all over the place in every UI.
For a productive discussion, focus on why the limits are bothering you. It is not helpful to point at other software or claim the limits are completely unnecessary. We won't make changes to Spine because of what other software does. The Spine UI is hand built from scratch, not using any sort of ready made UI toolkit, and we have reasons for every part of its behavior. Those reasons range from "unimportant, we just choose something to make it to work" to "absolutely crucial, we can provide a long list of reasons it is the way it is". In either case, for us to make improvements we need to understand the use cases, why the current behavior is causing pain, and how the new behavior improves that. Note when we do that, we are considering ALL the use cases of all Spine users, not just yours.
We are the UI experts that you trust to build you a great animation tool. If you don't trust us to do that, then you're probably using the wrong tool. It is unproductive to repeatedly criticize our decisions and classify them as completely unnecessary. It makes getting to the point and responding to your posts more time consuming. I understand that you are passionate about Spine and frustrated, but if you would focus on the problems you are having then it would be easier for us to help. What we need is basically "this is what I want to do, this is how I'm trying to do it, this is why I find it difficult".
spineappletree wroteThe same with limits in scaling of the viewport.
The viewport zoom is a lot more complex and the zoom behavior there works better when it knows which part of the zoom range is generally usable. A higher Bone scale setting gives more maximum zoom level in the viewport.
spineappletree wrote[btw] Why do we need to log in on this forum each time we Submit a post, when we are already logged in?
It uses a cookie if you check "Remember me". It could be your browser is losing that cookie.
