This is a questions directed at the foundation of programming in Spine:
When I hit Save as..... and click on a file to overwrite it, WHY IS THE FILE NAME NOT SHOWN IN THE POP-UP?
It is waaay too easy to overwrite the wrong file.
"Would you like to overwrite "File name 1?" instead of "A file already exists...."
This is such a basic thing.
PLEASE...please, change this.
Save File issues
It's a good idea, we'll make the change.
If you have accidentally overwritten a project file, you may be able to recover the overwritten file from the backup folder.
Please note that we read and thoughtfully consider all forum posts. If anything, using ALL CAPS makes it less likely to get what you want.
Nate haha fair enough. it is mostly frustration coming through as i was typing that. but i will keep it in mind.
I do actually have a ton of notes of things that I would love to see changed, mostly fundamental programming stuff.
I will organize my thoughts and type them up when i can.
Thanks regardless for the consideration
No worries! Sorry you may have overwritten the wrong file. 
Cool, we're happy to hear suggestions! Currently we're finishing 4.2 for release in a few day, so we can only fit in things that are easy to implement and don't have high risk. If you have some ideas for such easy changes, we may be able to squeeze them in now.
Hello again,
I did my best to organize some thoughts I have about Spine and the changes that I would love to see implemented. Hopefully they are logical enough to be comprehensible haha.
I would really like to be able to group transform constraints (inside a folder) for organization purposes. I have projects that use one skeleton with over a dozen skins and each skin has many additional features that each require specific constraints. I have well over 100 constraints to dig through when I am adding them to skins. A folder would reduce clutter a lot without breaking the hierarchy of the constraints if the ones in the folder still count as “above” or “below” respectively.
When I hover over the small skin icon while looking at transform constraints and the constraint is only attached to 1 skin, it displays a single name (image example attached). Two things here: first, a more specific path would be better than just a simple name. (e.g., “folder name > skin name” instead of “skin name.”) And second, when you have more than one skin using the constraint, currently it just says, “3 skins.” That is very unhelpful haha. I would save a lot of time being able to see at least the names of the skins, but as suggested above, the folder path + skin name would be ideal.
While in setup mode using the filters at the top of the tree, selecting the SLOT filter essentially reorganizes the entire tree into (I think) the DRAW order of the images that are attached to each slot. For me, it makes a lot more logical sense to keep them in order of the bones they are connected to, the same way it is shown while no filter is selected.
I have some other thoughts but I think they will be harder to describe and harder to implement. The biggest one (and the one I waste more time on) has to do with targeting smaller bones with my mouse. Sometimes it feels like I click 5 or 6 times to get the right thing selected. It would be nice if, once something was selected, there was some sort of priority when your next click+drag/click+hold prioritized the selected bone instead of whatever object is bigger or close to where you are now clicking. To set out an example of this, I generally have to zoom very far in to click on my ik constraint (that I use to move some legs), and almost always end up clicking on something else first, having to hit spacebar a couple times to clear the selection, then try again. Then, once I have the ik selected, I click and drag to move it, but because I am zoomed in, I often click and move something else instead. So I have to undo, clear selection, try again, zoom out, then make my movements. It is not a clean workflow in my opinion.
The last thing I will add to this list is that it would be spectacular to see what action I am undoing with my “Ctrl+Z.” Currently, when I misclick a bone and move it (often due to the previously mentioned difficulties of selecting things) I will have to undo multiple things. But not being able to see the current action I am undoing leads to having to fix things later on or undoing too many things. This would just help people like me who make many mistakes and often experiment before finding the best placement of things.
I appreciate the consideration of these issues, as I understand that maybe I am the only one who feels this way about these things. But these issues combined make for a much less productive and honestly more frustrating work experience every time I open the program.
Thanks for your time.
- Editado
theoneonion I would really like to be able to group transform constraints (inside a folder) for organization purposes.
Sure, you can do this in 4.2!
theoneonion a more specific path would be better than just a simple name. (e.g., “folder name > skin name” instead of “skin name.”)
Also in 4.2!
theoneonion when you have more than one skin using the constraint, currently it just says, “3 skins.” That is very unhelpful haha. I would save a lot of time being able to see at least the names of the skins
We can do this. I wonder how many becomes too many. 10 I suppose.
theoneonion While in setup mode using the filters at the top of the tree, selecting the SLOT filter essentially reorganizes the entire tree into (I think) the DRAW order of the images that are attached to each slot. For me, it makes a lot more logical sense to keep them in order of the bones they are connected to
I'm not sure. The tree's bone order is alphabetical. When the bones aren't shown, the slot order would seem random, except that slots under the same bone would be near each other. If you wanted that wouldn't you enable bones in the tree? 
For example, show only bones and slots in the tree, then right click the root bone to expand everything.
theoneonion The biggest one (and the one I waste more time on) has to do with targeting smaller bones with my mouse. Sometimes it feels like I click 5 or 6 times to get the right thing selected.
Spine always gives an indicator of what will happen before you click, ie bones turn white so you know what you'll select when you click. I'd be interested in a real world example where you find a bone hard to select. For example, I'm able to easy select any of these eye bones, even when they are so tightly packed and I'm zoomed out: Image removed due to the lack of support for HTTPS. | Show Anyway
There are a few things that could help:
- If your skeleton is very small or very large, changing bone scale in the settings could help. Many (subtle) things in the viewport UI are optimized for a reasonable and most common skeleton size and the bone scale setting lets you adjust that.
- You can disable selecting attachments if the problem is you hit attachments instead of the bone you want. The details about how bone selections are chosen changes slightly when attachments can't be selected in the viewport. Also when you can't select attachments in the viewport, you can still select them in the tree, which will select them in the viewport for manipulation. This keeps you from needing to toggle attachment selection on/off.
- Try deselecting first. When you have a selection, the distance to select different objects is less.
- Zero length bones are prioritized in some situations. Instead of having a very short bone, it may be better for selection to give it zero length.
- In animate mode you can select an attachment and then use the
Select - Boneshotkey to select the bone it is under. It's not bound by default. Be sure not to confuse it with theSelect Boneshotkey, which enabled/disables selected bones in the viewport. - Are you ready for your reward for reading all these bloody bullets? This last one should not be underestimated. Prepare your mind to be blown! Press
page upandpage downto navigate your selection history. This will save you so much time! It's very common to have a selection you want, need to do something else, and want to go back to the selection you had. You can do that using these hotkeys! Don't recreate selections over and over, that is very tedious and a time waste!
theoneonion once I have the ik selected, I click and drag to move it, but because I am zoomed in, I often click and move something else instead.
One way around this is to start your drag over the selected bone. This is a little tricky, as you don't get the white hover color for already selected items, but it can still be a useful tip.
theoneonion it would be spectacular to see what action I am undoing with my “Ctrl+Z.”
You can see it at least in that what you changed goes back to before you changed it. What would you like to see? A textual description of what was undone? I'm afraid this would be pretty difficult. 
You are not alone in using undo a lot. When I'm in the situation you described, I typically undo until I press ctrl+Z and I don't see what I was working on change. At that point I know I've gone one too far, so I redo ctrl+shift+Z and now I know I'm in the right state. I do this exact same workflow when editing code, too. I undo until the cursor jumps to some other location I was working on earlier, then I redo once.
Spine's undo system is one of our proudest achievements. Developing such a system is not talked about much and users tend to under appreciate the difficulties, but undo is notoriously hard to implement well because it's very invasive at the source code level -- every action the user can do has to be able to support both undo and redo. Every single action, so you can imagine this quickly becomes many thousands of places in the source code for even a moderate sized app. There are many ways to do this poorly and in most apps it becomes a significant hurdle for adding new features and a huge source for bugs. Our solution is super slick, it is rock solid and doesn't get in the way of new development at all, but unfortunately it would be difficult to name each undo state for technical reasons.
Thanks for sharing your ideas! Feel free to bring up new ideas any time. Don't be discouraged if we can't get to all of them or we have a disagreement on how things should. I'm happy to continue discussing them and, while we have our own opinions on many things, we always remain open to seeing things from a new perspective or otherwise being convinced. 
Nate I really appreciate the timely replies and im honestly really happy to hear that some of those points are already in 4.2. That is great news for me haha.
I will work through the suggestions you listed too and see if there is anything more I feel i need to add.
Thanks for your time. I look forward to actually trying 4.2
Sounds good!
4.2 is stable and ready to change to non-beta very soon! Physics can save a lot of time, giving you tons of dynamic secondary motion for free.
theoneonion Let me add one more thing to Nate's suggestion! For bones that are difficult to select, I would recommend checking Name in the properties so that the name is displayed. This will increase the range to which they respond to mouse clicks, and is especially useful for bones that are normally created with zero bone length, such as bones for IK or controlling the orientation of a character.
The following video shows the difference in how a bone responds to the mouse when its name is displayed and when it is not:
Misaki i appreciate this addition. i will try it for the hardest-to-select bones. thanks
Good point, Misaki!
You can use the name tags on bones with low alpha, so they aren't so in your face:
The same when hovered:
un mes más tarde
Hi again
I just wanted to get back to you all about your 4.2 update. I REALLY appreciate the changes you included, notably the names included in the "added to skins list" (although i would like to see the little number still shown when a constraint is included in multiple skins). The ability to hover over the icon to see what is using the constraint is very useful for my project. Also notable is the folder in the constraints list! When I finish organizing things, it will be so much cleaner, and i have already found issues with my constraint priorities that will be solved because of this change.
I still have not had a chance to get into the physics but i will soon and really look forward to it.
Overall, I just wanted to pass on a hearty thank you for taking the time to listen to criticism.
I'm glad you are liking 4.2! Wait until you try physics, it's super cool. 
Constraint and slot folders took a few years off our lives. Funny how a seemingly simple feature can be such a major pain. The way slot folders have to work when draw order changes in animate mode is... interesting.
theoneonion notably the names included in the "added to skins list" (although i would like to see the little number still shown when a constraint is included in multiple skins)
Can you explain what you mean about constraints here?
Nate Yeah I will try to make it clear. It is a simple thing and might not matter to most people. It will help me organize, though, so it is something that would be nice.
Basically, when you have a transform constraint being used by multiple skins, you can hover over the skins icon to see which skins are being used. It would be nice to see a tiny number on the skin icon representing how many skins are included in the list without having to hover over them. Heres what I mean:
Again, not a serious issue. Just something that would speed me up a bit sometimes.
There is also something strange that is happening while I am creating new transform constraints but it's a bit hard to explain but quite annoying.
I think these screenshots will help more than words haha.
Hopefully you can tell what I am referring to here. Basically, when I am clicking through skins and bones, etc., sometimes I get to see the entire series of tree branches (on the left side), allowing me to see the tiers and indentations. But other times, the entire field of view shifts to seemingly try to line up with the beginning of the indented one I have highlighted. The issue is that it will cut off the layers above, including the folders that may need to be opened and extended for organizational reasons, forcing me to stop what I'm doing to adjust my view. In the images I linked, you can see the inconsistency when selecting two skins in the exact same tree path. One shows the complete branch path, the other shows nothing.
Hope that makes sense. If it is intended, let me know. And if it has some adjustment feature that I have missed, I would use that too haha.
Again, thanks for the time involved with going through my msgs It is much appreciated.
I should add: that field of view issue persists regardless of the width of the view panel. I use an ultra wide monitor and pulled the view as far as i could and had the same results. Trying to trouble shoot lol
I see. We can't just use a micro number, it'd have to be the standard size of other text: Image removed due to the lack of support for HTTPS. | Show Anyway
This doesn't really work visually.
The number could go next to the skin icon, with the downside that it's wider: Image removed due to the lack of support for HTTPS. | Show Anyway
It could just be an orange number (if > 1): Image removed due to the lack of support for HTTPS. | Show Anyway
This is OK, but the icon + number is probably better.
Re: the tree scrolling, it looks like it's scrolled to the right. Do you see a horizontal scrollbar at the bottom of the tree? Image removed due to the lack of support for HTTPS. | Show Anyway
I definitely like the icon + number the most, even if it is slightly wider. i think the size wouldnt be noticeable.
I do see a scroll bar. I have an ungodly number of constraints attached to my main container bone, so there can always be a scroll bar.
That is basically as wide as i can get that panel and it still does the strange shifting thing between selections.
What are you doing that you have so many constraints on the same bone?! 
It's not really useful to have so many annotations (the little icons on the right). Maybe we should limit it to 10 or so, then put an ellipsis.
Anyway, when you select an item in the tree, the tree tries to scroll right so the item fits in the available width. It will scroll right as much as possible without cutting off the left side of the selected item. Normally that is to see the text, but you have these icons and it's trying to fit them all.
We'll see about excluding the annotations. Until then you can use the scrollbar to scroll back to the left, or click an item that is more left.
The skin icons with numbers looks like this in 4.2.21 for the mix-and-match example project: Image removed due to the lack of support for HTTPS. | Show Anyway
Yeah this project is a bit wild lol. Long description short: i have 24 animals all using one skeleton (so i can reuse animations) but each animal has 5 different heads. And then there are accessories.....for each head.....
Anyway, I will not worry too much about the shifting view for now. It is a bit annoying and strange but not incapacitating.
I like that version of the annotations a lot! That is exactly what I was picturing. Especially if I can hover over it to see the list. That would be perfect.
Thanks again for taking the time to solve these issues. It really is helping make things a lot smoother for me.