Preview - Input needed?

[Aaron Batty]

I guess a big issue I have is simply the wording: Preview.

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."

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.

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!).

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..."



On Sun, Jan 31, 2016 at 4:55 AM, Thomas Friedrichsmeier <
thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:

> Hi!
>
> On Sat, 30 Jan 2016 16:44:25 +0100
> d_jan <d_jan at ymail.com> wrote:
> > > 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".[…]
> >
> > What I know as a sort of standard from dockable windows in
> > applications is having the preview on/off button on the "main"
> > window, and the attached/detached button on the dockable (sub) window.
> >
> > E.g. Developer Tools in the browser: Open them via the menu or
> > shortcut; dock/undock them via a button at the dev tool window.
> >
> > Or see this mockup: http://codepen.io/anon/pen/obyGpv (wording
> > dock/sockable etc. needs to be discussed, but I think it is clear
> > enough to get what it does)
> >
> > Does this make sense?
>
> Yes. The problem I was trying to address was making it really easy to
> get something close to the old behavior (which, despite its problems,
> allows for a really convenient workflow, too).
>
> However, if we can simply add a menu bar / menu button to the preview
> window (as suggested by Meik, further down), then we will have that
> workflow covered, already. Detach-button would still be useful in that
> case, but more in the nice-to-have category. (And in fact, I think, it
> would behave different, too: _Copying_ the plot to an independent
> detached window, and thereby also logically detaching it from the
> plugin).
>
> Regards
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20160131/0c8646e0/attachment-0001.html>