Previews - another new thread

[Thomas Friedrichsmeier]

Hi,

On Wed, 03 Feb 2016 15:29:33 +0100
meik michalke <Meik.Michalke at uni-duesseldorf.de> wrote:
> Am Dienstag, 2. Februar 2016, 21:34:18 schrieb meik michalke:
> > as soon as you want to see both, code and plot preview, almost all
> > dialogs today are not high enough for  proper display. i guess
> > you'll have to resize one way or the other.
> 
> i've toyed around a bit with the correlation plot of
> rk.FactorAnanlysis. here's how it comes up for the first time, with
> plot and code preview activated:
>  http://reaktanz.de/stuff/R/RKWard_previews_right01.jpg
> 
> i deactivated code preview and rescaled the plot so it is fully
> visible: http://reaktanz.de/stuff/R/RKWard_previews_right02.jpg
> 
> then i closed the dialog, re-opened it and re-activated the plot
> preview again:
>  http://reaktanz.de/stuff/R/RKWard_previews_right03.jpg
> shouldn't it remember its geometry?

sorry, bug. I believe it should be fixed in git, now (I'm in the middle
of moving some stuff around, can't test easily, ATM). Play some more ;-)
 
> activateing the code again makes things worse:
>  http://reaktanz.de/stuff/R/RKWard_previews_right04.jpg
> we were much better off with the configurable default preview height
> for code below the dialog, for my taste.
> 
> to actually see both comfortably, the whole dialog must be rescaled
> rather drastically:
>  http://reaktanz.de/stuff/R/RKWard_previews_right05.jpg
> it wastes a lot of screen in the left center.

You are aware that you can change the relative height of the two preview
sections, when both are active?

> ideally, but probably only for this particular dialog, this would be
> my preferred view, as it makes the best use of screen space:
>  http://reaktanz.de/stuff/R/RKWard_previews_remix.jpg
> this would show the code preview with the same width as is does until
> now, but add the plot right to it. things are different if the
> buttons are moved, of course. and we'd need some intelligent resizing
> rules depending on the previews visible. i'd rather leave the plot
> unchanged until one manually resizes the window. does this makes any
> sense?

Hm, two problems here:
a) Likely, a single layout will never be optimal for each and every
dialog. I'd still think we should try to arrive at _one_ layout that
will work well in most cases, and not be too much of a nuisance in the
remaining ones. I think I actually prefer your previous suggestion
(code preview at bottom, spanning whole width) over the present one,
but I'm not yet really convinced of either.
b) This also depends on the placement of buttons, and we can't really
discuss the two issues, separately. Button placement will affect
typical dialog width / height, thus thus affecting preview size (esp.
most dialogs would become 1/4 to 1/3 wider, if we place buttons at the
bottom, instead of the side). But also preview placement will affect
where buttons will feel most natural.
Would you like to prepare some simple mockups to view side-by-side,
along with their pros and cons?

I'll also add:
- "Intelligent resizing rules" sounds rather scary to me. I think I
  understand the problem you are trying to fix, but I'd be skeptical
  both that it is important enough, and that really good rules _can_ be
  formulated at all.
- Not sure how many use-cases there actually are for _viewing_ both
  code preview and other previews at the same time. Sure it makes for
  nice screenshots, and sure it is nice to have (and I made a point of
  trying to support this), but perhaps the main point is still that
  both kinds of preview will be really easy to access. If we find
  showing both at once causes too much interference (esp. the previews
  affecting each other's sizing), one alternative to think about would
  be showing only one at time (e.g. tabbed).

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/20160203/da9e00ea/attachment.sig>