Bug 134476 - Allow larger board sizes in Majhongg game and editor
Summary: Allow larger board sizes in Majhongg game and editor
Status: ASSIGNED
Alias: None
Product: kmahjongg
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE RPMs Linux
: NOR wishlist (vote)
Target Milestone: ---
Assignee: Mauricio Piacentini
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-21 22:02 UTC by Alan Horkan
Modified: 2007-10-04 08:04 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Horkan 2006-09-21 22:02:38 UTC
Version:            (using KDE KDE 3.5.2)
Installed from:    SuSE RPMs

if you look at other mahjongg programs there are a variety of level which have much larger height width and depth than currently supported by KMahjongg
Comment 1 Mauricio Piacentini 2006-10-10 00:50:23 UTC
Yes, there is a real need to allow deeper boards, and larger ones as well. However, I believe it is a good idea to have some kind of arbitrary limit, at least for the editor. I have seen games that require 6 levels (we currently support 5), but I have not seen games with much larger board sizes. If you have any links that could help me determine the new limits please let me know.
Comment 2 Alan Horkan 2006-10-10 01:08:54 UTC
I've submitted layouts for KMahjongg and was unable to recreate many of the larger size levels.  Ideally the file format would support be able to support quite a high limit but the level editor would support smaller more realistic number of levels (somewhere around the depth necessary to support many of the boards seen in other games).  I'm fairly sure some layouts will require a depth of at least 10.  
If you have the use of a windows machine or have Wine setup you might try pretty good mahjongg http://www.goodmj.com/

There are many other improvements I'd like to see made to the level editor (not sure if I still have a copy of the ideas list I made) but making it act more like a seperate program of its own and making it easier to fill the board or draw lines of tiles would make things dramatically easier to use.  but that is better addressed in another bug report.  I filed this request because getting the underlying functionality into game is more important than spending too much time on the level editor (more important to make it possible than to make it easy).  
Comment 3 caulier.gilles 2007-10-03 12:27:42 UTC
SVN commit 720609 by cgilles:

digiKam from trunk (KDE4) : XMP metadata management with database.

This is the first stage to control XMP metadata contents with Database contents and vis versa. This code handle XMP with current Database schema witch still the same than 0.9.x.

Marcel work currently on the new databse schema describe on the OpenOffice document available at this url :

http://websvn.kde.org/trunk/extragear/graphics/digikam/DBSCHEMA.ODS?view=log

The code will be adapted later by Marcel to handle more XMP tags according with this new schema.

This is the list of current changes :

- Preparing code to handle strings hosted in different languages (comments for example, dixit B.K.O #98462).
- Handle all Xmp.exif and Xmp.tiff tags has Exif metadata content to get photo informations set by camera.
- Do not set Iptc.Urgency tag with Rating value, but use standard Xmp.Rating tags instead. Import of Iptc.Urgency 
as Rating still running if Xmp metadata are not available. (B.K.O: 134206).
- Preparing code to handle Xmp strings set different authors(comments for example, dixit B.K.O #134476).
- Set the Tags name as Xmp.subject (keywords).
- Set the Copyright/Authors information in Xmp tags (schema inspired from Adobe Photoshop 7.0).
- Store Tags Path List into a dedicaced digiKam.org Xmp namespace as a sequence of strings. Do not use Iptc.Keywords for that. Import from Iptc still running if Xmp metadata is not available. This way is very important to restore properlly in database all tags assigned to an imported picture. There is not strings size limitation with Xmp and char encoding is always UTF-8. Nothing will be lost now.
- Xmp is always stored in pictures format witch support this metadata format : jpeg, png, and tiff.

All these changes require to update libkexiv2 and Exiv2 from trunk to compile and run digiKam properlly.

CCMAIL: digikam-devel@kde.org
CCMAIL: marcel.wiesweg@gmx.de

BUG: 134206
BUG: 149966

CCBUGS: 98462
CCBUGS: 132362
CCBUGS: 91811
CCBUGS: 134476
CCBUGS: 136260
CCBUGS: 146714




 M  +59 -44    digikam/metadatahub.cpp  
 M  +1 -1      libs/database/collectionscanner.cpp  
 M  +127 -71   libs/dmetadata/dmetadata.cpp  
 M  +5 -4      libs/dmetadata/dmetadata.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=720609
Comment 4 Alan Horkan 2007-10-04 08:04:54 UTC
Gilles I think maybe you posted to the wrong bug report.