Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make selection of tools temporary #187

Open
bltzr opened this issue Jun 2, 2016 · 22 comments
Open

make selection of tools temporary #187

bltzr opened this issue Jun 2, 2016 · 22 comments

Comments

@bltzr
Copy link
Member

bltzr commented Jun 2, 2016

We discussed a while ago (and actually agreed on it, AFAIR) with @blueyeti and others about the question of having non-permanent tools selection
My memory (which might be flawed) was that we proposed the following behavior:

  • selection/move is the default, and permanent tool
  • other tools (create, play....) are only temporarily selected, and are released after the action

To explain my take on it:
I have used i-score1.0 for a while now, and sometimes for quite long periods of time, and I consistently get confused by tools remaining selected.
It is very very often that I would create an event/constraint unintentionally after creating one intentionally - actually, that happens almost all the time, and makes me half-mad :-) (maybe that's because I'm already half mad, and there is not so much i-score-induced gradient to it ;-) )
This also happens after using the play tool (but I use it more seldom, so...).

Maybe this is made worse by the fact that the cursor shape doesn't change when changing tools (which is another feature request that has been expressed, but didn't seem obvious...), but IMHO, changing the shape only wouldn't solve the problem either.
I can make an issue for that, though, if you think it's worth...

Do others have this kind of problem, or is it just me being not able to get into the habit of using i-score the way it actually works... ???
@lossius @reno- @avilleret @jln- @theod @jcelerier ?

-> if we agree on this proposed behavior, we would still need to decide if tools are released (i.e. reverted to the select/move tool)

  • on mouse-up (i.e. once the action has been done)
  • or on key-up (i.e. the user needs to keep the key pressed in order to do the action)
    I can see pros and cons for both:
  • mouse-up is the way Omnigraffle works when the tool has been selected on the UI (i.e. through a mouse-action on the screen) , it's quite nice once used to it, but maybe not the most usual/"natural"/intuitive way (in other words, that's probably not the common way most softwares behave for similar operations...???)
  • key-up seems much more common, hence intuitive for newcomers, but it requires the user to keep his non-prefered hand on the keyboard - which is probably OK... (is it, fellow-users ?)

We could also think about a way to “lock“ tools selection
Again, in Omnigraffle, this is doable by double-clicking on the tool icon (I don't know any way of doing this with the keyboard...)
Maybe that would be a good way to do it ? Does anyone of you know of a similar behavior in other softwares ?
I've also thought of (maybe in complementarity) using the CAPS LOCK key: when on, the tools would be selected permanently... does that sound like a reasonable idea ?

Maybe some also have better suggestions ?
But I feel the current user-interaction on this is more than suboptimal, and should probably fixed before we release the beta version.
What do you all think and feel ?

@avilleret
Copy link
Contributor

I agree with the temporary behavior.
If a tool can be selected with a key, then it is very convenient to my eyes
to release the tool as soon as the action is done (or canceled by
triggering escape or deselecting the tool).
Some software I'm using have a tools remaining behavior and I found it
quite confusing.

My 2 cents

a

do it yourself
http://antoine.villeret.free.fr

2016-06-02 15:41 GMT+02:00 Pascal Baltazar [email protected]:

We discussed a while ago (and actually agreed on it, AFAIR) with @blueyeti
https://github.com/blueyeti and others about the question of having
non-permanent tools selection
My memory (which might be flawed) was that we proposed the following
behavior:

  • selection/move is the default, and permanent tool
  • other tools (create, play....) are only temporarily selected, and
    are released after the action

To explain my take on it:
I have used i-score1.0 for a while, and sometimes for quite long periods
of time, and I consistently get confused by tools remaining.
It is very very often that I would create an event/constraint
unintentionally after creating one intentionally - actually, that happens
almost all the time, and makes me half-mad :-)
This also happens after using the play tool (but I use it more seldom).

