Hi, On Fri, 13 Nov 2015 11:08:08 +0100 d_jan <d_...@ymail.com> 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
pgpRCLcVi6lW3.pgp
Description: OpenPGP digital signature
_______________________________________________ rkward-devel mailing list rkward-devel@kde.org https://mail.kde.org/mailman/listinfo/rkward-devel