Blender user interface design

I do not see the benefit of such a thing, and change behavior between controls…

Without forgetting that in blender, if we click&drag down we can edit multiple values at the same time.

with this “click set parameter” method

double click and drag and grab are automatically used less … only when necessary to be more precise in some way …

1 Like

I’m not trying to be dick. I can certainly see the advantages.

There would obviously be no issues if the numerical entry was separate from the slider. But we are using the same area for both so there are conflicts that need to be thought through.

So let’s ignore for a moment the idea of requiring a double-click for all numerical inputs.

Instead think of an input that this would apply to. An input that goes from zero to one. Displayed in there right this moment is “0.15”. What happens at the moment you click that first click in the middle of that input? Does it change to “0.5” immediately because you clicked there? Or does nothing happen, just in case this is part of a double-click?

If that first click changes the value then that would mean double-clicking on the input would end up with you manually editing a value that is now 0.5. If you instead wait, in case it is going to be a double-click, that means you are delaying every single click action by the double-click time.

Again, not trying to be a dick, just pointing out some pitfalls with such a change to the current design.

verification tests should be made.
even with other software in the case…
inkscape… the first that comes to mind

A post was merged into an existing topic: Blender UI paper cuts

What’s up with the white borders?

The 2.8 is “just” in beta, but they have many good add-ons. Plus the Add-on Tabs need more space.
My idea:

Add-On Groups

  • Add new group(s) / Delete group(s)
  • Rename group(s) ( HardSurcafes/HSurfaces/HS… for example )
  • Change group-color ( in the Preferences )
  • Add Add-on for a group in the Preferences ( and maybe with drag )
  • Change succession of tabs ( with drag )
  • Right Click on the group: Select Add-on
  • Left Click on the group: Last selected Add-on

Or… something like it. :slight_smile:

4 Likes

honestly I would prefer the use of icons instead of vertical writing, I have enabled just a few addons and I do not already understand a dick …

it would be even more preferable if the blender developers created some standard compartments with icons with these theme-colored standatrd icons, as it will be for the property panels … so addon’s writers will adjust better … and there will be less chaos.

icons with popups dialog that have the name and a brief description of the addon … many times I forget what the addons are for :joy::joy::see_no_evil:

4 Likes

Gimme this please. hahaha…

1 Like

It was proposed at least a year ago, that change the tab text by custom icons from addons or a defined icon with the shape of a big letter to replace that addons without custom icon.

1 Like

Not seeing those white borders here.

I see those borders some times, but not always. Hard to reproduce for me in that it might not do it at all when the Blender window is one size, and then does it all the time if I resize a bit first.

For me though, it does go away completely with this patch, but I don’t know enough about opengl stuff to not know it does not inadvertently screw up other things.

1 Like

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.

Thanks for the fix Harley, I had never noticed the glitch before until a recent build.

1 Like

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.

1 Like

this is how I imagine this would work

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

double click set the parameter via keyborad

1 Like

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)

if it is not too complex to encode …
I would agree to set it up optional …
I certainly do not intend to prevail other people’s preferences ^ __ ^

I’m moving this here.

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 ^ __ ^

so…

1 Like