Combinig translate/rotate/scale tools?

Development Feature discussions
21

There must be something that has to be coded. Probably something has been missed. In which other part of Synfig Studio under mac is used the ALT key and it is working? maybe we can steal the code from there. Did/Does it work with other tool?

And just for help to the mac community, maybe possible that you retry to follow the current build instructions and correct whatever you see wrong in them? I know that it is tedious and not easy because dooglus helped you once to solve some build issues but you know that we haven’t a mac to test those build instructions, so only lucky people like you can keep the hope :slight_smile:

-G

22

:smiley: Hi my friend! Well I have to investigate the alt function on osx for other functions, I’m not animating much at all for the moment but I’ll dive in to it from time to time. I am indeed interested and willing to help with the mac build, I just wish I understand more of what I am doing, I will dive in to that too when time permitts.
I hope you’re okey Genete and I’m very glad to see you from time to time on different forums! :smiley:

23

I’m very busy as well and trying to keep the Synfig hope alive! I’m glad to have news from you too. I don’t have so many news or post from you either. I’m sure that you’re fine :slight_smile:
-G

24

The last changes that has been introduced by nikitakit in the unification of the Translate, Rotate and Scale tools into the Normal tool still having some things to fix. The current master version allows to reach the null state tool when you change the layer selection. This null tool shouldn’t be reached never because it cannot have options. It was the old Normal tool.
I asked him to fix the code to return to normal tool when the layer selection changes instead of return to the null tool.
The changes that he has made are in the nikitakit_ducks branch and they works as expected.
But before apply to master I’ve noticed that it is possible to continue going to null state by pressing the STOP button or the ESCAPE key.
Fix those last bugs is very easy, but I would like to do it right. :slight_smile:
This is the chart for the current tool event handling:

[code] Layer Selection STOP button STOP button press
change effect status or ESC press

Smooth : none disabled -
Mirror : none disabled -
Width : none enabled null tool
BLine : normal tool enabled reset
Circle : normal tool enabled null tool
Rectangle: normal tool enabled null tool
Star : normal tool enabled null tool
Gradient: normal tool enabled null tool
Polygon : normal tool enabled reset (doesn’t refresh)
Text : normal tool enabled null tool
Draw : none enabled null tool
Fill : normal tool enabled null tool
EyeDrop : normal tool enabled null tool
Zoom : none enabled null tool
Sketch : none enabled null tool[/code]
As you can see there are some tools that still allowing to reach the null tool after pressing the STOP button.
I have the followings doubts:

  1. When you change the layer selection some layers return to Normal tool and some other don’t. Why? Which one should do that and which one don’t and for which reason?
  2. The STOP button is obviously a reason to leave the current tool and reach the normal tool. Should be disabled in some tools? why?
  3. It seems that the BLine tool was born with the STOP button enabled but used to reset the bline creation. For that usage it is already a button in the Tool Option panel (the clean icon). It is worth to keep it or can the STOP button allow to return to Normal tool? Same comments to Polygon.

I would like to listen users opinion on that.
-G

25

Also, I think that Rotate tool and Scale tool should return to the toolbox.
I think that a new user should have the option to have a tool that works as the old style although once the user masters his abilities the usage of the Normal tool will be increased.

What do you users think on this?

-G

26

I second that!

G.

27
  1. That is a special feature, previously known as “egress_on_selection_change”. (I have replaced the egress part with entering the normal state). It is enabled on all of the object-creation tools, probably with the idea that when you change the selection, you will want to edit those layers rather than (for example) creating another BLine.
  2. I guess the rest of the tools deserve to react to the stop button as well.
  3. I believe that in all drawing tools except polygon and BLine, the layer is created as soon as the user lets go of the mouse. Thus, there’s isn’t much for a stop button to do. On the other hand, being able to cancel BLine construction with the escape key is handy. Maybe have it clear the canvas on the first stop event, and return to normal if it’s already empty?

