[rkward-devel] typo: type or types?

[meik michalke]

hi,

am Dienstag 27 September 2011 (13:50) schrieb Thomas Friedrichsmeier:
> On Monday 26 September 2011, meik michalke wrote:
> > in the t-test plugin, the varslot has the attribute
> > 
> >   type="numeric"
> > 
> > although the attribute reference suggests it should be
> > 
> >   types="number"
> 
> I had to look it up, myself. Actually the reference is correct

ok, i reverted my changes.

> while the usage in the vast majority of plugins is incorrect. Effectively,
> no type filter is applied in all those varslots.

funny this wasn't discovered until now. the reason for this is probably that 
the t-test with the wrong option is the main example in the plugin docs. i 
corrected the code there, so that the docs are at least valid now.

> That said, I'm not too sure, whether it would be a good idea to go about
> and fix the plugins, right away. I fear the concept may be too strict in
> some cases, and probably isn't too self-evident (the varslot will simply
> refuse to accept objects not matching the filter).

they should either be corrected or the attribute removed completely.

> Perhaps it would be a better idea to allow the user to select any object
> they like, but instead to give some sort of visual indication, that this
> could be a problem (like a small warning sign next to the variable name,
> with an appropriate tool tip). What does everybody else think about this?

i think this cannot be decided on a global level. there clearly are cases 
where one type of data is the only one that makes sense, so i'd consider it a 
win for ergonomics that you cannot even select something which will only 
produce errors (which, for a normal user, might be harder to understand than 
the simple fact of not being able to put an object into a varslot).

on the other hand, it's a really good idea to have RKWard explaining the 
*reason* why the object can't be selected, if you try and fail; what about a 
tooltip for varslots like "Valid types: ..."/"Valid classes: ...", and in the 
event of picking a wrong type, the varslot turns red (like "required", and 
should be handled like this)? this would be similar to saveobject, if you try 
to overwrite an existing object.

if you want to give more control to users without discarding the feature 
alltogether, you could add something like a "do it!" attribute to varslots, 
like the "overwrite" button for saveobject. but as a plugin developer, i'd 
like this to be optional.

> Note: Essentially the same consideration applies to the classes=""
> attribute, which is used much less frequently, however.

i'm using it and find it very helpful :-) it actually lead me to define my own 
classes, so i can know what to expect in the data given. the validity features 
for classes are just great.

but you're right, it could be more obvious that some fields are pickier than 
others, and why.


viele grüße :: m.eik

-- 
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at d-40204 d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20110927/a3eaeabc/attachment.sig>