I’d like to suggest that when a user opens a 2.79 or earlier file in 2.80 with the “Load UI” option checked that we should warn the user that the old UI layouts may not be compatible or appropriate for 2.80 and ask them whether they really want to load the old UI stuff or not.
Or somehow make the Load UI checkbox default to no for old files, but that probably requires peeking into the files before the user explicitly gives us permission to open and load them, so it may not be a good idea.
Or maybe there could be a separate “Load old UIs” checkbox that would default to no and would apply instead of the Load UI checkbox if the file is from an “old” version.
You’re very welcome. I’m not certain that is the best fix, or even if the problem is wide-spread - could only affect me and you for all we know. LOL.
I am certain the problem is caused inside that one function, but it could be that my understanding of the issue is incorrect and so my fix may not make sense. We’ll see though when it hits Brecht’s desk.
example of a “click set slider” range from -1 to +1
-1 … 0 … +1
at “zero zone” click, is set to zero
at borders click is set to -1 or +1
at drag and slide “infinitely” right or left, it works like the classic way that sets the desired numbering
shift + drag sets a more precise parameter
ctrl + drag sets a parameter multiplied in speed
I think it would be fairly easy to get everything you are looking for if double-click is required to change all numerical entries using keyboard. But I’d guess it is that change that is the hardest sell. It would be making all numerical entry harder (from single-click to double-click) for a feature that only makes one type of entry a bit better.
But again, correct me if you are not asking to change every entry to require double-click for manual entry. If it is only for bounded inputs then we have the problem of not knowing what you can single- versus double-click on, as shown in above illustration (IOR versus the rest)
I do indeed use shift+drag, though I rarely use dragging at all. I know the values I want to input and it is simply faster and more accurate to type them in.
I’m not going to just believe someone who says “It’s slow, because”, without evidence, reasoning, not even a theory. I’ve been using blender plenty long myself (I’m not going to check), but atleast I provided some reasons.
shift/ctrl+drag wasn’t in the original proposal, though it solves some issues, it doesn’t solve them all. And as @Harleya pointed out, the largest issue is simply consistency in the ui field elements.
But, to the main point, in real scenarios, The suggested new way is only faster marginally, if you want to go and change a bunch of random sliders to vague values.
this is a much clearer explanation … you do not want sliders of any kind, only to be able to set parameters as quickly as possible …
so you do not ask yourself the problem of slowness to stay to drag the sliders every time ^ __ ^
There seems to be some overlap between this thread and the paper cuts thread, so…
There was a huge discussion about the top bar in here earlier, and perhaps someone already mentioned it, but I couldn’t see someone pointing out this particular issue I have with it:
Also, I think this deserves its own thread, but it is really disappointing the way that add-ons now are very hidden by default. And, if you look at blenderartists discussions, some add-ons want floating dialogue windows so badly that they roll their own, which doesn’t feel very consistent.
Did you see the 404 maxon.net page? I guess it’s a attempt of pressure on unconscious. Or just a declaration of something. Something like “we see blender rollin’, we hatin’”.
not when it’s messy and inconsistent.
Like depending on scale some become 2 colums, some 3, some 1, some no matter what always stay being one.
So it makes keeping track of were stuff is very difficult, either do it right or dont do it.
