Palapeli: a belated review

Hello Stefan,

First let me congratulate you on Palapeli.  It is a truly
magnificent program.  I love the way the slicer works, the
wonderful look and feel of the graphics and the way the
pieces seem to quiver and melt together when you find a fit.

Although I am late with this review (being otherwise
occupied a few weeks ago), I have now been able to
put in many hours of play on puzzles ranging from
9 to 1000 pieces.

Like Matthew Woehlke, I am an old jigsaw puzzler from
way back and have had some beauties.  Palapeli opens
up the possibility of doing really large, challenging puzzles
without inconveniencing the whole family by taking up most
of the dining table for several days at a time.  I am looking
forward to hours of fun!

I am also looking forward to hooking my grand-children on
smaller highly-personalised puzzles.  All you need is a digital
camera and Palapeli and voila, you have an endless supply
of puzzles.  You should be very proud of Palapeli, Stefan.

But I have a few suggestions to make, mostly regarding the
GUI input, which can be rather frustrating and time consuming,
particularly on large puzzles and pieces at low magnification.

My 1000 piece puzzle is a traditional "Ravensburger" scene,
similar to this shot of the crooked house at Rothenburg ob der
Tauber in Germany:

   http://en.wikipedia.org/wiki/File:Rothenburg_BW_4.JPG

Firstly, picking up pieces is a bit uncertain, especially when they
are small.  I think the hand thingy is supposed to cover the piece
(as in grabbing a door handle), but for a long time I was trying to
use the tips of the fingers (which is more intuitive for picking up
or moving a jigsaw puzzle piece).  Then, if the hand closes, I think
you have actually missed when you may think you have got it.
Worst is that if you miss and the view contains only part of the
table, the whole view shifts and you lose sight of the piece you
were trying to pick up.

I see that the RMB now moves the view, so I would suggest
removing the LMB move of the view, maybe with a popup to say
to use the RMB.  Also I would suggest a  more "positive" mouse
pointer than the hand.

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?

Several people have suggested a multi-piece pickup and that
might be the single greatest way to improve the GUI.  With the
larger 1000 piece puzzle I find myself continually searching for
and picking up pieces with some common characteristic, such
as timbers for the house in the center of the scene, edge pieces
for the left side or even pieces with the same color and similar
shapes (e.g. tabs at top and bottom, sockets at left and right).

These pieces are rarely found next to each other, so lassos
and rubber-banding would not work when pieces are scattered.

So I would like to suggest a "magnet" mode for the mouse.  When
the magnet is on, every piece you click on sticks to the mouse and
is carried along with it.  When the magnet turns off, the pieces are
dropped wherever the mouse then is.  As the pieces are dropped,
they are spread out into a small rectangular array in much the same
excellent way as when the puzzle is started.  There might be various
ways to turn magnet mode on or off.  The Ctrl key is an obvious
choice, but maybe there are better ways.  It would be up to the user,
of course, to make sure there was space where the pieces are
dropped.  If not, he/she would only make that mess once ...

Matthew's boxes could also come into play with magnet mode.
I suggest the boxes could be iconised or shrunk, so that the sorted
pieces need come back into play only when they are required
and would not take up much space on the table meanwhile.  One
of the pieces in the box could be used to "label" an iconised box.

Maybe someone asked for this already, but could we have a readily
accessible view of the picture we are aiming for?  At present, I open
one in Gwenview, but have to keep shuffling windows.

With a 1000 piece puzzle, the small size of pieces is a problem
when searching for a piece.  If you view the whole table, it is
very hard to see what is on each piece.  If you magnify the pieces,
you scroll a lot and tend to lose track of where you are on the table.

One solution is to start a small KMag window to magnify the pieces
and that is what I have been doing, but there are a couple of
drawbacks.  One is that the KMag window is distracting when
not in use.  The other is that it magnifies an already pixillated
image of the piece, so you can see the overall shape and color,
but not much else.

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.

