[rkward-devel] [rkward-cvs] SF.net SVN: rkward-code:[4504] trunk/rkward/rkward

[Thomas Friedrichsmeier]

Hi,

On Tuesday 29 January 2013, meik michalke wrote:
> one thing that could benefit from some tweaking: before this, RKWard
> decided by the order of plugins which features were used (i mean, a later
> plugin overwrote an earlier one with the same ID, right?).

IIRC it's the reverse: The later definition is ignored. I know it can be 
useful to "overwrite" plugins during development, but I think it's always a 
"quirk", if it happens on an end user's system.

(If you think there is a valid use-case, we can certainly find a way to 
suppress the warning; e.g. by adding a new attribute override="true" to make a 
later definition override an earlier one, without a warning).

> now, if RKWard detects a duplicate ID, the second one is marked "quirky",
> if i understand this correctly. but it seems this assesment is quite
> sticky and will not change when you deactivate the conflicting pluginmap,
> even after a restart of RKWard. so i think pluginmaps should be
> re-evaluated after a) their individual status changed (checkbox), and b)
> each start of RKWard.

The key idea behind the "quirky" flag is that a user may want to continue 
using a plugin map that is known to produce warnings. In this case, if the map 
is already known to be quirky, the user won't see the same warning on each 
start of RKWard. So, clearing the flag each start of RKWard would actually 
result in more nagging, not less.

Not sure about your suggestion a), but I'm ignoring it for now, as it does not 
really cover the case at hand, either: It's the disabling the *other* 
pluginmap that makes the pluginmap in question evaluate cleanly, here.

Currently, the status flags ("quirky" and "completely broken") are cleared
- when the version of RKWard has changed since last session (to cover the use-
case that errors were produced due to a version mismatch)
- when the timestamp of the pluginmap file has changed

Obviously it also makes a lot of sense to clear the flag, when a pluginmap has 
just been loaded without problems, and so I've committed that, a minute ago.

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/20130129/3c92cd33/attachment.sig>