Preview - Input needed?

[Thomas Friedrichsmeier]

Hi,

On Tue, 26 Jan 2016 15:22:56 +0000 (UTC)
Jan Wort <d_jan at ymail.com> wrote:
> > Now that the import plugins have a preview, should "Open imported
> > data for editing" still be the default?
> 
> It would show that the action was actually done (and successfully so)
> so I'd suggest to continue using this behaviour. (Just tried it
> myself, accidentally with a large table, which did not appear
> (immediately) --  I found this irritating)
> 
> 
> >Many plugins require add-on packages to be installed, and the 
> 
> > usual work-flow is that once the plugin is run,...
> 
> Hmm, I don't understand - is this because previews need additional
> packages?

Many plugins require add-on packages, e.g. XLConnect for the
(Java-based) Excel import plugin. If that package is not installed,
RKWard will prompt for the package to be installed once you click
"Submit". (Via the overloaded require()-function in R). Part of the
idea for this "installation on use" approach is that users will be able
to evaluate whether a certain plugin is the thing they are actually
looking for, _without_ having to install requirements _first_. Also, in
some cases, the requirements change according to the settings in the
UI.

Now, previews are not any different from this, in principle, except
they will "do stuff" before you click "Submit", possibly even as soon
as you open the dialog. This would defeat the above logic, and thus my
thought was that it is better to show a message "cannot show preview,
because package XY is not installed", rather than the usual prompt for
installing the package.

(In fact, in the current implementation, if you were to _not_ install
the required package, the preview would prompt you to install it again,
and again, and again, for every change you make in the UI).

> > Also, of course, now that plugins can show data, and also 
> 
> > output (as in the output window), which are the plugins where 
> 
> > previews will be particularly useful?
> 
> I'd assume that any data-restructuring would benefit greatly, like
> generate random, recode, sort, subset, (in the future maybe some
> reshape like function etc.) Currently, I assume that for tests it is
> not very useful (except for evil p-hackers ;-) ) but I may be wrong
> here. 

Yes, sounds reasonable. Will see what I can do (but adding previews is
rather easy, all in all).
 
> > Wonderful! The associated JS files do not seem to arrive on 
> 
> > codepen, though, so the mockup becomes read-only. Is that fixable,
> > too?
> 
> Ah, interesting question. This would allow them to life on codepen
> only. Maybe it's possible, I'd need to try. The current usecase for
> the function was just sharing, like a fancy image :)

Yes, and that's really useful, too. My idea was that if the shared
"image" remained editable, this would make it even easier to "reply" in
the same medium, e.g. by posting yellow stickies, or moving elements
around.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20160126/6148f201/attachment.sig>