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

[d_jan]

After a brief try:

> "Reset filters" button.

Does the Job. Good.

> If you know of an _existing_ icon
> we can use to symbolize this, rather than spelling out "Reset
> filters"

I can’t think of any universally known icon, communicating "reset". One
could combine a delete icon with a filter icon, but this would be not
understood without learning it – so: better squeezed than hard to use!

> I also implemented Meik's suggestion to use arrow-right and
> arrow-down for collapsed / expanded states.

Indeed, works nicely.

Minor adjustment:
The Advanced-Filter-Options’ "Show all Objects" Selector is not aligned
with the one above ("Top level Objects…") and seems to be visually
grouped with "show hidden objects" with does not make much sense, since
show hidden objects is outside, the "Show all…" is inside the
Advanced-Filter-Options. So:
- Group all Advanced Filter Options (there seems to be a box-thingy that
groups them) OR
- Put just "Show all Objects" in a group too, so it aligns with the
selector ("Top level…") above.


Am 16.11.2015 um 13:31 schrieb 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
> 
> 
> 
> _______________________________________________
> rkward-devel mailing list
> rkward-devel at kde.org
> https://mail.kde.org/mailman/listinfo/rkward-devel
>