Bug 342270 - "Backspace" silently assigned to "Remove Point" after set custom shortcut to "Fill with Background Color"
Summary: "Backspace" silently assigned to "Remove Point" after set custom shortcut to ...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-28 07:52 UTC by mvowada
Modified: 2015-01-03 13:57 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mvowada 2014-12-28 07:52:36 UTC
The "Backspace" key is silently assigned to a previously not listed entry named "Remove point", after setting a custom key to "Fill with Background Color".

Here the issues could be two, in my opinion:
- The "Remove point" entry doesn't show up by default in the shortcuts list
- The "Backspace" key is silently assigned to "Remove point", after setting a custom key to "Fill with Background Color"

(Krita version: 2+git20141226+r73494-51-dk~ubuntu14.04.1)

Reproducible: Always

Steps to Reproduce:
1. with default configurations start Krita and create/open a document
2. Menu > Settings > Configure Shortcuts... > Search: Remove point > no entries found
3. Menu > Settings > Configure Shortcuts... > Search: Fill with Background Color > default key is "Backspace"
4. Menu > Settings > Configure Shortcuts... > Search: Fill with Background Color > set and use a custom key
5. Menu > Settings > Configure Shortcuts... > Search: Remove point > default key is "Backspace"

Actual Results:  
The "Backspace" key is silently assigned to "Remove point", after setting a custom key to "Fill with Background Color".

Expected Results:  
The "Backspace" key shouldn't be silently assigned to "Remove point", after setting a custom key to "Fill with Background Color".

I'm not sure if it's the desired behavior. 
This happens with at least one document open, assigning the shortcut when no documents are open, the "Remove point" entry won't interfere and it won't show up in the shortcuts list.
Comment 1 bunu 2014-12-28 10:57:22 UTC
[I am a GCI student]

For me Remove point is already assigned Backspace from the beginning which is no problem as long as the two functions can't be used at the same time. It is not a key or a combination of keys that is assigned to a function, but the other way around.
Comment 2 mvowada 2014-12-28 12:28:18 UTC
Hi, you're right, they're separate functions.
Do you think could be superfluous alerting the users when switching back to default shortcut?

Summarizing:
- "Remove point" isn't listed in the shortcuts list at launch of Krita
- "Remove point" will appear as soon as a document is opened in Krita
- Therefore a custom shortcut for "Fill" has nothing to do with the appearing of the "Remove point" entry in the shortcuts list
- By default "Remove point" will share the same key "Backspace" of "Fill"
- The switching back from a custom key to the default one (Backspace) in "Fill", opens an alert dialog with the message: 'The "Backspace" shortcut is ambiguous with the following shortcut. Do you want to assign an empty shortcut to this action? Shortcut 'Backspace' for action 'Remove point''
Comment 3 bunu 2014-12-28 12:42:21 UTC
[I am a GCI student]

I think it is strange to use Backspace twice by default. But this was chosen as default so I suggest:
-change default shortcut
-if a shortcut ambiguity occurs on defaults it should not display a warning
Comment 4 mvowada 2014-12-28 13:25:14 UTC
Thank you for your reply. 

In my opinion double shortcuts reveal to be versatile using different tools, like i.e. when editing of vectors or when filling the canvas with a color (being in this case the shared key "Backspace").

I can see why multiple functions could share the same key shortcut, and I think this is a strong point. 

That said, I find a bit: 
- redundant the alert message when switching back to the default key 
- not clear to me why not all the shortcuts are appearing in the shortcuts list at Krita launch, without opened documents.
Comment 5 bunu 2014-12-28 17:19:48 UTC
[I am a GCI student]

Point 1: true
Point 2: I agree. People don't want to open a document to edit their shortcuts. However I understand that usually it is good only to show the functions that can be used at a certain mode.
Comment 6 Halla Rempt 2014-12-28 17:45:20 UTC
"People don't want to open a document to edit their shortcuts. "

That's something I'm working on fixing... For a bunch of reasons, mostly to do with inertia and a long, long history, this is pretty tough. But we'll get there :-)
Comment 7 Halla Rempt 2015-01-03 13:57:26 UTC
Git commit c02946c86c44a86a912b5c2100db8eaec5d92209 by Boudewijn Rempt.
Committed on 03/01/2015 at 11:06.
Pushed by rempt into branch 'calligra/2.9'.

Create a master action collection for the shortcut editor

This is still a half-way solution, ideally we'd just create actions from
the .action file and fetch those actions in the code where we need an
action, so there's still duplication. If we make the master action
collection the source for new actions, we will also have to make the
krita.action file translatable.

If you create an action which should have an editable shortcut, you need
to add that to a .action file. Make sure that all the text is exactly the
same, so it gets translated in the shortcut dialog.

On closing the shortcut dialog, changed shortcuts are saved. All
mainwindows's actioncollection will re-read the configuration so they
are synchronized. There's no local krita.rc file anymore, so the windows
won't be able to save the shortcuts to the local krita.rc, all shorcuts
are saved in the kritarc config file.
Related: bug 313218, bug 342184, bug 337368

A  +336  -0    krita/krita.actions
M  +1    -14   krita/ui/KisMainWindow.cpp
M  +92   -3    krita/ui/KisPart.cpp
M  +19   -0    krita/ui/KisPart.h
M  +0    -23   krita/ui/KisView.cpp
M  +0    -22   krita/ui/KisViewManager.cpp

http://commits.kde.org/calligra/c02946c86c44a86a912b5c2100db8eaec5d92209