rkflx requested changes to this revision.
rkflx added a comment.
This revision now requires changes to proceed.
> BUG: 79904
@bruns @alexeymin I'm not sure you have reviewed this change properly? This
bug is about "MacOS styled menus and remote X sessions". If you "Accept" a
revision, to keep quality up it is important to check everything (in particular
at least read what the bug is about), otherwise please give a "+1" only.
@ngraham I don't think we should change the string (at least if text input in
the filter is enabled, but I'd value consistency with the other case too…).
The widget is not only about selecting a filetype, but about being able to
filter the filenames based on wildcards, much like what you can do in Dolphin.
There is a "What's this" help to explain the feature further, but changing it
to "File format" hides it even more from discovery, which would be a bad thing
and counter your other efforts in this dialog to make things more discoverable.
Also, reading what's available in the filter already makes it pretty obvious
that the widget can be used to filter for filetypes too. I doubt users have
problems using this only because it says "Filter" on the very left side.
There are some situations where changing the string might be warranted:
- The file dialog does not allow to filter and displays a fixed
(non-editable) combobox of filetypes.
- Another (more obvious) UI to filter the view is added.
I'm willing to accept the patch if the naming is made more intelligent to
account for all situations. Another approach would be to change the API so that
applications can override the default "Filter" string. Until that's done, a
string which fits all cases has to stay, which is "Filter".
INLINE COMMENTS
> kfilewidget.cpp:586-591
> whatsThisText = i18n("<qt>This is the filter to apply to the file list. "
> "File names that do not match the filter will not
> be shown.<p>"
> "You may select from one of the preset filters in
> the "
> "drop down menu, or you may enter a custom filter "
> "directly into the text area.</p><p>"
> "Wildcards such as * and ? are allowed.</p></qt>");
I'm talking about this. E.g. an intermediate-level user could filter for
`*ProjectX*CustomerMeetingApril*`, which is not at all about filetypes.
Of course the very simple folder listing in your screenshot does not have the
need for filtering like that, but you know very well that in the real world
folder listings can get very long, otherwise you would not work on the Places
panel ;)
REPOSITORY
R241 KIO
REVISION DETAIL
https://phabricator.kde.org/D12130
To: ngraham, #frameworks, #vdg, bruns, alexeymin, rkflx
Cc: rkflx, alexeymin, abetts, bruns, michaelh, ngraham