Maybe this is made worse by the fact that the cursor shape doesn't change
when changing tools (which is another feature request that has been
expressed, but didn't seem obvious...), but IMHO, changing the shape only
wouldn't solve the problem either.

Do others have this kind of problem, or is it just me being not able to
get into the habit of the way i-score works... ???

@lossius https://github.com/lossius @reno- https://github.com/reno-
@avilleret https://github.com/avilleret @jln- https://github.com/jln-
@theod https://github.com/theod @jcelerier
https://github.com/jcelerier ?

-> if we still agree on this proposed behavior, we would still need to
decide if tools are released (i.e. reverted to the select/move tool)

  • on mouse up (i.e. once the action has been done)
  • or on key up (i.e. the user needs to keep the key pressed in order
    to do the action) I can see pros and cons for both:
  • mouse up is the way Omnigraffle works when the tool has been
    selected on the UI (i.e. through a mouse-action on the screen) , it's quite
    nice once used to it, but maybe not the most usual/"natural"/intuitive way
    (in other words, that's probably not the common way most softwares behave
    for similar operations...???)
  • key up seems much more common, hence intuitive for newcomers, but it
    requires the user to keep his non-prefered hand on the keyboard - which is
    probably OK... (is it, fellow-users ?)

We could also think about a way to “lock“ tools selection
Again, in Omnigraffle, this is doable by double-clicking on the tool icon
(I don't know any way of doing this with the keyboard...)
Maybe that would be a good way to do it ? Does anyone of you know of a
similar behavior in other softwares ?
I've also thought of using the CAPS LOCK key: when on, the tools would be
selected permanently... does that sound like a reasonable idea ?

Maybe some also have better suggestions ?
But I feel the current user-interaction on this is more than suboptimal,
and should probably fixed before we release the beta version.
What do you all think and feel ?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#187, or mute the thread
https://github.com/notifications/unsubscribe/AAe0UhL--ZdyNHOLZBiKvm4HJM2Fwok5ks5qHt2KgaJpZM4IskMq
.

@jcelerier
Copy link
Member

See ac468d8

@jcelerier
Copy link
Member

I also added a first try for the cursor change however :

  • default cursors are ugly and not meaningful but somebody has to make the actual cursors that we want to use
  • they seem a bit buggy on qt's side so it will require a lot of testing.

@bltzr
Copy link
Member Author

bltzr commented Jun 3, 2016

ohoh !!!
nice !
will try that not later than this morning, thanks a lot @jcelerier !!!

@bltzr
Copy link
Member Author

bltzr commented Jun 3, 2016

I've just tested, and that's much better IMHO
though, I have some comments:

  • I think we should have the same behavior for the play tool
  • the shift key has to be held when creating a "sequence", while the C key cannot be held while doing so, so that's a bit strange... so, in order to "rationalize" this, either:
    1/ we give the same behavior to the sequence option to shift (i.e. shift-C has to be pressed to create a "sequence"' - I'm not sure that will be any better...
    2/ we allow the user to keep the C key pressed while created (and do the same behavior as currently after the key has been released, i.e. revert to select after the next action has been done, i.e. on mouse-up)
    what about locking the tools ? any opinions ? (that not of the highest priority, though...)

@bltzr
Copy link
Member Author

bltzr commented Jun 3, 2016

Also, I don't see any cursor change, except when dragging, where It changes to a double-arrow, but that happens in all modes...
I don't know about Qt cursors, but what I would find intuitive:

  • same as current when in select/move
  • plus cursor when in creation mode
  • play/triangle cursor when in play mode
    I see these are not in the default distribution... is there any "cursor-shapes repository" that I could look into ? Or I can try to make quick'n'dirty versions of them (svg's ?)

@jcelerier
Copy link
Member

I think we should have the same behavior for the play tool

done.

The shift key has to be held when creating a "sequence", while the C key cannot be held
while doing so, so that's a bit strange...

For me it makes sense, shift (as well as ctrl & friends) is generally an "alteration" key. For instance in all graphical tools I know, if you are in the "resize" tool, the resize is unconstrained when shift is not pressed, and constrained if shift is being pressed.

@bltzr
Copy link
Member Author

bltzr commented Jun 3, 2016

For me it makes sense, shift (as well as ctrl & friends) is generally an "alteration" key. For instance in all graphical tools I know, if you are in the "resize" tool, the resize is unconstrained when shift is not pressed, and constrained if shift is being pressed.

I agree, but here the problem is that the modifier key is not pressed at the same time than the tool's key - so that feels a bit contradictory... have you tried creating a couple sequences ?
What about allowing to let the C button pressed ? That would solve the problem, IMHO...

@jcelerier
Copy link
Member

Well, you don't press the "resize" tool key as well when you shift + resize in photoshop...

@bltzr
Copy link
Member Author

bltzr commented Jun 3, 2016

true.... but it is permanent

@bltzr
Copy link
Member Author

bltzr commented Jun 3, 2016

Is allowing to let the C button pressed a problem ? (design-wise, or technically)

@jcelerier
Copy link
Member

absolutely not :p

@jcelerier
Copy link
Member

wrt Sequences : @blueyeti proposes using horizontal magnetism to make a sequence

@bltzr
Copy link
Member Author

bltzr commented Jun 3, 2016

why not... but then we have to make it VERY clear that it does so...

@bltzr
Copy link
Member Author

bltzr commented Jun 3, 2016

maybe by using different colors for sequences and “normal" constraints ?
e.g. blue constraints when normal, white when in a sequence (somehow similarly that it does with events/timenodes..
that would also make sequences more distinguishable than they are now

then, when creating a constraint horizontally, under a certain ∆y, the constraint appears white, which means it's a sequence (i.e. keeps the namespace, and interpolates by default), over this ∆y the constraint becomes blue
I mean the change of color doesn't happen once done, but while the constraint is being "drawn"

what do you think @blueyeti ?

@bltzr
Copy link
Member Author

bltzr commented Jun 3, 2016

it would be nice to actually try it, if that's not overly hard to implement, but my first reaction is rather positive to this proposal

@jcelerier
Copy link
Member

maybe by using different colors for sequences and “normal" constraints ?

actually @blueyeti proposed the exact same thing ^__^

@bltzr
Copy link
Member Author

bltzr commented Jun 3, 2016

les grands esprits se rencontrent !

@jcelerier
Copy link
Member

jcelerier commented Jun 3, 2016

we allow the user to keep the C key pressed while created (and do the same behavior as currently after the key has been released, i.e. revert to select after the next action has been done, i.e. on mouse-up)

@bltzr this is actually a weird behaviour.
e.g. when using it, if I keep C pressed and construct three constraints for instance, I find it really weird for the tool not to revert to "select" when releasing.

@bltzr
Copy link
Member Author

bltzr commented Jun 4, 2016

you're probably very right !
what if we followed this rule:

  • if mouse-down happens after key-up, then mouse-up reverts to default tool
  • if mouse-down happens before key-up (i.e. while C is still being pressed), then key-up reverts to the default tool (select)
    would that make sense ?
    would it be a mess to implement ? (so we can evaluate the question by actually testing it)

also, I'm not 100% certain that, "cognitively", these two behaviors are compatible.... not sure they aren't either... opinions ?

also, maybe it would be useful to give a way to the user to lock tools
maybe a lock icon on the left of the tool palette (with a semi-separator, or something between it and the other tools) that we could click on (and potentially enable with caps-lock). What do you think ?

@jcelerier jcelerier modified the milestone: release/1.1 Jun 10, 2016
@bltzr
Copy link
Member Author

bltzr commented Jun 10, 2016

I see you postponed that to 1.1 - I guess there's something convoluted making it complicated to do as I proposed ?

Also about the sequence behavior, I think that is quite cool indeed (and also very clear, since the automations show up directly - and disappear when moving vertically....) - so thanks Blue Yetis !
Maybe changing the color would make that even nicer ? Is that complicated ? Or did you just forget ? (Or postpone... ?)

@bltzr
Copy link
Member Author

bltzr commented Jun 10, 2016

also, now that we can create sequences by vertical magnetism, I guess we could remove the tool/shift modifier
maybe adding the possibility to disable in the settings would also be a good idea ? Or maybe even in the toolbar... because maybe sometimes one doesn't this to happen, and maybe one wants (this has been my case, but maybe I would have done otherwise if that was already existing)

maybe I should create one or several issue(s) for all matters relating to sequences, shouldn't I ?
so this issue can stay on the tool-selection permanence ?

@jcelerier jcelerier modified the milestones: To discuss, release/1.1 Jun 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: TODO
Development

No branches or pull requests

3 participants