Just to be clear, the so-called “null state” in my latest commit is really the normal state. All keyboard shortcuts should work as expected. The actual problem is that the toolbox refresh event is never called. I could either use the same minor hack as with the selection change (a quick solution, though I think it causes the normal state to reinitialize over the same chunk of memory) or add a refresh function to the normal state that will be called from the state manager (this will require modifying ETL, but all states except normal would return to the way they were before I decided to mess with everything).

28

So I propose to modify this code for all the tools except BLine and Poly:

Smach::event_result StateCircle_Context::event_stop_handler(const Smach::event& /*x*/) { throw Smach::egress_exception(); }

with

Smach::event_result StateCircle_Context::event_stop_handler(const Smach::event& /*x*/) { throw &state_normal; }

Does it make sense?

-G

29

I third that… besides helping beginners, another reason, when you’ve got a heavy scene and the computer is becoming slow, it might good to be able to select rotate and scale tools first, incase the computer is too slow to respond to the key presses.

30

I’ve got a computer again, and I just tried the new combined transrotascale… very nice, thanks :slight_smile:)

One quirk to report, sometimes the ctrl and art keys are “sticky” and it stays on rotate / scale, and other times it doesn’t (personally I prefer when it doesn’t)

31

You have an “art” key? Man, I gotta get one of those! :smiley:

Matt

32

Yes, I’ve noticed it too. The default and desired behavior is that the key are not sticky. If you click on the Tool options panel and check one of the keys it will remain sticky until it is pressed again or unchecked with the mouse.
Thanks for test the development version!
-G

33

One of the things about the way the keys are implemented is that they are only recognized if the canvas window is in focus. Especially on GNU/Linux systems where the window focus is set to follow the mouse, this can lead to keys being “sticky”.

I believe it may be possible to implement this another way (testing for modifier key masks rather than for keydown/keyup events), but that would work best if the checkboxes for rotate/etc were removed.

34

Nikitakit, that makes sense - I experimented with it, and the stickiness happens if the modifier key is released after the mouse goes out of the canvas window… that’s good, I can work with it:)

Matt, to install an art key on ubuntu, go to your keyboard preferences and add dvorak… the l and the r will then be right next to each other - you’ll start making typos that leave other people wondering how you made them. Helps if you live in a tropical climate :Þ

35

I think “sticky keys” problem is significant. If I have Alt or Ctrl key sticked and trying to move single duck - nothing happens (because we are in scale or rotate mode). It took me some time to figure what’s the problem was. ^___^

Is there a way to re-check for pressed keys when canvas window gets focus? Is it possible to fix that before release?

36

If you want to use the key position (rather than catching events), the little checkboxes will have to go. The toolbox will just have some hints about the shortcuts. There might also be the problem of AltGR not working as an alt key. On the flip side, the code will be less of a hack and more predictable.

Sorry, but my skills just aren’t good enough to do everything as well as I would like to. Should I make these changes, or no?

37

Nikitakit, I don’t think anyone is complaining on your work. Your programming skills are far better than mine and you have done a great work with the implementation of the rotation and scale abilities in the normal tool.
Regarding to the sticky problem I have some suggestions/thoughts:

  1. I would like to keep the rotate and scale tools checkboxes. I think that some users would like it. Is it possible?
  2. If it is possible to change the behavior of the Normal tool to use key modifiers instead of key events then do it, even if it implies remove the checkboxes. Replace the checkboxes with some tool help text will be enough. Also it would be nice to have the hint of “use the SHIFT over a tangent duck unlink tangents”.
  3. I think that it is not a bad idea to modify the cursor icon when the key are pressed, like it happens in the mirror tool. That would be an indicator to the user on which modifier is being applied. I can work on that.

-G

38

Yes, I’m not complain. ^___^ Just pointing out to issues.

I think it’s ok to remove checkboxes if that help to get rid of issue. Changing icon is very good idea for usability.

Thanks!

39

My suggestion was: can we use gtk’s signal_enter_notify_event (library.gnome.org/devel/gtkmm/st … e8ca149510) to catch when mouse returns to canvas window and check what keys are pressed at this moment?