Preview - Input needed?

[Thomas Friedrichsmeier]

Hi,

On Sat, 30 Jan 2016 12:29:23 +0100
meik michalke <meik.michalke at uni-duesseldorf.de> wrote:
> Am Samstag, 30. Januar 2016, 10:25:12 schrieb Thomas Friedrichsmeier:
> > 1) Having the preview docked directly to the plugin window. (Size
> > is an issue, here, but could probably be solved by moving the
> > preview area to the side, instead of bottom of the dialog.)
> > 2) Having an easy way to create a full-featured on-screen graphics
> > window. This is what "Preview" is currently doing for plots.
> > 3) Having an easy way to store a plot permanently for a basic log of
> > your data analysis. This is what the output window is meant for, and
> > what the "Submit" button is doing, currently.
> > 
> > Problem is we only have two "paths" (Preview and Submit). Solutions
> > I can think of (but I'm not really happy with any):
> > 
> > - Add a third button / checkbox to all plot plugins, whatever it is
> >   called.

-- while we're still at brainstorming, I'll toss in a further thought
in this category: Turn the "Preview"-checkbox itself into a tri-state
control, e.g. a drop-down menu "Preview disabled", "Docked Preview",
"Separate window". (Actually it would even be possible, right now, to
have two separate <preview>-boxes, one for docked, one for "default"
placement.  I don't think it's what we want, though.)

> > - Combining 1) and 2), somehow:
> > -- Simply make it user configurable: Do you want plot previews to be
> >   "docked" (1) or "detached" (2).
> > -- Add a button to detach a docked preview, i.e. to go from 1 to 2.
> > - Combining 2) and 3), somehow:
> > -- Always do both 2 _and_ 3 when clicking "Submit".
> > -- Add option to do either 2) or 3) on "Submit" to each plot plugin.
> > 
> > Ideas / opinions?
> 
> we were talking about attaching the graphics device to the main
> window a while ago. not that it solves any of the issues, but this is
> probably a good time to exhume those ideas as well. here's the draft
> i did then: http://reaktanz.de/stuff/R/RKWard_graphics_section.png
>  (also look at the menu area, sorry for the german -- it's the
> graphics controls)
> the mail bringing it up (october 2013):
>  https://mail.kde.org/pipermail/rkward-devel/2013-October/003670.html
> and the assigned issue:
>  https://bugs.kde.org/show_bug.cgi?id=355533

Hm, yes, still needs attention, but as you say, it probably does not
really relate to the preview issues.

> would it help if RKWard, on "submit", didn't only store the flat
> bitmap image, but the whole raw R object (save.image()) as a
> reference, linked to in the output, so that it is re-opened in the
> graphics device if you click on it? it could be embedded in the HTML
> file in base64 encoding.
> 
> i mean:
>  - have the preview docked to the dialog (sideways is a good idea!)
>  - if you hit "submit" it is appended to the output as usual, but in a
>    <a href="base64image.RData"><img src="image.png" /></a> kind of way
>  - if you click the image, the raw image is being opened in the
> graphics device, so you can still save it in different formats or
> sizes etc. (i never tried this, i'm just assuming this is possible
> with raw plots)
>  - you can still use the "run again" link to change the plot itself

Good idea in principle, but I'm afraid this would be more complex:
First off: recordPlot() is the function you were looking for, and its
help page cautions that only plots from the current session can be
replayed (which could still be helpful, of course). I'm also not sure,
if it would work with lattice plots and such. (Certainly possible in
principle: Our plot history feature uses this, but it also has quite a
bunch of rather complex code for this...)

> the downside of this is, if you're used to save your plots from the
> preview (as i often do, too), this adds a detour to your getting to
> the graphics device. therefore
> 
>  - an extra control to detach the plot while still in the preview
> stage sounds useful to me

Follow-up question (not terribly important at this point) will be: Does
it also "detach" the preview in the sense that the preview is no longer
updated by the plugin? 

>  - if it's not too hard to do, i'd not toggle docked/detach, but
> "show menu" vs. "hide menu", i.e., either show the docked preview or
> a graphics device that is also docked in the same place, without the
> plot history

Hm, we may be on to something, here: perhaps the "problem" of a docked
preview simply boils down to the missing menubar. I'm not entirely sure
it will be possible to add, but I can look into this. We _will_ run
into some sort of platform issues, though: Think of top-of-the-screen
menus on Mac, for instance. Alternatively perhaps some "menu in a
popup" like is fashionable in browsers, these days.
 
> > Almost forgot: Could you or Meik create an updated Mac bundle from
> > the 0.6.4 release branch? Problem should be fixed, there.
> 
> how should we call it? 0.6.4.1?

Considering it's a Mac-only thing (and in fact a Mac-binary-only thing),
I'd suggest calling it 0.6.4-1 like most distros would do for a new
revision of the packaging.

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/20160130/861b24e6/attachment.sig>