To sum up, my suggestions are:
  - More "positive" mouse pointer.
  - No more moving the view with the left mouse button.
  - Keep the view centered on the mouse pointer when
    using the wheel to zoom in and out.
  - Magnet mode for multi-piece pickup and drop.
  - Iconisable boxes for holding sets of pieces.
  - Readily accessible view of the picture required.
  - Magnifying-glass mode for the mouse.

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 ...
  - Could the tab be called "My Collection"?  "Library" is for books and
    programs I would say.
  - How do you get access to the example puzzles?
  - Could the minimum size be 2x2?  I'd like to get my 3-year old
    grandson started on Palapeli ...
  - 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 ...
  - I once got rapped over the knuckles by a core-developer for putting
    a button in a menu bar, but I like what you have done in Palapeli:
    there is usually so much wasted real-estate in a menu bar.
  - Talking about real-estate, do we really need the scroll bars, progress
    bar and gadgets at bottom right.  I would rather be able to see more
    pieces ... and it is not hard to estimate jigsaw puzzle progress visually.
  - Is there some way (like mipmapping) to improve rendering of small
    pieces that contain fine detail?  They just go "speckly" ATM.  Perhaps
    an "average" uniform color would be more useful.
  - Could the auto-saving feature be made more obvious to a first-time
    user?  Maybe a message with a "Don't show this again" box.

Re the last two points, I picked pictures with large areas of fine detail
for my first two puzzles - leaves and fallen twigs.  I was then up till
2:30 am, not being able to find a Save menu and not daring to quit
and maybe lose my work ... :-(

Hope you find all this helpful, Stefan.

All the best, Ian W.

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

@Stefan: did you see my mail on the slicer changes? I never heard back...

Ian Wadham wrote:

> Firstly, picking up pieces is a bit uncertain, especially when they
> are small.  I think the hand thingy is supposed to cover the piece
> (as in grabbing a door handle), but for a long time I was trying to
> use the tips of the fingers (which is more intuitive for picking up
> or moving a jigsaw puzzle piece).  Then, if the hand closes, I think
> you have actually missed when you may think you have got it.
> Worst is that if you miss and the view contains only part of the
> table, the whole view shifts and you lose sight of the piece you
> were trying to pick up.
>
> I see that the RMB now moves the view, so I would suggest
> removing the LMB move of the view, maybe with a popup to say
> to use the RMB.  Also I would suggest a  more "positive" mouse
> pointer than the hand.

I've been meaning to mention this also since I noticed the RMB panning.
Yes, please remove LMB moving the view. (Also, THANK YOU for RMB moving,
it is so nice to be able to combine moving a piece with moving the view;
very useful for moving a piece a long distance without having to do it
at small zoom!)

Also I have to agree with Ian, either there is something off about the
hotspot for dragging pieces or it is too sensitive. If there is a way to
make this more forgiving, e.g. grab closest piece within so many pixels,
even if you are not actually on the piece, I think that would be a big help.

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

I have mixed feelings here. On the one hand it is convenient to not have
zooming make the view jump around. But it also means... you cannot move
the view around with zooming. Also, center-on-mouse seems to be the more
intuitive behavior. (Probably because that is what Inkscape and Google
Maps do.)

Actually... one comment here. It's not unusual for me to want the wheel
to scroll, and I think this will be a bigger issue with touchpads and
fancier mice that have also a horizontal wheel. Inkscape has an easy
solution, the wheel itself doesn't zoom, but wheel plus a modifier
(usually ctrl). Plus ctrl-wheel for zoom is fairly standard (used in
most web browsers, besides aforementioned inkscape).

> Several people have suggested a multi-piece pickup and that
> might be the single greatest way to improve the GUI.

+100 :-D

> With the
> larger 1000 piece puzzle I find myself continually searching for
> and picking up pieces with some common characteristic, such
> as timbers for the house in the center of the scene, edge pieces
> for the left side or even pieces with the same color and similar
> shapes (e.g. tabs at top and bottom, sockets at left and right).

+100 again :-D

I think I mentioned this somewhere, the idea of picking up a stack of
pieces (pick up one at a time, hold in a stack in your hand) and then
putting them down somewhere close together. I still think the baskets
idea is great, but I would give this highest priority. Right now puzzles
with many pieces (1000+ certainly, but even 200+ to an extent) are
difficult to play for exactly this reason

> So I would like to suggest a "magnet" mode for the mouse.  When
> the magnet is on, every piece you click on sticks to the mouse and
> is carried along with it.  When the magnet turns off, the pieces are
> dropped wherever the mouse then is.  As the pieces are dropped,
> they are spread out into a small rectangular array in much the same
> excellent way as when the puzzle is started.

Well. That sounds oddly familiar ;-). Except the use of "magnet". I
still think of it as picking up a bunch of pieces and making a stack in
your hand.

> There might be various
> ways to turn magnet mode on or off.  The Ctrl key is an obvious
> choice, but maybe there are better ways.  It would be up to the user,
> of course, to make sure there was space where the pieces are
> dropped.  If not, he/she would only make that mess once ...

My thinking was to have a small side bar. This would hold the "baskets",
and also a pop-up preview of the finished puzzle (i.e. "the box lid").
But most importantly it would show a preview somehow of the pieces in
your hand.

