bf-blender / Windows (2005/04/18)

[joeri]

I don't dislike the ctrl.
There, now the developers can say other users like it and that blender is not about you.

It does make the move to user definable keys more difficult, i think.

Yeah, I as waiting for that. I was voicing my own opinion, and I have no doubt some do not have any problems with it. But, considering the outcry at first, I get the feeling that, like I said, people have just "accepted" it. A direct shortcut will always be the best solution, imo, and I still cannot understand why g,r,s would be a problem. But then again, I'm not a coder.

There are 2 issues here:
1. Developers that don't listen.
2. Ctrl as hotkey, or other alternatives.

1. Many answers possible, I do think they listen, sometimes they just don't agree. Saying that they do their best to harm you is just not true.
So it must be something the oposite. Somewhere in between not realy care what you think and doing the best for you.
They could be plain stuppid, but I don't believe that's the case on any in the top of development.
I think problems are caused by keeping things compatible. I realy admire the developers for trying to keep blender the same for people who upgrade but don't want to use new features, just the bug fixes.
If someone with bad habbits, like holding the ctrl for no reason, gets burned on that path then I think they should change their habbits, and not blaim the developers.

Well, GRS still works. That's the whole point, nothing is changed with the old usage. There is a new usage, with a gismowidget, it acts different on many ways, not only on ax locking but also in workflow. It needs a key and "all keys are belong to us" (all keys are taken).

Then there is this other story. Photoshop started to use holding space for paper movement, can you imagine the comments that gave? Holding the space? Have they gone mad? It's there for 6 versions now and still works perfect.
So, if you hate it okay, but how does it interfeer with your workflow?

[Bellorum]

1. Many answers possible, I do think they listen, sometimes they just don't agree. Saying that they do their best to harm you is just not true.

Well, first off, I said nothing about "harming". Neither did I say anything about developers not listening. I just said that they chose to ignore what they heard.

Well, GRS still works. That's the whole point, nothing is changed with the old usage. There is a new usage, with a gismowidget, it acts different on many ways, not only on ax locking but also in workflow. It needs a key and "all keys are belong to us" (all keys are taken).

Well, widgets are for me, just another, visual, way of transform, and for the sake of consistency it should work the same. G, R and S were never "taken". Widgets, as I see them are nothing but a new mode of transform, where those keys should work the same as in normal transform, not change back to it. This was the original implementation, and no one complained. On the other hand, when it was changed to ctrl we got one of the longest testingbuild threads ever with complaints. That should count for something?

So, if you hate it okay, but how does it interfeer with your workflow?

Did you completely ignore Solmax? It's simply not as fast as having a direct shortcut for every transform, and you do sometimes hit that ctrl just one too many times, and then you have to cycle the whole way around again. Please tell me how that is efficient, without insulting my motor skills.

[crsrma]

So, if you hate it okay, but how does it interfeer with your workflow?

Did you completely ignore Solmax? It's simply not as fast as having a direct shortcut for every transform, and you do sometimes hit that ctrl just one too many times, and then you have to cycle the whole way around again. Please tell me how that is efficient, without insulting my motor skills.

I haven't bothered with the widget in recent builds because of the interference CTRL cycling is causing. Most of the problems with it interfering with other CTRL modified commands seems to have been a lot of unnecessary work, where using the standard keys would be much more consistent, efficient & logical. Also, the cycling behavior is somewhat hit-or-miss in nature & I tend to just fallback to the header buttons, effectively negating the functionality & creating more traffic in my workflow.

There's also the business of it conflicting with the double-click CTRL hotkey that my aged KVM switchbox uses, that's not really of much importance though, as it only affects a small (me, myself & I) minority.

Just my two cents, don't want Bellorum feeling like the only nag here .

Btw, I had suggested someone try an rt: debug option, to demo GRS as an alternative, not sure if anyone has TODO'd it or not though.

[joeri]

1. Many answers possible, I do think they listen, sometimes they just don't agree. Saying that they do their best to harm you is just not true.

Well, first off, I said nothing about "harming". Neither did I say anything about developers not listening. I just said that they chose to ignore what they heard.

I did not say *you* said anything about harming, I was saying something about harming. So don't be an ass to emphasize on anything you didn't say. I'm to stuppid to understand the suttle difference between "chose to ignore" and "not listening" ie. listening is not the same as hearing.

