[Kde-games-devel] Plans for Palapeli

Albert Astals Cid aacid at kde.org
Tue Dec 31 15:00:58 UTC 2013


El Dimarts, 31 de desembre de 2013, a les 18:21:16, Ian Wadham va escriure:
> Hi guys,

Hi

> 
> I wrote to Stefan Majewsky, the author of Palapeli, just before Christmas,
> asking him if it is OK for me to develop some features to support large
> jigsaw puzzles in Palapeli, beginning with Johannes Loehnert's Preview
> facility, which is currently in the last stages of review.
> 
> He replied, adding that I could quote him on this list:
> 
>     "I'm indeed very caught up in IRL obligations, so I won't be doing any
>     work on kdegames anytime soon. I trust you and the rest of the team
>     with implementing any changes necessary to keep Palapeli fresh
>     and enjoyable.
> 
>     "So, by all means, go ahead with the patch.
> 
>     "I wish you, and the rest of the kdegames team, very happy holidays
>     and all the best for the next release cycles."
> 
> So I plan to merge and push the Preview patch fairly soon, having
> implemented Alexander and Albert's suggestions to make "Preview"
> a toggle action and button and to include it on the beginnings of
> a View menu.
> 
> Then I would like to become the developer of Palapeli for a few
> months, to the point where it can handle puzzles from 500 to 10,000
> pieces with moderate ease and convenience for the end-user, leaving
> him or her free to concentrate on the solution and its difficulties.
> 
> In the real world, you begin solving a large jigsaw puzzle by finding
> a table large enough to hold the completed puzzle and the piles or
> boxes of pieces you accumulate as you go along.  Then you "divide
> and conquer" by going through the pieces and sorting out groups
> with common attributes that might form a sub-assembly, such as
> edges and corners, skyline, parts of buildings, etc., using the
> picture on the top of the box  to help out.
> 
> In Palapeli there is no "large table" for a large puzzle, just a large
> QGraphicsScene with a QGraphicsView in which you can either
> see all the pieces, but too tiny to see much detail, or you can zoom
> in and see more detail but not see all of the pieces. There is limited
> support for sorting pieces into groups currently, but the Preview facility
> should be very useful as a "box-top picture". So my aims, after merging,
> committing and pushing Johannes Loehner's Preview feature, are:
> 
> - Improve selection operation and highlighting when the pieces
>   on-screen are shown as very tiny or have no shadows.
> 
> - Provide a quick-zoom or "close-up" feature that shows details of
>   pieces in an area and can be toggled on/off quickly, e.g. using a
>   shortcut key.
> 
> - Provide a facility to step quickly though a series of close-up
>   "frames" or views, to search the whole scene systematically
>   e.g. using shortcut keys.
> 
> - Optionally reserve space for the area where the solution will go.
> 
> - Provide holders (or boxes) in which pieces with common
>   attributes can be collected and stored --- implemented as
>   floating windows which can be moved wherever the desktop
>   system will allow, perhaps onto other desktops or monitors.
> 
> - The idea of holders as separate windows, scenes and views
>   is that they will stay in position, relative to the puzzle-table
>   window, even while the end-user zooms and scrolls through
>   the scene searching for pieces. When the solution area comes
>   into view, they will be at hand, ready for their pieces to be unloaded
>   and assembled into the solution. Or the holder-windows can be
>   moved out of the way if their pieces are not needed yet.
> 
> - Small puzzles will not have holders by default, but they can
>   be requested. Large puzzles (e.g. > 300 pieces) will have at
>   least one holder by default, but more can be requested.
> 
> - Holders can be given meaningful titles (e.g. "Edges", "Sky"). Also,
>   when they are shown at minimum size, they show the last piece
>   deposited, in close-up view, for easy identification.
> 
> - Pieces can be put into holders or taken out, just by selecting
>   and dragging in the usual Palapeli ways.
> 
> - There will be a function where a holder can be selected and
>   then pieces can be sent (or "teleported") to it, just by clicking,
>   perhaps in conjunction with a modifier key. For example, the
>   edge pieces in a "frame" of the view could be quickly collected
>   in this way, however widely they are scattered. It is analogous
>   to picking the pieces up in your hand as you go along.
> 
> - Holders will automatically arrange pieces tidily as they are collected.
> 
> - Holders will have a Select All action, for use if you wish to empty
>   the holder onto the puzzle table (by dragging).
> 
> - Holders, their contents and geometry will be autosaved in the
>   usual Palapeli way.
> 
> - Empty holders can be deleted.
> 
> - A way of re-compacting a holder or parts of the puzzle table
>   (e.g. pieces selected by rubber-banding), as the solution proceeds
>   and the distribution of pieces becomes sparse, would be nice to have.

Looks awesome :-)

Cheers,
  Albert

> 
> If anyone has any suggestions or would like to help out with this
> work, please feel free to contribute.  Also, if anyone would like to
> take over as Palapeli maintainer when I retire from KDE Games,
> please step up.
> 
> All the best, Ian W.
> 
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel



More information about the kde-games-devel mailing list