[Kde-games-devel] Palapeli preview window survey

[Ian Wadham]

On Monday 16 August 2010 1:47:18 am Johannes Löhnert wrote:
> > The magnification widget is working, but I need to work out how to
> > scale it accurately and move it.  If I have time to finish it today, I'll
> > send in the patch.  Otherwise it will have to wait till next weekend.
> > I have a full calendar for the next few days.
> 
> The idea of such a widget sounds good. Would you suggest to put in into a
>  tool window like the solution? Scaling could simply adapt to the largest
>  atomic piece on the board.
> 
Yup, and I already did that.  It's scaling nicely now.  I'd also like to have
a keyboard shortcut to turn it off and on.

I ran out of time last night, so I have not been able to get it to "click
through", i.e. let the main Palapeli::View see mouse-clicks that are made
on the magnifier.  So, if the magnifier follows the mouse (a config option
maybe), I have to offset it a bit, which makes it not so easy to use, e.g.
view a piece here, click it a centimetre or two further away ... :-)  If
I have time (I'm babysitting all day today), I'll send a patch of it as it
stands and you can have a look.

> > My idea is to have a special "drop" action that works as follows:
> >
> >   1. Use a generalized version of the code in Palapeli::Scene::
> >       loadPiecePositions to arrange the selected pieces into a grid.
> >   2. Make room for the grid (not the scattered pieces), as necessary.
> >       Maybe allow some extra space for later additions to the grid.
> >   3. Drop the pieces, as arranged in the grid.
> >   4. Place a QGraphicsView over the grid area that contains just
> >       that area and no other pieces.
> >   5. Magnify the grid and expand the widget on hover, to allow
> >       easy viewing/selection of pieces to be moved back into the general
> >       puzzle area.  Not sure yet how the player would signal "done" when
> >       ready to shrink the box and see the main puzzle area again.
> >   6. Provide functions to dismiss the widget, etc.  Dismissing
> >       would send the puzzle-table back to normal, just as if you
> >       had used the edge to sort those pieces.
> >   7. Allow steps 1-6 to be repeated with any number of boxes,
> >       according to the whims of the puzzle-player, e.g. boxes
> >       for edge pieces, sky pieces, tree pieces, road pieces, etc.
> >
> > What do you think, Johannes?
> 
> hm, step by step:
> ad 0. (how to trigger) - Stefan has some drafts of "on screen widgets"
>  similar to the Plasma cashew.
>  (http://majewsky.wordpress.com/2009/02/23/the-week-in-palapeli-research-on
> -fullscreen-interfaces/).
> 
Interesting, especially the "full screen" aspect.  Onwards to touch screens!
(See another thread).  BTW I am using the corners for the solution window,
not having a second monitor.  That's a rather old blog page, though.

> Maybe one could drag pieces on one of those edge
>  icons to open a box. They would be always visible, in contrast to the
>  puzzle table edges, which increases convenience.
> 
> ad 1. - IMHO, "rearranging pieces" and "moving pieces into box" should be
>  separate actions. Maybe one just wants to close "gaps" without moving
>  pieces into a box. Or OTOH maybe one wants to move pieces to a box which
>  are already arranged (e.g. three mergegroups with missing links).
> 
Yes, definitely.  I realised that (esprit d'escalier or Treppenwitz) after
I had sent the email.

> ad 2. - .. do I understand correctly that you would use a "far off" place
>  in the main scene as box? Sounds, well, hackish to me. But indeed it would
>  be a simple solution, so why not.
> 
Heh! Hackish? But indeed why not? I would say it is minimalist. It is like
what a jigsaw puzzle player does in real life (clear some space at the edge of 
the table or use the box-lid, etc.) and it builds on existing methods rather 
than inventing new ones.

> ad 4. - That graphics view, do you mean it would be a separate window like
>  the solution view? Or should it be embedded in / replace the main view
>  somehow? (I am not sure yet what I would like better...)
> 
Having seen your solution window, I think a "box" could be a transparent
widget with an almost invisible frame, positioned and sized over any sub-area
of the puzzle table on which the player is currently working, e.g. a box of
sorted pieces believed to belong to the house at the center of the picture
or a box that encloses the partially completed house.  Either box would
expand on hover to allow more detailed working.  All the engine functions
for solving puzzles would work inside a box, much as they do on the rest
of the puzzle table.  This would allow "divide and conquer" on very large
puzzles, without large amounts of zooming and scrolling.

> ad 5. - well, was I placed before it without a manual, I would expect that
>  I must drag the selected pieces out of the widget into the main view to
>  signal "done". However I don't know if thats technically possible.
> 
Maybe, but I think "drag" may be unsafe in this context and might be hard
for the user to perform.  The images of the pieces are very small in a large
puzzle and easy to miss when clicking.  We had some trouble with that in
the early Palapeli before Stefan got the hand/fist thingy sorted out.

For example, you might select N pieces from all around the puzzle table,
collect them into a grid and then, through a misplaced click, drop the lot
right over a whole lot of other pieces, even perhaps the partial solution,
leaving a real mess to be cleaned up - not very friendly ...

Me, I have never really liked "drag and drop", for that kind of reason.

One of my favorite UI's was on the Xerox Star, which was object-oriented
rather than procedure-oriented, unlike almost every GUI since (curses on
Microsoft, though Apple had a hand in it, too).  On the Star, you would
select an object by clicking, press a generic key on the keyboard to say
what you wanted to do with that object (e.g. Move) and then, if necessary,
click on a destination, i.e. like object->method(parameter).  For example,
to print, Move a file to the print-server icon.  To store a file, Move a file
to a file drawer or folder icon.  No need for dialogs in every app and no
need for a File Manager.  Very easy for first-time users to learn, as I can
attest from experience.

Some software is starting to go that way today, e.g. Inkscape and Blender,
but the keys are letters you have to remember, not nicely labeled keys that
say "Move" or whatever.

So drag and drop if you wish, but also allow something like multi-select
as at present, keystroke to form a grid, click for where you want to drop it.

> > BTW, shouldn't the "preview" be called a "retro-view" ... :-)
> > It's what you had before you shuffled the puzzle ... :-)  I'm joking, but
> > maybe "solution" and "view solution" would be good words for the UI.
> 
> I agree, "Solution" FTW. :-)
> 
Stretching a definition a little, you could use KStandardGameAction::solve
as the action, with standard shortcut S and the icon a wizard's wand.  Or
maybe KStandardGameAction::hint would be more appropriate, the icon
being a light bulb.

All the best, Ian W.