[rkward-devel] power analysis plugin

[Thomas Friedrichsmeier]

Hi,

On Sunday 05 October 2014 16:01:27 meik michalke wrote:
> > That might even help work around the squeezing you get when switching from
> > single sample to two samples (depending on dialog height).
> 
> that's still an annoying bug, isn't it? by the way, while working on this i
> came to notice that the squeezing only happens on my laptop, not on my
> desktop machine -- both run the same distro, KDE and Qt versions and, from
> what i can see, use the same desktop theme, window layout stlye etc.
> 
> on my desktop, the window is always resized accordingly (it only never
> shrinks after it had grown due to new elements appearing).

Well, no idea why it works in some cases but not in others. Not much point in 
debugging such "details" before porting to KF5/Qt5, though.

One thing that has always been slightly buggy regarding Qt layout is when text 
is word-wrapped. Any chance this could be the difference (i.e. note is word-
wrapped on your laptop, but not on your desktop)?

> > Another thing is: Considering this looks fairly finished (apart from
> > documentation), and useful to a wide audience, should we make this part of
> > the 0.6.2 release?
> 
> sure, why not. would someone jump in to do write the help file? ;-)

I'll see what I can do.

> how would you like to do this? generally, i'd prefer to add it as a kind of
> bundle, so it remains a plugin on its own, at least so it can be disabled
> easily in the plugin configuration. this makes it easier to release updates
> of that part without having to wait for another RKWard release. but that's
> probably a bit more complex to do right, at least for the debian packaging?
> > On a more general note, which external plugins are "ready" for inclusion?
> 
> don't you think the menus might get a bit to crowded if we include it all?

Well, yes, the menus are starting to be crowded (although I don't think it's a 
"real" problem, yet). But are they crowded with the right things? If / when we 
make a plan on which plugins should be enabled/disabled by default, power 
analysis would _not_ be among the first to go, IMO.
 
> perhaps we can re-think the plugin installations process instead, to make it
> more obvious which plugins are available (at least the ones in our own
> repo).

That's true in it's own right. But I think having to install a plugin, in 
order to be able to use it, is always going to be more cumbersome / less 
discoverable. And at least from a bandwidth point of view, including plugins 
has a barely noticable impact on the size of releases.

From another point of view, there are two areas that could be improved:
- Having an easy way to provide updates for "official" plugins without a full 
release. That might be as simple as changing the rule "first to be defined 
wins" to "latest version wins", when dealing with conflicting plugin 
declarations. (Well, actually, that's easier said than done, implementation-
wise, but conceptually, it's straight-forward...)
- Providing better control over which plugins are active. I'm still not 
convinced, the level of individual plugins is (typically) the right 
granularity of control, but in fact, control should be more fine-grained than 
the current "official" pluginmaps, and esp. more fine-grained than simply 
using all.pluginmap, by default.

Anyway, that's both for another release. Keep nagging me about it. But IMO it 
should not keep us from including more plugins, that are currently external, 
ATM.

> that said, i think the plugins for ANOVA, factor and cluster analysis are
> quite useable -- except they all lack docs...

Ok. More than I can handle for 0.6.2, probably, but should be on the list for 
0.6.3, then.

> > (Well, yes, I really should have thought about this, earlier. OTOH, I
> > think
> > there is a point for releasing 0.6.3 rather shortly after 0.6.2 - i.e.
> > before end of this year - anyway. This could include dynamic i18n for
> > plugins, and some other bits that are mostly orthogonal to porting to KF5,
> > technically.)
> 
> you mean like a restart button for the R backend? :-D

Well, I was rather thinking about some other _easy_ bits ;-).

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/20141006/5c926a97/attachment.sig>