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

[Thomas Friedrichsmeier]

Hi,

On Sun, 22 Nov 2015 17:27:14 +0100
meik michalke <meik.michalke at uni-duesseldorf.de> wrote:
> Am Samstag, 21. November 2015, 15:17:41 schrieb Thomas
> Friedrichsmeier:
> > 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".
> 
> i do remember we discussed this, but i don't recall my position :-D
> trying to think of a reason for wanting hard checks, i guess my view
> could have been: if a plugin author explicitly defines classes for
> input, he probably means it. i don't know...
> 
> do *we* have to decide whether hard or soft checks should be done?

true, we can pass on the problem to plugin authors. But of course that
will mean users will have to put up with two confusing behaviors,
instead of just one ;-).

I'll continue the brainstorming building on your ideas:

1. Yes, I think it makes sense to do soft checks, by default. For most
plugins this will come closest to the previous state of not doing
type-checks at all.
1b. The warning symbol will be replaced, of source.
1c. The warning symbol could be repeated next to / inside the
"Submit"-button.
1d. On pressing the "Submit"-button, there could be a warning dialog:
"Do you really want to do this?", with a "Don't ask again" option.
Somewhat similar to your idea 3.

1c and 1d are things that might have to wait for the KF5 version,
though, for pragmatic reasons: I'm not sure, whether the required
changes are easily mergable. (Yes, the KF5 port has progressed far
enough that this is starting to be a concern).

2. If allowing for hard checks, and in particular if we allow for hard
checks _in addition to_ soft checks, these should work by refusing the
object in question right away. I am still not sure, how to solve this,
UI wise, but perhaps it's ok'ish to simply pop up a dialog "No, you
can't do this, because...", when the user clicks the "Add"-button with
an invalid object selected. That will be somewhat annoying, but OTOH it
is not something users would try to do all the time.

3. Optional hard checking might need a little more control than a
single boolean. For instance, a plugin author might want to enforce a
hard "num_dimensions"-check, but only a soft "types"-check. So perhaps
the semantics would be hard_checks="num_dimensions classes types", with
either "num_dimensions" or "" as the default.

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/20151123/bfdbc267/attachment.sig>