My thinking was, use LMB+drag as now. If you ctrl-click, piece moves to
your hand. If you click empty space, top piece in your hand is placed
there. (Maybe use shift-click on empty space to drop pile.) This lets
you lay out pieces in neat rows (e.g. I often lay out a row of pieces
along an edge of a puzzle). Basically, same as Ian's idea except for how
you put pieces down again.

> Maybe someone asked for this already, but could we have a readily
> accessible view of the picture we are aiming for?  At present, I open
> one in Gwenview, but have to keep shuffling windows.

Having multiple monitors is great :-). Palapeli on the main one,
gwenview on a secondary... (otherwise I am doing the exact same thing).

I think I mentioned this, but the "box top" should be a separate window
for exactly this reason, so I can park it on a second monitor.

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

That's an interesting idea; something else that could go in the sidebar
area. Hmm... I think both sidebar and box top should be docking windows;
that way you can park them if you have one monitor (or just want them on
the same monitor), or pull them off if you have multiple monitors.

Personally I haven't needed it, and Ian notes kmag as a sort-of
workaround. So probably a .1 feature rather than .0. Likewise box top
mode (since you can use gwenview as a workaround). I'm really thinking
that 'piece stacks'/'magnet mode' should be .0 though... it would be
great for .0 to be usable with 1000+ piece puzzles!

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

@Ian: well you can always edit the rc directly ;-). But being able to do
it in UI wouldn't be a bad thing, I think.

>   - Could the tab be called "My Collection"?  "Library" is for books and
>     programs I would say.

+1

>   - How do you get access to the example puzzles?

@Ian: not sure what you mean? (I can probably answer this if Stefan is
slow on mail, if I understood the question...)

>   - Could the minimum size be 2x2?  I'd like to get my 3-year old
>     grandson started on Palapeli ...

@Ian: I'd guess the slicer doesn't break, why don't you propose a patch? ;-)

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

Hmm... hadn't thought of this. Actually I /have/ sometimes wanted the
ability to tear pieces apart again. It's not unusual for me to take,
say, a long section of edge, see if it fits, then take it off again to
work on apart from the rest of the puzzle. (Mostly because having to
clear out space from the middle of the puzzle can be inconvenient. A
good example would be check if an edge goes with the corner, then pull
it away again to work on just that edge.)

>   - Talking about real-estate, do we really need the scroll bars, progress
>     bar and gadgets at bottom right.  I would rather be able to see more
>     pieces ... and it is not hard to estimate jigsaw puzzle progress visually.

Personally I don't think I would want to drop the scroll bars. IMO that
would make it harder to see where the edges of the puzzle are.

However if we add the sidebar, a PS-style navigator could solve this.
Basically you have a thumbnail of the entire table with a rectangle
showing the current view. This might even be better than

I like the progress bar! :-) But it also could fit on the side bar
instead of taking up the entire width of the window.

In the shorter term, what about combining the bottom scroll bar,
progress bar, and zoom widget?

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Patent litigation: last resort of companies whose business model has failed.

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Freitag 06 November 2009 20:23:48 schrieb Matthew Woehlke:
> @Stefan: did you see my mail on the slicer changes? I never heard back...

Which one?

@Ian: I'm afraid you can't read my answer before Sunday. I seriously need some
sleep. :-(

Greetings
Stefan


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Hi,

sorry for the long delay. Here goes the long and detailed answer:

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 think the hand thingy is supposed to cover the piece
> (as in grabbing a door handle), but for a long time I was trying to
> use the tips of the fingers (which is more intuitive for picking up
> or moving a jigsaw puzzle piece).  Then, if the hand closes, I think
> you have actually missed when you may think you have got it.
> Worst is that if you miss and the view contains only part of the
> table, the whole view shifts and you lose sight of the piece you
> were trying to pick up.

I could add the possibility to configure another cursor.

--> Bugreport 213769 (new)

> I see that the RMB now moves the view, so I would suggest
> removing the LMB move of the view, maybe with a popup to say
> to use the RMB.  Also I would suggest a  more "positive" mouse
> pointer than the hand.

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)

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

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

