Hi, ok update:
- If filters are in effect, there is now a "Reset filters" button. It's clearly the least elegant of the solutions proposed by Jan, but the others looked like more work than it seemed worth. - Things are still a bit squeezed. If you know of an _existing_ icon we can use to symbolize this, rather than spelling out "Reset filters", that might be a nice way to save some space (after porting to KF5, we will have the option to overlay items for "filter" and "discard"). - I also implemented Meik's suggestion to use arrow-right and arrow-down for collapsed / expanded states. In lists (and the optionset) this looks good to me. However, now an arrow right would be rather confusing for expanding the advanced filter options. So I switched to the wrench-symbol, there. - Similarly a wrench-icon is shown above <varselector>s to indicate the availability of more options. - Text search is regexp-based, now, but again, users are unlikely to even notice the difference, until they try to use a regexp (or read the tooltip). Please test and let me know of any quirks. Regards Thomas On Fri, 13 Nov 2015 21:25:10 +0100 Thomas Friedrichsmeier <[email protected]> wrote: > Hi, > > On Fri, 13 Nov 2015 11:08:08 +0100 > d_jan <[email protected]> wrote: > > Indeed. The standard interface design pattern for this is to show > > some indicator for the active filters, even if the corresponding > > settings are hidden. An example can be seen here: > > https://www.flickr.com/photos/morville/4274338388/in/album-72157623208685504/ > > on the upper left: Anytime you activate some filter it will be added > > to "current search" where you can easily deactivate them. (try > > yourself on > > http://search.trln.org/search?Nty=1&N=0&sugg=&source=trln&Ntt=statistics&Ntk=Keyword) > > > > If you can dynamically insert, the right place for such indicators > > would be on the bottom of the filter/search section of the Workspace > > UI (not wrapped in the usually hidden filter settings, but always > > visible *if* a filter is set. > > > > If this is not possible, a "reset Filters" Button is much less > > elegant, but does the job too. > > > > See these suggestions mocked up here: > > https://community.kde.org/RKWard#Filters > > Thanks! I'll look into this, soon. > > > One question: The fields with are searched in the standard settings > > – do they exlude name, lable and class? Since in the UI it looks > > these boxes are unchecked by standard. > > However, if I search e.g. for "swiss" I find the dataset with this > > name – but only if I did not touch these filter settings before. > > Seems like a state tracking bug, if I understand it right. Easy fix: > > Have the boxes checked by default and/or have a "all fields" option. > > Hm. Of course these are meant to be checked by default, they are for > me, and looking at the code I can't spot any obvious problem. Is this > reproducible for you? > > > > One thing that I'm not entirely happy with (perhaps you have an > > > idea) is searching/filtering in varselectors: Showing the filter > > > controls permanently, did not look like a good idea, here. They > > > can be activated from the context-menu. Is this discoverable > > > enough? > > > > I think it is o.k., possiby one could add a simple button behind > > "select Variables" which does show the same settings as the context > > menu to make it more discoverable. It could read "display" or show > > simply that "down triangle" you have for activating the advanged > > search panel in the workspace dialog. > > Thanks. Will do this. > > Meik wrote: > > what i really like here is how the search field matches names if > > they simply contain the string, without the need for regular > > expressions. for consistency, this should also be the case in the > > package search field. however, this seems to make it impossible to > > actually use regular expressions at all -- this should probably be > > configurable in the extended options ("match text" vs. "match > > regular expression") > > Regarding this, I don't see a any good place, where to squeeze in an > additional option. But perhaps it could simply use regexp matching > _all_ of the time (working on substrings, unless started by '^')? > Since most (but not all) regexp special characters are illegal in > object names, anyway, the difference should barely be noticeable, > unless and until you actually try writing a regexp search string. > > BTW, that behavior would in fact be consistent with the package search > field, which is already searching on sub-strings, too (it did not, > initially, but I had already changed that some time ago). > > Regards > Thomas
pgpSDhQu5ImLH.pgp
Description: OpenPGP digital signature
_______________________________________________ rkward-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/rkward-devel
