https://bugs.kde.org/show_bug.cgi?id=524623
Bug ID: 524623
Summary: Usability request: Direct the user towards filter
masks when trying to apply a filter to non pain layers
from the 'Filter' menu
Classification: Applications
Product: krita
Version First 6.0.3
Reported In:
Platform: unspecified
OS: All
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: Usability
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
DESCRIPTION
Currently, if a user tries to apply a filter to a layer group (or any non paint
layer) by using the "Filter" section in the menu bar (by selecting the layer
and opening the menu), it just greys out all options without any feedback, so
a) If a new user doesn't already know about the filter masks/layers and how to
apply them from elsewhere (as they're generally hidden behind sub-menus) and
that they do apply to non paint layers, it might make them think that Krita is
unable to apply filters to such layer types
b) It creates a workflow inconsistency where to apply filters (even non
destructive ones as the filter dialogues do show the button to apply as a
filter mask) to normal paint layers, you are able to use the "Filter" menu; But
if you want to do that to layer groups or other layer types, you are unable to,
and have to use alternative ways
STEPS TO REPRODUCE
1. Select layer group or vector layer
2. Open the "Filter" menu from the menu bar
3. Try to apply any filter
OBSERVED RESULT
All filter entries are greyed out and non-selectable without any indication of
why nor pointing to alternatives
EXPECTED RESULT
Keeping those entries enabled when a non paint layer is selected, and (one of
these)
a) The program giving information trough a dialogue directing the user towards
filter masks, and preferably offering to apply the chosen filter as a mask to
the selected group or vector layer
b) Bringing up the selected filter pop-up as normal, with only the "Create
Filter Mask" button visible
ADDITIONAL INFORMATION
It is important for - especially complex - software to be self-explanatory in
how it works as is is being used and as users encounter edge cases, preferably
explaining the why and how, but especially guiding or offering to do what the
user might be intending to do, instead of giving an unexplained "no you can't
do it" and expecting them to just know why it is there and that that there is
another way. As a non experienced user might not know the difference between "a
feature that exists but is not reachable from the common/expected path" and "a
feature that doesn't exist"
--
You are receiving this mail because:
You are watching all bug changes.
