Previews - another new thread

[meik michalke]

hi,

Am Mittwoch, 3. Februar 2016, 19:01:19 schrieb Thomas Friedrichsmeier:
> On Wed, 03 Feb 2016 15:29:33 +0100
> meik michalke <Meik.Michalke at uni-duesseldorf.de> wrote:
> > 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 ;-)

cool, works.

> > 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?

yes, i did adjust them. i meant that if you want to see more of the code here 
while the plot is active, you have two choices:
 - changing width will also resize the plot preview, they are tied to each 
   other
 - changing height also resizes the plot, but more importantly, you must
   enlarge the window to the full dialog's width, covering more and more of
   the screen with useless plain areas

the code preview in the past was always working great for me (except for the 
vertical resizing problems of Qt, but that's not an issue of RKWard's design). 
yes, it needed some resizing now and then, but most of the time that didn't 
bother me much. resizing never wasted space.

if we move the code preview like above, i would consider this a change for the 
worse, because it doesn't really improve anything from my point of view, but 
introduce new hassles.

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

yes, as i said ;-) i didn't want to suggest this layout for everything, just 
imagine something that would address the space issue most efficiently.

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

the more i think of it, the more i like that one, too (see below).

> b) This also depends on the placement of buttons, and we can't really
> discuss the two issues, separately.

yes, i meant the same thing.

> most dialogs would become 1/4 to 1/3 wider, if we place buttons at the
> bottom, instead of the side

what about splitting them up -- moving the "help" button to the top right and 
"submit" and "cancel" to the bottom?

btw, when i moved them to the top, i didn't really imagine them as "boring" 
buttons like now, but more like toolbar controls that could also be enhanced 
or even replaced by icons (see below). i don't have strong feelings for either 
position, but these icons are probably useful anyway?

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

maybe the wording wasn't so good. what i meant was, if you pull at what end of 
the dialog, what should remain fixed and what is being resized? e.g., with 
plots to the right and code at the bottom, i would like to be able to resize 
the plot when pulling on the right side or top, and only the code preview when 
i pull the left side or bottom.

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

i would see this as a decline in functionality, too, because i actually use 
this a lot and wouldn't want to lose it, needing to switch forth and back 
between plot and code to examine which option has what effect in the outcome. 
think of teaching scenarios, where you would like to show this to other 
people. this i wouldn't throw out of the window.

some more sketches -- here's code below with buttons as icons on top:
 http://reaktanz.de/stuff/R/RKWard_previews_remix3.png
similar, but with "submit"/"cancel" below:
 http://reaktanz.de/stuff/R/RKWard_previews_remix4.png
personally, i'd still prefer the top variant, because the buttons always 
remain in position, independently of any preview/resize action. how do you 
feel about this?

you might have noticed i've left out the preview checkboxes. they seemed 
redundant to me when previews are active, so why not replace them with toggle 
buttons like this (code is collapsed now)?
 http://reaktanz.de/stuff/R/RKWard_previews_remix5.png
this could be the dialog when it's opened without active previews:
 http://reaktanz.de/stuff/R/RKWard_previews_remix6.png
similar, but with "submit"/"cancel" icons on top:
 http://reaktanz.de/stuff/R/RKWard_previews_remix7.png

there's a lot of variance in alignment, and icon sizes are a bit too much, i 
guess. but you get the idea, pick one if you like it ;-) 


viele grüße :: m.eik

-- 
  dipl. psych. meik michalke
  institut f"ur experimentelle psychologie
  abt. f"ur diagnostik und differentielle psychologie
  heinrich-heine-universit"at d-40204 d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20160204/cdc61641/attachment.sig>