[rkward-devel] Workspace Window, now with mockup.

[Thomas Friedrichsmeier]

Hi,

On Fri, 13 Nov 2015 11:08:08 +0100
d_jan <d_jan at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20151113/15f4c3d9/attachment.sig>