Well, widgets are for me, just another, visual, way of transform.
Widgets, as I see them are nothing but a new mode of transform, where those keys should work the same as in normal transform

And thats where you are wrong with this implementation of the widgets.
Adding the same thing but only with a visual gizmo is a missed change.
It should add something. For example direct single ax rotation.

On the other hand, when it was changed to ctrl we got one of the longest testingbuild threads ever with complaints. That should count for something?

Why? Ofcourse more non conservative solution will give more complains, does not say anything on the quality of the complains, or the quality of the solution.

Did you completely ignore Solmax?

no

It's simply not as fast as having a direct shortcut for every transform

Its not as fast for the same thing, but it's faster for other things, thats good! That makes it a real addition.
And its not the cycle what the complains are about, it's that it is the ctrl key.

and you do sometimes hit that ctrl just one too many times, and then you have to cycle the whole way around again. Please tell me how that is efficient, without insulting my motor skills.

I'd love to insult your motor skills but I'll save that for some other time. I'd say the gizmo is a big icon-in-da-face indication of what the next one will be. So it's as efficient as S-S or G-G. If you make a mistake then yes you get the burn. But that counts for all parts in blender.

[Bellorum]

I did not say *you* said anything about harming, I was saying something about harming. So don't be an ass to emphasize on anything you didn't say.

Insert snide remark on throwing stones in a glasshouse here.

And thats where you are wrong with this implementation of the widgets.

I'll be more fair, and say that's your opinion.

Why? Ofcourse more non conservative solution will give more complains, does not say anything on the quality of the complains, or the quality of the solution.

So it was the quality of complaints that made developers ignore them? Should've have been easy to counter them.

And its not the cycle what the complains are about, it's that it is the ctrl key.

That's utter BS. It's part of the complaint, but just looking at the remarks in this thread alone will prove you wrong.

If you make a mistake then yes you get the burn. But that counts for all parts in blender.

Lovely. We wouldn't want to change that.

[arjok]

Wicked posts on keying the Widgets.

Sorry to bump into the subject, but I am using blender now for quite some time, and have to say that the current build is just awesome...

Comming back to the wicked widgets keying issue... My perspective is that this is an development in progress and therefore open to change. As a programmer myself, I just know that sometimes you have to implement a certain "under testing/review" aspect differently then eventually will be deployed within the stable version. This method is mainly used to keep current workflow in tact whilest giving the opportunity to allow users to test the new feature. Also it might be the case that due to the differences in workflow (and sorry I do not know the workflow of Blender within) it is just impossible to change or implement it in the same manner as it was.

From a GUI point of view I must say that keeping the "GRS" keys intact even with the widgets enabled, establishes the current implementation of the user interface. But this should only be done if the widget can be toggled whilest having G,R or S selected.

One thing that struck me is that the widget "All-axis" handle is not accessible when in a planar view (top, side, front, etc..)

Regards,
Art.

[solmax]

the complains are about:

- comfort:

this one is hard to argue, but it simply feels not good when using the pinky for cycling. the thumb would be much better, since at least it "feels" faster. maybe this is also because the pinky is the weakest finger, i don't know. it's like being forced to use a steering wheel with your elbows.

- speed, efficiency

using gizmos means being able to model easily in a 3D vieport and move/scale along a plane (=2 axes) at a time. this is a time saver compared to the old one-world-axis constriant (MMB). now using discrete hotkeys for each transform mode is easy to learn and fast in use. in most modelling cases you DON'T use G, R and S in this order (which would be the ideal working environment for a cycling implementation). this means quite often you need to change mode twice until you reach the mode you need. and if you overshoot the mode, you have to cycle through modes again. so in a worst case scenario, a change from R to G involves 5(!) CTRL strokes with my poor pinky, in the best case it's still 2. now please, tell me what could possibly be good about that??

and yeah, speaking of developers: I really respect them for what they do and appreciate the hard work. but being too ignorant to adress this issue is just not the right way of dealing with things. I mean this IS an issue, it has been one ever since the introduction of this controversial shortcut. and posting a fast response wouldn't take more then maybe 2 minutes!

[Bellorum]

My perspective is that this is an development in progress and therefore open to change.

I've seen no indication that this is a work in progress, more like set in stone. Especially considering release is closing in, which is why I posted my complaints in the first place.

