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
pgpRCLcVi6lW3.pgp
Description: OpenPGP digital signature
_______________________________________________ rkward-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/rkward-devel
