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

[Matthew Woehlke]

Stefan Majewsky wrote:
> Am Montag 09 November 2009 18:54:47 schrieb Matthew Woehlke:
>> Stefan Majewsky wrote:
>>> 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".
>> So is LMB pan going away? :-)
> 
> No, but I'll enlarge the click area (I would have done it now, if I had a 
> clean solution for this).

Well, you have two votes to kill LMB drag (or at least make it 
optional). Also Google Maps is the only thing I can think of offhand 
that does LMB drag by default (not counting things that have an explicit 
'drag' tool or where LMB is otherwise unambiguous).

>> Isn't it possible to simply edit
>> $KDEHOME/share/config/palapeli-libraryrc directly? So I'm not sure this
>> is really a problem; if someone wants to "maliciously" edit a puzzle's
>> info they can already do that, but it is inconvenient to fix e.g. typos.
> 
> No, palapeli-libraryrc is a metadata *cache*. You can insert anything you want 
> into there, but it won't help you much because the canonical metadata is 
> stored in the puzzle. (That means, of course you can change the metadata, but 
> it requires you to edit the metadata files in the puzzle.)

Okay... so it is slightly harder to "simply" edit the puzzles. But still 
not very difficult, certainly not impossible.

That said... you're the maintainer. I'm just saying, if someone /wants/ 
to misrepresent a puzzle, and is willing to expend a little effort to do 
so, they can. That should be weighed against the inconvenience of making 
legitimate changes to already-generated puzzles.

>> You might want to regenerate the puzzles after revisiting the seam
>> visibility issue. (The pen width needs to be 2.0 to fully eliminate
>> seams, not 1.5... though even then I see a small number of glitches at
>> corners, but at least it is /only/ corners.)
> 
> I had to find the middle way between the ugly lines and too big (= also ugly) 
> overlaps. The best compromise (taking the set of all default puzzles into 
> account) was 1.5 IMO.

Okay, but did you see my suggestion to just make it a proper feature 
already and add some relief at the edges?

(Also, the ideal pen width is a function of piece size and image size... 
a large image with few pieces looks great with pen size 2, but a small 
image with many pieces looks bad even with pen size 1. Which is why IMO 
it would be better to arrange that the edges are always clearly visible 
- not sporadically so, which looks like a bug - and use the unaltered 
image once the puzzle is finished.)

>>>>   - 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.
>> Personally I'm okay with this behavior, even though it /is/ a little odd
>> when any piece can fit perfectly with any other piece (e.g. rectangle
>> slicer, but also any tessellating slicer).
> 
> I agree with the oddity of tessellating slicers, but that's what a design 
> decision is about. One decides which situation is odd and which isn't. In this 
> case, I've sacrificed a little loss in reality for a big gain in usability.

Right. In case it wasn't clear, I agree with your decision here.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
My preferred shell is Christian. It's Bourne Again.