Well, I consider this discussion over for my part. I doubt any change will be made to current behavior. But I encourage others to voice their opinions. I know I'm not the only one having issues with the current implementation.

[crsrma]

If you make a mistake then yes you get the burn. But that counts for all parts in blender.

Lovely. We wouldn't want to change that.

I dunno.. I think he's on to something there, all that punishment & burninating could make Blender quite exciting & doubly unique.

I know I crave punishment from my tools, don't think anyone could disagree.

...But this should only be done if the widget can be toggled whilest having G,R or S selected.

There's a main toggle to turn the widget (Ctrl+Space) on/off. That would seem to be enough to me, you're in that mode for a reason afterall & theoretically intend to do some modeling with it. I mean, the mousing behavior is identical after you pick your axis/axes for GRS, correct?

[-efbie-]

I don't like ctrl either, and widgets are nice but they don't look finished at all.
I hope that the widget system won't be released as it is now.
Here is some problems that i see :
- Center ball clutters the view
- When in side view, the perpendicular arrow is still shown but not used, it should not be visible
- the arrow's tails should be selectable
- scale widget can't be used to globally scale down.
- the angle "pie" flips when rotating past 180°
- the 'face align' mode, should be usable when edges / vertices are selected

[Zsolt]

BUG!!!
This is the same scaling bug, mentioned earlier by SamAdam, here's a way to duplicate it:
- in any scene, turn on widgets, switch to scale widget, and scale it in one direction.
- after this, press S to scale, and enter a number, like 2, press enter. It only sceles in the direction that the previous widget scaling worked! In fact, from now on, it will only scale in that direction. EVEN if you use scale, and enter any values for the other axes with TAB.
It seems like the widget sets some sort of flag that isn't reset later.

[MikeMLP]

Given the hostility of this thread, I know I will get flamed for this, but oh well...

I have been playing with the widgets for a while now, and I havn't found any killer features that are only available with the widgets. Are there any? If so please tell me. Also, what is this "face align mode?"

Anyway...
I'm content to work with G, S, R. I find that I like it better in widget mode where I don't have to wory about the mouses' distance from the selection dictating how big a change in G, S, R, but then again, it is much slower to move your mouse to the widget handle than it is to just hit G, S, R. I can now do multi-axis constraints with the "old" G, S, R, thanks to the new transform code. What more is there?

The widgets are fine for their first release, be thankful for what you (as a group) have and quit moaning , I'm sure they, as every aspect of blender has been, will be re-touched, and modified. Widgets are here, the concept works, that is what is important, the residual issues are minor from a users view but may not be so minor from a coder's view. Have a little patience.

[theeth]

BUG!!!
This is the same scaling bug, mentioned earlier by SamAdam, here's a way to duplicate it:
- in any scene, turn on widgets, switch to scale widget, and scale it in one direction.
- after this, press S to scale, and enter a number, like 2, press enter. It only sceles in the direction that the previous widget scaling worked! In fact, from now on, it will only scale in that direction. EVEN if you use scale, and enter any values for the other axes with TAB.
It seems like the widget sets some sort of flag that isn't reset later.

Ah, now we're getting somewhere.
I think I know what the problem is.

Martin

[theeth]

BUG!!!
This is the same scaling bug, mentioned earlier by SamAdam, here's a way to duplicate it:
- in any scene, turn on widgets, switch to scale widget, and scale it in one direction.
- after this, press S to scale, and enter a number, like 2, press enter. It only sceles in the direction that the previous widget scaling worked! In fact, from now on, it will only scale in that direction. EVEN if you use scale, and enter any values for the other axes with TAB.
It seems like the widget sets some sort of flag that isn't reset later.

Ah, now we're getting somewhere.
I think I know what the problem is.

And fixed.

Commiting soon.

Martin

[SamAdam]

BUG!!!
This is the same scaling bug, mentioned earlier by SamAdam, here's a way to duplicate it:
- in any scene, turn on widgets, switch to scale widget, and scale it in one direction.
- after this, press S to scale, and enter a number, like 2, press enter. It only sceles in the direction that the previous widget scaling worked! In fact, from now on, it will only scale in that direction. EVEN if you use scale, and enter any values for the other axes with TAB.
It seems like the widget sets some sort of flag that isn't reset later.

Ah, now we're getting somewhere.
I think I know what the problem is.

And fixed.

Commiting soon.

Martin

gracias