[RkWard-devel] length() and na.rm

[Stefan Rödiger]

Am Donnerstag, 17. August 2006 14:28 schrieb Thomas Friedrichsmeier:
> On Thursday 17 August 2006 16:19, Stefan Rödiger wrote:
> > I totally consent. Moreover it makes things more handsome and the reuse
> > of code should also be easier.
> > I was reading the package description of "moments" and I would say it
> > really makes more sense to create a separate plug-in for this.
> > Anyway I found this plug-in is an very important one since this is what I
> > would use first to look at my raw data. Therefore the idea behind the
> > thumb images and so on. It would really describe a lot. But "keep it
> > simple" is truly better. I can use "embed" anyway later on as option.
>
> Probably it makes sense to organize the small separate plugins into a
> single sub-menu called "Descriptive Statistics" (or something like that).
> Then users will have an easy starting point for analysing their data, but
> still the functions could remain separate. Probably what we currently have
> as "Basic Statistics" will go there, too (and sooner or later we should
> have another look at reconciling some of the duplicate functionality).
> I suggest we elaborate on this, when you have some plugin(s) completed or
> the next release is nearing. Changing the menu-hierarchy is easy now, and
> does not require much pre-planning.
>

True

> > Yes, and this makes things inconvenient. I thinks a possibility for the
> > future would be to create something like "first-run wizard" for this.
> > Which means the corresponding packages are downloaded at the first run.
> > If they are not available the plug-ins should be disabled. Otherwise you
> > would get tons of bug reports. But I don't know how to handle package
> > updates and the sever issue. Do you think my idea makes things to
> > complicated?
>
> I think the "first-run wizard" is probably a good idea, but also quite a
> bit of work. I'll put it on the TODO list. This could be used to
> pre-install the most common libraries.

Unfortunately yes, its much work. I guess there are more important things than 
this right now. A "Read Me" would be easier. People who use this software 
will be literated enough to manage it anyway I guess. 

> Not sure about disabling plug-ins, 
> though, After all, the worst that will currently happen if a package is not
> installed is rkward asking you to install it. In contrast, I don't think it
> would be obvious to new users, how a disabled plugin can be enabled.

Well you are right. With a "Read Me" or Help an easy to solve question.

> I'm not sure what you mean with "server issue".

If a sever is down or somebody is not on-line or ... . Just in case. These are 
stupid mistakes which can easily avoided. It was just a thought.

>
> > > Could possibly be optimized to
> > >
> > > rk.temp.freqtable <- table (x)
> > > names (rk.temp.freqtable)
> > > [which(table(rk.temp.freqtable)==max(table(rk.temp.freqtable)))]
> > >
> > > which looks even more convoluted, but avoids calculating "table (x)"
> > > over and over again.
>
> Well, just the programmer's POV. Should not make any noteable difference
> for anything but extremely large datasets.
>

You are the boss ;)

> > > png (...) would take additional arguments width, and height, so we
> > > could extend rk.graph.on (), to include those parameters (or simply to
> > > accept a '...'-parameter and pass it on to png ()).
> > > I'll add something to CVS later, and then write back.
> >
> > Why not JUST doing via the GUI as parameter instead of extending
> > rk.graph.on ()? That should be sufficient too.
>
> Hm? But if at one place you want a full-size graph, and at another place
> just a thumbnail, then you'll need to be able to specify the size from
> within the plugin. Or are we talking about different things?
>

No, you were are talking about the same but I didn't get it actually 
(sometimes I "think" to complicated ;) ). But now ... everything is clear.

> > Yes, but as you pointed out before. Its not simple and the question is
> > what people can to with it right now. OOo doesn't support it and KWord
> > only in basics. Editing is possible via inkscape and so on but finally
> > you have to export them again to png or so. To be honest it's enough to
> > keep it in mind as longterm project since some "geek"-knowledge is needed
> > to work with svg at the moment.
>
> Another option for a scalable graph output format would be postscript, but
> I'm not sure that's such a good idea in the long rung.

I'm not such a big fan of ps. I had more trouble with ps than svg while 
importing, working with colors or editing. Most modern tools will use svg it 
in future so work with ps would somehow be wast of time and energy IMHO. So 
svg would still be on top of my list (... later ...).

> Maybe we can also 
> make it a (global) GUI choice, which output format is preferred.
>

Sounds reasonable.

> Regards
> Thomas