[Kde-games-devel] Palapeli: a belated review

[Ian Wadham]

On Mon, 9 Nov 2009 9:18:35 am Stefan Majewsky wrote:
> P.S. For my birthday two days ago, I got a 1000-pcs puzzle which I'm
> currently working on with two fellows. Photos will appear on my blog soon.
>
Well, here's wishing you many happy returns of that day, Stefan ... :-)

Of course, I did not know it was your birthday when burdening you with
all those requests, so it is extra nice of you to consider them seriously.
Presumably the puzzle you speak of  is a physical one, so maybe you
would like me to email you my 1000 piece puzzle of Rothenburg ob der
Tauber as a gift.  It's OK, the photo is one I took myself.

After attending aKademy 2008 in Belgium I went on a tour and took
hundreds of photos - Mosel Valley, Rothenburg/Dinkelsbuhl, Prague,
Vienna, Schonbrunn, Graz, Grossglockner, Ottobeuren and many,
many places in France, including lots of Loire chateaux and Gothic
cathedrals ... all good jigsaw-puzzle material.  I even have photos
of Mauricio, Luciano and Eugene in Mechelen, as well as that Belgian
coffee with the unsinkable sugar lumps ...

> Am Freitag 06 November 2009 10:38:35 schrieb Ian Wadham:
> > Firstly, picking up pieces is a bit uncertain, especially when they
> > are small.
> I could add the possibility to configure another cursor.
> --> Bugreport 213769 (new)
>
The cross-hairs one would be good.  It's the one I settled on with
Kubrick after much experimentation.  Kbk has a mixture of large and
small perspective views of cubies that you have to be able to grab.

> I'm with Matthew here. LMB is the default behavior provided by many
> applications, although Matthew is right that "if there is a way to make
> [piece selection] more forgiving, e.g. grab closest piece within so many
> pixels, even if you are not actually on the piece, [...] that would be a
> big help".
> --> Bugreport 213771 (new)
>
Well, I still favor removing the LMB drag of the view and so does
Matthew it seems, but as long as  you can minimise the incidence of
false hits when you are trying to pick up a piece, coder decides ...

> > Using the mouse wheel to magnify the view quickly is excellent,
> > but please could the view remain centred on the mouse-pointer,
> > so that the area you are working in remains visible, even when
> > you are working near the edges of the table.
> --> Revision 1046496 (turned out to be a two-liner, committed just now)
>
Errmmm ... after about 14 hours effort yesterday, I finally rebuilt Qt (4.6),
all of KDE 4 trunk, KDE Games and kdereview (where palapeli vanished
to even as I worked).  The number of "dependencies" now is unbelievable.

> Note that the implementation is not complete. The view will still remain
> centered on the puzzle table when the puzzle table is smaller than the
> viewport. (See Qt bug 5437.)
>
Maybe I am doing something wrong, but I cannot see a huge change here.

> > So I would like to suggest a "magnet" mode for the mouse.
> --> Bugreport 211870 (I think the second paragraph is what you already
> mentioned there.)
>
Matthew was the first to suggest a multi-piece pickup function, of course,
I just wanted to open up the metaphors in a user-friendly way.  One way
Palapeli could go, probably without too much programming effort, would
be like a file manager or KMail ...  You click on and highlight all the pieces
you want to pick up, using Ctrl and LMB, then you click and drag on one
of them to take the group where you want it to go.  I think, in that case,
Palapeli would need to re-group the pieces into one compact area or
drop all of them into one of Matthew's boxes.  The magnet idea is for
each piece to stick to the mouse as it is clicked (no selecting/highlighting).
The cursor could even become a small magnet.  Matthew also suggested
the idea of being able to drop pieces one at a time.  Again coder decides ...

I think it is important, to do full justice to Palapeli, to give the program
the best user-control interface you can.

> > Matthew's boxes could also come into play with magnet mode.
> --> Bugreport 211866 (just for the record)
>
Great.

> I've changed the puzzle file format to include the complete image some days
> ago, so previews of any quality can be implemented in later versions.
> --> Bugreport 213773 (new)
>
+1

> > My suggestion is to have a "magnifying glass" mode for the
> > mouse pointer (using the M key perhaps?), so you see a magnified
> > image of the piece under the pointer and maybe also the edges of
> > neighboring pieces.  Magnet and magnifier combined could be
> > a fast way to find and collect related pieces.
> Great idea.
> --> Bugreport 213774 (new)
>
Thanks, but beware ... KMag does not cut it.  It just magnifies whatever
pixels are in the reduced view.  It's enough to see what tabs and sockets
a piece has and roughly what picture is on the piece, but only if there is
not too much detail (i.e. the puzzle is not difficult).  I was thinking more
of getting the same local view of one piece as you would of the whole
table if you used the scroll-wheel.

> > Just a few more minor points:
> >   - Can we change the properties of a puzzle in My Library?  I gave
> >     one of my puzzles the wrong name ...
>
> I'm not sure about this one. The puzzles in the library could also be
> imported from some external resource, and it is not a good idea to let the
> user put his name on puzzles made by others. Perhaps some special rule
> could be inserted to allow editing only for puzzles created on this
> computer, but that would require to change the library format. I do not
> like changing formats some days before release (even if the release is only
> to kdereview).
>
This was a design issue in KGoldrunner and might be again if/when it
gets new levels in hot new stuff.  KDE access to runtime data-files does
not care whether it is looking in $KDEHOME or $KDEDIR, so I just used
subdirectories "system" and "user" to keep released levels and locally
composed levels quite separate.  No need to affect formats.

> >   - Could the minimum size be 2x2?  I'd like to get my 3-year old
> >     grandson started on Palapeli ...
>
> Will do that tomorrow.
>
Errrmm ... Please also change the minimum values in the spinboxes.

> >   - Long-term we may need ways to be not so obvious when a fit occurs
> >     and to tear a piece loose if it is in the wrong place.  I've seen
> >  puzzles with that level of difficulty ...
>
> Currently, you cannot at all affix pieces to other pieces that are not
> direct neighbors. This is due to the generality of Palapeli's game engine:
> It does not make any assumptions about how pieces are ordered.
>
Well, I said "long-term" ...  Once I owned two puzzles with very uniform
coloring and many similarly-shaped pieces.  One was circular, with about
1000 pieces and about 50 cm diameter, a photo of a ceramic plate moulded
and painted by Picasso, all in cream colors with raised areas and pale blue
brush strokes.  The other was of Escher's "Belvedere", the pavilion with the
impossible columns, which was almost all beige tints, had maybe 5000
pieces and measured about 100x75 cm.  Both puzzles required many
"re-fits" of pieces before I could solve them.

Such puzzles might be a long-term aim for Palapeli, but, with the
way it works now, you could still make quite a difficult puzzle out
of a rectangle of uniform color sliced into smaller rectangles ... ;-)

Thanks again for all your responses, Stefan.

All the best, Ian W.