Summarized from discussion on mailing list: https://mail.kde.org/pipermail/rkward-devel/2015-November/004333.html --"Soft" warnings-- 1. The warning symbol shown next to problematic objects could be repeated next to / inside the "Submit"-button. 1b. 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. This dialog should specify where the problem is found (which varslot, which object/s), and what it is (as already available per object). -- "Hard" checks -- 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. Most elegant option might be by showing a (closable but non-modal) pop-up notification. -- Fine tuning -- 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.