> Several people have suggested a multi-piece pickup and that
> might be the single greatest way to improve the GUI.  With the
> larger 1000 piece puzzle I find myself continually searching for
> and picking up pieces with some common characteristic, such
> as timbers for the house in the center of the scene, edge pieces
> for the left side or even pieces with the same color and similar
> shapes (e.g. tabs at top and bottom, sockets at left and right).
> [...]
> So I would like to suggest a "magnet" mode for the mouse.  When
> the magnet is on, every piece you click on sticks to the mouse and
> is carried along with it.  When the magnet turns off, the pieces are
> dropped wherever the mouse then is.  As the pieces are dropped,
> they are spread out into a small rectangular array in much the same
> excellent way as when the puzzle is started.  There might be various
> ways to turn magnet mode on or off.  The Ctrl key is an obvious
> choice, but maybe there are better ways.  It would be up to the user,
> of course, to make sure there was space where the pieces are
> dropped.  If not, he/she would only make that mess once ...

--> Bugreport 211870 (I think the second paragraph is what you already
mentioned there.)

> Matthew's boxes could also come into play with magnet mode.
> I suggest the boxes could be iconised or shrunk, so that the sorted
> pieces need come back into play only when they are required
> and would not take up much space on the table meanwhile.  One
> of the pieces in the box could be used to "label" an iconised box.

That's exactly how I'll implement it.

--> Bugreport 211866 (just for the record)

> Maybe someone asked for this already, but could we have a readily
> accessible view of the picture we are aiming for?  At present, I open
> one in Gwenview, but have to keep shuffling windows.

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)

> With a 1000 piece puzzle, the small size of pieces is a problem
> when searching for a piece.  If you view the whole table, it is
> very hard to see what is on each piece.  If you magnify the pieces,
> you scroll a lot and tend to lose track of where you are on the table.
> [...]
> 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)

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

>   - Could the tab be called "My Collection"?  "Library" is for books and
>     programs I would say.
>   - How do you get access to the example puzzles?

Aren't they installed for you? If not, do a "bash make-puzzles.sh" in the
puzzles subdirectory, then "make install" again. (I know, it's awkward. That
will change when Palapeli moves to kdereview.)

>   - Could the minimum size be 2x2?  I'd like to get my 3-year old
>     grandson started on Palapeli ...

Will do that tomorrow.

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

>  - Talking about real-estate, do we really need the scroll bars, progress
>  bar and gadgets at bottom right.  I would rather be able to see more
>  pieces ... and it is not hard to estimate jigsaw puzzle progress visually.

Will do that tomorrow.

>  - Is there some way (like mipmapping) to improve rendering of
>  small pieces that contain fine detail?  They just go "speckly" ATM.
>  Perhaps an "average" uniform color would be more useful.

--> Bugreport 213777 (new)

>   - Could the auto-saving feature be made more obvious to a first-time
>     user?  Maybe a message with a "Don't show this again" box.

Will do that tomorrow.

Greetings
Stefan

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.


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Parker Coates]

On Sun, Nov 8, 2009 at 17:18, 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.

I  can't believe that Ian and Matthew would give you a big list of
complaints for your birthday. Do they have no sense of decency? :D

Seriously though, happy birthday!

Parker
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Am Sonntag 08 November 2009 23:38:29 schrieb Parker Coates:
> I  can't believe that Ian and Matthew would give you a big list of
> complaints for your birthday. Do they have no sense of decency? :D

YMMD!

> Seriously though, happy birthday!

Thanks very much.

Greetings
Stefan


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Stefan Majewsky wrote:

> Am Freitag 06 November 2009 10:38:35 schrieb Ian Wadham:
>> I see that the RMB now moves the view, so I would suggest
>> removing the LMB move of the view, maybe with a popup to say
>> to use the RMB.  Also I would suggest a  more "positive" mouse
>> pointer than the hand.
>
> 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? :-)

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

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.

>>   - Could the tab be called "My Collection"?  "Library" is for books and
>>     programs I would say.
>>   - How do you get access to the example puzzles?
>
> Aren't they installed for you? If not, do a "bash make-puzzles.sh" in the
> puzzles subdirectory, then "make install" again. (I know, it's awkward. That
> will change when Palapeli moves to kdereview.)

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

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

Parker Coates wrote:
> I  can't believe that Ian and Matthew would give you a big list of
> complaints for your birthday. Do they have no sense of decency? :D

Now, now, they're not complaints, they're constructive suggestions! :-)

> Seriously though, happy birthday!

+1 :-)

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

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

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

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

>
> >>   - Could the tab be called "My Collection"?  "Library" is for books and
> >>     programs I would say.
> >>   - How do you get access to the example puzzles?
> >
> > Aren't they installed for you? If not, do a "bash make-puzzles.sh" in the
> > puzzles subdirectory, then "make install" again. (I know, it's awkward.
> > That will change when Palapeli moves to kdereview.)
>
> 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.

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

Greetings
Stefan


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

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.

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

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.
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel