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

Can't re-bind ellipse tool, etc. to work like default #1460

Closed
KashouC opened this Issue Apr 19, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@KashouC

KashouC commented Apr 19, 2017

By default the ellipse and filled ellipse tool is bound to Shift+U, and pressing it cycles between the two, but if you rebind them, this isn't possible to achieve, as it will just remove the conflicting bind instead.

Aseprite v1.2-beta9
Windows 7 x64

@KashouC

This comment has been minimized.

Show comment
Hide comment
@KashouC

KashouC Apr 19, 2017

I fixed it by editing the default key binds in the GUI file, but while this should maybe be it's own seperate feature request, it would be nice if setting ellipse and ellipse fill to "R" for example would ALWAYS select ellipse first, so you know that you always get fill by pressing R twice, instead of having to check every time.

KashouC commented Apr 19, 2017

I fixed it by editing the default key binds in the GUI file, but while this should maybe be it's own seperate feature request, it would be nice if setting ellipse and ellipse fill to "R" for example would ALWAYS select ellipse first, so you know that you always get fill by pressing R twice, instead of having to check every time.

@dacap

This comment has been minimized.

Show comment
Hide comment
@dacap

dacap Apr 19, 2017

Member

Hi @KashouC, two things about this:

  1. As you found, there is a bug were we cannot set the same keyboard shortcut to select a couple of tools (e.g. to restore the default behavior)
  2. Yeah, I don't like the current way to select the tools when two or more tools share the same keyboard shortcut

To solve the second point we might:

  1. Use the solution you proposed, but there are one problem: How do we know what is the first tool to be selected? For example, if ellipse and ellipse fill are associated to R key, should the first R select the ellipse or the ellipse fill? (this is already an actual problem, as by default the non-filled ellipse is selected first, and then the filled ellipse, by the order that these tools are listed in the gui.xml, so that might be the possible solution)
  2. Other possibility is to have a keyboard shortcut to switch tools in the group (i.e. as Photoshop does), so for example (by default) the U key selects a tool in the rect/ellipse group, and Shift+U switch the icon in that group (between rect -> filled rect -> ellipse -> filled ellipse)

I'm not sure yet how to solve this in a proper way, maybe both possibilities.

Member

dacap commented Apr 19, 2017

Hi @KashouC, two things about this:

  1. As you found, there is a bug were we cannot set the same keyboard shortcut to select a couple of tools (e.g. to restore the default behavior)
  2. Yeah, I don't like the current way to select the tools when two or more tools share the same keyboard shortcut

To solve the second point we might:

  1. Use the solution you proposed, but there are one problem: How do we know what is the first tool to be selected? For example, if ellipse and ellipse fill are associated to R key, should the first R select the ellipse or the ellipse fill? (this is already an actual problem, as by default the non-filled ellipse is selected first, and then the filled ellipse, by the order that these tools are listed in the gui.xml, so that might be the possible solution)
  2. Other possibility is to have a keyboard shortcut to switch tools in the group (i.e. as Photoshop does), so for example (by default) the U key selects a tool in the rect/ellipse group, and Shift+U switch the icon in that group (between rect -> filled rect -> ellipse -> filled ellipse)

I'm not sure yet how to solve this in a proper way, maybe both possibilities.

@KashouC

This comment has been minimized.

Show comment
Hide comment
@KashouC

KashouC Apr 19, 2017

Yeah there are a lot of different ways to do this, but you probably want it to be as intuitive as possible and not have to add a bunch of extra buttons and stuff so I'm not sure.

Personally I think it would be fine if it just depended on which tool comes first in the keybindings basically. Other options include adding a tab for multi-binds where you can select priority, being able to "re-order" the tools by dragging in the tool bar, adding some sort of order drop down menu behind the keybinding of binds that are bound to a key used by other tools. Problem is that all of these options are either arbitrary things you'd just have to know about, or overly invasive solutions.

Also for setting the same key binding on multiple tools or functions, it would be nice if the program prompted you when you tried to use an occupied key by asking to replace the other bind, keep it, or cancel.

KashouC commented Apr 19, 2017

Yeah there are a lot of different ways to do this, but you probably want it to be as intuitive as possible and not have to add a bunch of extra buttons and stuff so I'm not sure.

Personally I think it would be fine if it just depended on which tool comes first in the keybindings basically. Other options include adding a tab for multi-binds where you can select priority, being able to "re-order" the tools by dragging in the tool bar, adding some sort of order drop down menu behind the keybinding of binds that are bound to a key used by other tools. Problem is that all of these options are either arbitrary things you'd just have to know about, or overly invasive solutions.

Also for setting the same key binding on multiple tools or functions, it would be nice if the program prompted you when you tried to use an occupied key by asking to replace the other bind, keep it, or cancel.

@dacap dacap changed the title from Bug: Can't re-bind ellipse tool, etc. to work like default. to Can't re-bind ellipse tool, etc. to work like default Aug 11, 2017

@dacap dacap added the high priority label Aug 11, 2017

@dacap dacap self-assigned this Dec 6, 2017

@dacap dacap added this to the v1.2 milestone Dec 6, 2017

@dacap dacap closed this in b0b3818 Dec 6, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment