ossia / score

ossia score, an interactive sequencer for the intermedia arts
https://ossia.io
Other
1.5k stars 104 forks source link

make selection of tools temporary #187

Open bltzr opened 8 years ago

bltzr commented 8 years ago

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:

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)

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 commented 8 years ago

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 notifications@github.com:

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 https://github.com/OSSIA/i-score/issues/187, or mute the thread https://github.com/notifications/unsubscribe/AAe0UhL--ZdyNHOLZBiKvm4HJM2Fwok5ks5qHt2KgaJpZM4IskMq .

jcelerier commented 8 years ago

See ac468d84773ec464bb7da56636956f1dbcfbd8a5

jcelerier commented 8 years ago

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

bltzr commented 8 years ago

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

bltzr commented 8 years ago

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

bltzr commented 8 years ago

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:

jcelerier commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

bltzr commented 8 years ago

true.... but it is permanent

bltzr commented 8 years ago

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

jcelerier commented 8 years ago

absolutely not :p

jcelerier commented 8 years ago

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

bltzr commented 8 years ago

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

bltzr commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

actually @blueyeti proposed the exact same thing ^__^

bltzr commented 8 years ago

les grands esprits se rencontrent !

jcelerier commented 8 years ago

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 commented 8 years ago

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

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 ?

bltzr commented 8 years ago

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 commented 8 years ago

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 ?