[rkward-devel] typo: type or types?

[Thomas Friedrichsmeier]

Hi,

On Tuesday 27 September 2011, meik michalke wrote:
> funny this wasn't discovered until now.

indeed.

> they should either be corrected or the attribute removed completely.

naturally, this should be corrected. But I simply suggest to delay the fix for 
another while (at least until after 0.5.7). Then, we will have some time to 
experiment with a few concepts.

Meanwhile, the wrong attributes are still a sort of documentation about which 
varslots were intended to be numeric, and thus, I suggest to keep them until 
we are happy with whatever we came up with.
 
> 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).

True. However, what I'm worried about is cases, where developers _think_ a 
certain restriction makes sense, but in reality it is too strict, and prevents 
the user from doing something absolutely "legal". Some examples:

- In cases, where type string or factor are expected (e.g. in labels), number 
will sometimes make sense, too. Will we always keep such corner cases in mind?
- In cases, where number is expected, logicals are often, but not always 
allowable, too.
- In cases, where factors (e.g. tabulation by groups) are permitted, logicals 
generally qualify, while strings and numbers may or may not make sense.
- We don't have specific support for date / time variables, yet. But these will 
be fun, too, as there are certainly cases, where useage is place of numbers, 
strings, or factors makes perfect sense, while in other cases it does not.

For classes, there are many more variants. Often R functions do automatic 
conversion using as.XYZ(), and that may sometimes work (and make sense) in 
cases that we had never thought about.

> 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.

Yes, showing the "offending" object in the varslot, along with some visible 
form of warning and explanation, will certainly be a big step in the right 
direction. From there, I think we basically have these options:
- Always allow the user to proceed (like required="false")
- Allow the developer to specify, whether the user should be allowed to 
proceed (something like a new attribute strict="true/false")
- Don't allow the user to proceed by default, but give them some means to 
override this.

Which would you prefer? Are there other sensible options?
 
Regards
Thomas
-------------- 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/20110928/34c21ae9/attachment.sig>