[Bf-committers] Re: [Bf-blender-cvs] ....(knife tool)
Tue, 14 Oct 2003 11:14:58 +1000
> >The interaction is something we should reconstruct. This includes 2
> >successive modes which only confuse, and don't work in a way compatible
> >with the rest of Blender.
> There is nothing else in blender that works this way, because there is
> else in blender that works this way.
The closest things I can think of are:
and to a lesser extent:
-camera fly mode
All of these are more like 'tools' (block input, wait for users to do their
manipulation, and then confirm the changes with a way out) than most other
things in Blender which just operate instantly. None of these have any
choices to be made beforehand, though the transform stuff has different
modes and constraints that you can toggle from within the function, while
you're doing the manipulating..
> >- in 'freehand mode' the cutting should happen immediately after
> >releasing the mouse.
> I don't agree (What's new?). (Esp. looking at your later point about mixed
> freehand/polyline mode). It's way too hard to draw an accurate line with
> the mouse. The user needs a chance to abort before damaging his mesh.
> It's also nice to allow them to adjust their mouse if they hit the edge of
> mousepad. It's not so much of an issue with Editmesh undo in place.
> But 1) we shouldn't make the user rely on undo, we should strive
> to let them do it right in the first place, and 2) it's not a guarantee
> 2.3 will release with both.
> I think it was _you_ who said the proper flow was
I think it was me, in one of the meetings, and I want to mention it again
here because I think it's important :) It may be a symptom of Blender being
designed without an undo, but one of the great things about the UI is that
(at least in many cases anyway, like transform();) destructive actions give
you a chance to visualise what the change will be, then have the option to
confirm/cancel it. This can take the form of cancelling out of a confirm
dialog with a mouse move, or by pressing RMB in transform mode.
This is right along the lines of all that UI theory of 'always giving the
user a way out' and makes Blender so pleasant to work with - rather than
letting you make mistakes, and go back and reverse them with undo, when
these tools in Blender work well (not all of them are consistent with this
workflow unfortunately) it lets you prevent the mistakes from even
happening. It's fast and it gives a nice feeling of being in control since
you're not always apologising to the computer and asking it to repair what
you've done. Of course that's not to say that undo is useless - far from it,
but I think it's a good idea to aim to continue this workflow.
Having the cut happen on mouse release would work similarly to border
select - the only way to cancel out would be to keep holding down the mouse,
and press -esc- . For selection I suppose it's not such a big deal since
speed is good, and it's easy to cancel it by pressing -a- to deselect. For
the knife tool though, speed isn't quite so important as accuracy, so I'd
personally prefer to keep it the way it is - it's less cumbersome to cancel
and of course there's the polylines issue. It's not a non-standard behaviour
in Blender - brush select and I guess transform(); also require an extra
action at the end to confirm.
On this topic, I also agree with theeth's suggestion on the tuhopuu-devel
list or making RMB cancel rather than confirm, to try and keep some sort of
consistent behaviour. To be really consistent, brush select could be made to
work that way too (enter to confirm, RMB to cancel) though that idea may not
be all that popular.
> The 50%/intersect choice could go first, I see no advantage either way.
> It could also be a mode button like "Beauty". Personally I don't like the
> button. I always forget what mode I'm in and end up subdividing my mesh
I've been using the knife very extensively in tuhopuu (and I love it! :) and
I don't think I've ever used the '50%' option. Unless anyone else has good
reasons for keeping it, I'd say get rid of it - it makes the tool more
streamlined, simple and fast without the extra choices (which must get made
with every cut..grr).
> >- I would love to see a real cutting cursor once... on OSX it changes
> >in a normal cursor, very confusing.
> There was talk of better cursor support with the new GUI. Don't know if
> will happen.
> Also, I only have a linux box to test on. This is why the windows cursor
> changes to a
> cross and not a pen cursor (It was already used, therefore "safe").
I've got new pointers for at least these under control and should be able to
show something preliminary tomorrow/soon:
* Cutting cursor
* Text Cursor
* Boundary Selector
* Hand Cursor