- 已编辑
Feature Requests and Questions Editor v4
Having worked my way through the editor (both v3 and v4) I have a few questions and feature requests:
Please add a default framerate in settings
As I understand we can change the dopesheet framerate in the playback panel. I don't really get why setting is in a completely different panel and saved (?) per project. I find myself needing to set this setting on each new project, as I'd like to use 24fps.
It would be very helpful to me if there would be a general setting to set the default framerate for the editor players. That way new projects would have that default setting and only when overwritten by the fps setting in the playback panel we get a different setting per project.
Confusing location and incomplete name for fps
Also I think the term 'dopesheet fps' is confusing and not accurate anymore. As for instance in v4 we have the graph that also adapts this framerate. I'd call this setting something more general, like 'editor FPS'.
Please change Alt behaviour while moving handle!!!
For me this is the most important one, as I find this one pretty frustrating to use to be honest (by lack of a better diplomatic word ).
For me the way alt works on handles is unintuitive and even a little weird in v4. I understand with normal dragging at first we can move handles around while both handles of a keyframe remain in sync, so move along with eachother. That's clear to me.
But than when you press and hold Alt while starting to drag a handle it moves the handle without moving the other handle. That's also clear and intuitive to me.
But than it gets weird to me. As suddenly Alt wasn't an additional key to hold during the drag-action, but now suddenly has acted like a toggle switch. As from now on the handle is loose, even without having Alt pressed; if we drag the handle the sync with the other handle is lost forever, until we re-sync it again.
Which seems to be done by moving the handle again, but now together with alt again. So suddenly Alt has got the opposite meaning; namely to re-unite the handles again. To me this is completly weird and counterintuitive.
For me either of these would make much more sense:
- only drag a single handle when alt is pressed. If alt isn't pressed we always move/rotate both handles (much preferred!!!)
- have a toggle button to switch between loose or synched (is already there I believe, but not a very fast workflow on itself)
Using alt as a permanent toggle, so stays in a state after letting go of the key, is counterintuitive as the whole point of alt, shift and ctr-keys are that they need to be pressed together with other keys to do something. Here we never press another key together with alt, but just drag a mouse, and I never seen any software using alt as a permanant toggle in such a situation.
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!
Please keep relation between handles while synching both
In vector software I use when moving one handle, with the other handle moving along (so synched), the relation/angle between both handles always remains the same. In Spine though, when moving one handle that was loose before, but than connected again to the other handle (synched), the other-side-handle jumps to be in line with the dragging handle, so loses the relation angle to the dragging handle.
To me this is unexpected and not what I want. I want the other handle to always keep the same angle around the keyframe in relation to the dragged handle. This works for instance like that in Affinity Designer; when moving a handle, the other handle always rotates around the keyframe with the moved handle so the angle between the two always remains the same. While synched. And when making the handles loose again we can change that angle between the two.
Is it possible to save looppoints?
In the editor we can set loop-points (in/out). Is it possible or would it be an idea to also save this in the file and export them to the json? I think that could be a very handy feature to animate something on screen and keep animating in a loop from the middle to the end of the animation.
Faster tooltips? Or delay setting for tooltips?
Learning Spine it's nice there are tooltips. But it takes a long time before they appear on screen, so I find myself waiting a lot for these, wondering if something's wrong. It gives the feeling the software is slow and that something is loading, eventhough I'm sure it's done on purpose to not block the view of people using the editor or whatever.
To me the tooltip-delay is way too slow now. I would like to set the delay to a much lower value. I can't find this in the settings though, the only thing I find is that we can turn it on or off. Am I missing something perhaps? 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.
Thanks!
Friebel :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 :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 :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 :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 :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 :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 :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?
Nate :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?
You write a lot of text, but basically you're saying screw every consensus in UI/UX land for years. Can't see it another way than you are trying to re-invent the wheel for everything; tooltips, usage of alt, consensus on IN and OUT in computer software for animations not for video...
There's no point in discussing things that are standardised for years / since the beginning of computers. And we are totally on the different side of the spectrum when it comes to making decisions. I'm all for not reinventing the wheel, but follow the rules everybody is using, as it's frustrating for users to learn a completely different approuch for all software programs you use and things are not a standard without a reason; it took years for things to become standard and they became a standard because that seemed the best way in the end.
You seem to overthink every of these standards, making the interface different than other software and doing weird things like using alt as a toggle, but only toggling when dragging with a mouse. That's not only counter-intuitive, but doesn't make sense at all at how alt works since the beginning of computers and the standardised way every other software out there uses it.
You were asking in another thread (the unity forum) on my thoughts on the runtimes guide/api and you write here to continue posting thoughts. But what is my time and effort worth in posting things that aren't even special, but should be acknowledged as they are standards? And what is it worth trying to convince you of things that the rest of the world already is convinced about for years and/or picked a side on? It doesn't seem to matter how much concrete evidence/comparssons/examples of this I hand out to you guys, you are not open to it.
I love Spine and I think it's cool that people keep thinking about things, but this comes across as very subborn to me. The way Alt works in the graph editor is just completely weird to the language of UI/UX and in comparisson to other software using bezier splines with handles either for animations or vector graphics.
I'm sad that this is the standpoint of Esoteric software on UI decisions. But that's your choice and not up to me. I can only hope you're open to suggestions, but I don't feel like that when it comes to these important decisions.
I quit giving suggestions now, as when you're starting doing things so differently than other software around forcing users to be confused when using comparible software / other software in the same workflow and being frustrated to switch all the time (and us something this counterintuitive), because different packages work differently, it's a waste of my time posting this.
This is not personal at all, you seem like a great guy and I think it's great you put time and effort in being on the forum and supplying indepth answers that are really helpful. And I also like Spine a lot. But in the area of UI I guess being critical on in my eyes basic stuff that shouldn't be a dicussion, it just isn't working and it's not giving me a nice feeling. So that's something that obviously isn't working for me, so I guit doing that, as it's not coming across. Sorry.
Friebel :You write a lot of text, but basically you're saying screw every consensus in UI/UX land for years. Can't see it another way than you are trying to re-invent the wheel for everything
That is not what I'm saying at all. Being common does not make a UI/UX pattern the best solution. We can't innovate if we are copying others blindly. It's much better to thoroughly understand problems and consider all solutions, not just what people are most used to. When common solutions make sense, we do that. When we can do better, we do that.
Friebel :It doesn't seem to matter how much concrete evidence/comparssons/examples of this I hand out to you guys, you are not open to it.
I don't dismiss your ideas out of hand. I address your concerns and explain myself thoroughly. Instead of continuing the discussion, this is the second time you tell me that I'm not open minded. The natural conclusion of this is that your arguments don't hold up. We are open to be convinced about any aspect of Spine, but it's not productive if we take the time to explain our decisions and then you completely dismiss everything we've said.
I think it's a pitty that you are twisting my words, turning the situation completely around and completely ignoring the gist of what I wrote. You now act like I missed your arguments? Which arguments? You didn't name any. And nothing concrete either. While you completely ignored the many factual arguments I gave you, with links and all, in my posts.
It confirms my point exactly. Unfortunately. Still expected more from you. Guess I got to know you better and the way you seem to think you need to operate. You are obviously the type of guy that wants to call 'red' 'blue' and then blame others they are critical about it and kindly ask you to call 'red' just 'red', like the rest of the world. And you call that innovating....
It's a shame.
This was the last thing I wrote here. I'm going to make my decision now. I have a very bad taste about this now and regret every effort I put into this.
You're clearly not reading my posts. It would be silly to copy and paste everything again when you can just scroll up, plus I guess you'd ignore it again. Still, I can give some examples.
Over here you claim we are using terms incorrectly. I explained we are not going to use animation terms with the opposite meaning when teaching animation theory. You ignored everything we said, instead claiming that the evidence you showed should convince us, despite it being refuted. You ranted about developers versus animators and called us closed minded and arrogant.
In this thread you say how Spine uses alt for curves is confusing and counterintuitive. I explained why we use alt that way: we want keys to stay separated, we want a hotkey for both separation and unity, that common workflows don't have confusion, etc. Instead of considering any of that, you responded with a rant about how we ignore UI/UX standards. Not only is that untrue, open Maya and Blender and 3DS and do any basic action, like move the camera around. They all do it differently, they all use alt and other hotkeys differently.
You say curves should remember the angle when the handles are separated. I explain Spine is not vector drawing software and there is no use case where that is useful. You don't respond to that at all. You rant more about how I am close minded while simultaneously refusing to consider any perspective but your own.
I tried very hard to make the discussion constructive, but you have repeatedly insisted on being rude. We won't spend any more time with you.