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

[Thomas Friedrichsmeier]

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 <thomas.friedrichsmeier at ruhr-uni-bochum.de>
wrote:

> 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/20151116/5408e5b0/attachment.sig>