[rkward-devel] Bug: Submit not active in several plugins (?)

[Thomas Friedrichsmeier]

Hi,

On Fri, 20 Nov 2015 23:02:12 +0100
d_jan <d_jan at ymail.com> wrote:
> In several Plugins I can’t execute tests etc. since the submit button
> is not activated.
> 
> Steps to reproduce the bug:
> 1) Load Orange Dataset (e.g. I did orange <- Orange)
> 2) In the Chi Squared Test for outlier, select the orange age variable
> (also possible: Shapiro-Wilk or most other normality tests)

phew, took me quite a while to diagnose this bug, as I was looking in
all the wrong places. Actually it was a very long standing bug that was
uncovered by Meik fixing a bunch of mis-spellings all over our plugins.
That in turn caused the <varslots> to actually check the type of their
object, but comparing it again the string "Number", instead of
"numeric".

Well, I fixed the worst for now, but still, there are some follow-up
questions, roughly around the issues you did point out:
 
> What happens: I can't submit and execute the test.
> Also, in front of the picked variables are little delete icons
> (trashcans on KDE). If I click them, nothing happens.

The icon was meant as an indication that something is problematic about
the object, it is not meant to be a button. I suppose some sort of
"Attention/Warning" symbol might explain this better? The actual
problem is shown in a tool tip on mouse over.

> What should happen: Executing the test should be possible. If there
> is a condition preventing this for good reasons, there should be some
> warning/note that is not easily overseen.

Good point. In this particular case: Fixed. But actually, I do feel a
bit uncomfortable, here, as there might be cases where were restricting
what can be done, unnecessarily. For instance, in many cases, where our
<varslot>s specify "numeric", logicals would be acceptable, too, at
least as corner-cases. They'd still not be the "typical" type of data
to feed into the plugin, but there may well be use-cases for doing so,
once in a while.

Other things that (few) plugins check is class of objects. Here, wrong
classes will typically really be an error, but it's not hard to imagine
cases, where a check for classes might be overly restrictive (think
inheritance, think methods get improved to accept additional related
kinds of objects, but we forget to update the plugin...).

Yet another possible filter is "number of dimensions" (i.e.,
importantly, vectors vs. 2d matrices). I think false positives in this
filter are relatively unlikely, although again, not entirely
inconceivable.

I discussed this a bit with Meik, back then, and we did not quite
agree. Meik argued for "hard" checks (if any), which is what is in
place, now. I was thinking more along the lines of "ok, let's show the
user that this is likely to be wrong, but do allow to proceed". (It
would not be too hard to make this configurable per <varslot>, but I
guess it would still be best to have a consistent policy on this).

Thoughts?

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/20151121/cefc6427/attachment.sig>