<div dir="ltr"><div><div><div>I guess a big issue I have is simply the wording: Preview.<br><br></div>It's not a preview. It's the actual view. It's more like a dynamic view than a preview. "Preview" implies something lower-quality and temporary, when actually it's the higher-quality output. The "Submit" could simply be renamed "Save to output." <br><br></div>I like Jan's idea for the docked/undocked design, but I think the graphics device should sit to the side of the window. It's already quite difficult to fit some of the taller dialogs onto a laptop screen (I use an 11"!). The problem also arises when demonstrating on a 1024x760 projector. Wider is better than taller, I think.<br><br></div><div>I actually love Meik's idea of having a link that allows you to go back to the graphics device from the output, but if it's too hard, it's too hard. That would, however, make the output work more like an SPSS output, which I think is pretty intuitive. The output is there as a record of everything you did in that session, and you can use what you see there to export to other formats for publication, etc. But I've called for more SPSS-like behavior in the output before (i.e., I'd prefer it to be saved along with the workspace, rather than just being a ticker-tape dump of everything I've ever done on any project ever, until I flush everything I've ever done ever!). <br><br></div><div>Meik: Are you going to build that 0.6.4-1, or am I? I won't be able to do that until Tuesday, because that builder box is at work, and I shut it down on Friday, and won't be back on campus until Tuesday... As I shut it down, I thought, "Will I need this anytime soon? Nah..."<br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 31, 2016 at 4:55 AM, Thomas Friedrichsmeier <span dir="ltr"><<a href="mailto:thomas.friedrichsmeier@ruhr-uni-bochum.de" target="_blank">thomas.friedrichsmeier@ruhr-uni-bochum.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<span class=""><br>
On Sat, 30 Jan 2016 16:44:25 +0100<br>
d_jan <<a href="mailto:d_jan@ymail.com">d_jan@ymail.com</a>> wrote:<br>
> > while we're still at brainstorming, I'll toss in a further thought<br>
> > in this category: Turn the "Preview"-checkbox itself into a<br>
> > tri-state control, e.g. a drop-down menu "Preview disabled",<br>
> > "Docked Preview", "Separate window".[…]<br>
><br>
> What I know as a sort of standard from dockable windows in<br>
> applications is having the preview on/off button on the "main"<br>
> window, and the attached/detached button on the dockable (sub) window.<br>
><br>
> E.g. Developer Tools in the browser: Open them via the menu or<br>
> shortcut; dock/undock them via a button at the dev tool window.<br>
><br>
> Or see this mockup: <a href="http://codepen.io/anon/pen/obyGpv" rel="noreferrer" target="_blank">http://codepen.io/anon/pen/obyGpv</a> (wording<br>
> dock/sockable etc. needs to be discussed, but I think it is clear<br>
> enough to get what it does)<br>
><br>
> Does this make sense?<br>
<br>
</span>Yes. The problem I was trying to address was making it really easy to<br>
get something close to the old behavior (which, despite its problems,<br>
allows for a really convenient workflow, too).<br>
<br>
However, if we can simply add a menu bar / menu button to the preview<br>
window (as suggested by Meik, further down), then we will have that<br>
workflow covered, already. Detach-button would still be useful in that<br>
case, but more in the nice-to-have category. (And in fact, I think, it<br>
would behave different, too: _Copying_ the plot to an independent<br>
detached window, and thereby also logically detaching it from the<br>
plugin).<br>
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888">Thomas<br>
</font></span></blockquote></div><br></div>