[Kde-games-devel] Palapeli preview window survey

[Johannes Loehnert]

Hello,

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

well, my main point was the suggestion of a fixed place on-screeen where to 
drag pieces to box them away. I am agnostic to whether it is a "onscreen 
widget", a window border or a little twinkling pink unicorn. :-)

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

In my point of view, the key issue is persistence. Meaning that the game 
should remember my boxes across sessions. (probably obvious...)
On a sidenote, for real-life puzzles I actually use lots of boxes, but seldom 
the sidespace of the table. Maybe that's why "separate scenes" seemed a better 
metaphor to me.

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

Thinking about it, maybe one should do something like the tiled windows in 
dolphin: give some means to subdivide the main view, and undock / redock those 
subwindows to make the multihead users happy. In this way of thinking, the 
"boxes" would simply become predefined view rects onto the puzzle scene. Each 
view could have a dropdown to set the view to a certain "box". The expand-on-
hover feature could be added on top.

Regarding the solution window as in the patch -  please keep in mind that 
currently it is just a suggestion by me. Stefan was not really convinced when 
I first showed it to him, and he is the one to decide what gets commited.


> 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. 
> 
> [... description of Xerox UI ...]

Drag&drop is an action which most computer users are used to, and probably 
will expect to work. What I like well is the "Photoshop" model - in that 
programm, a selection cannot be lost by a misplaced click, it is dismissed 
only if you explicitly command it. And in case of accident, Ctrl+Z brings it 
back.

That said, the Xerox model could be tacked on without losing anything. I think 
both things (Photoshop selection and Xerox behaviour) could be realized by 
extending the existing InteractorManager.


Best regards,
 Johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20100816/eeb7afd3/attachment.sig