[Kde-games-devel] Re: REKO cardsets for KDE cardgames?

[Neil Stevens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday June 12, 2003 02:29, blachner at gmx.de wrote:
> > I personnaly don't see the problem of adding new methods to
> > KCardDialog.
>
> If I add new methods, wouldn't this break binary compatibility? As far
> as I know yes. Maybe I know wrong or I should better make
> KAdvancedCardDialog which inherits from KCardDialog to achieve binary
> compatibility?
>
> Source compatibility would be no problem.

Binary compatibility is important, though.  Breaking it requires everyone 
who's made a binary package of a game to recompile that package and carry 
two versions of it.

> > Returning QImage instead of filename seems more sensible to me. Using
> > directly KIO would be even more flexible.
>
> Hmm, I prefer the QImage way but I don't know much about KIO. If KIO
> should be used, the kcarddialog must give back a KIO URL I think. I
> don't know if KIO URL is the right word for this. That also means that
> the card games must use KIO instead normal file access to load the
> cards. Is this right?
>
> Maybe a combination is the best way? That means I write a KIO slave for
> REKO cardset and the kcarddialog uses this slave to give QImages back to
> the games. If it is done this way, the games need not access the cards
> over KIO directly and other card formats can be implemeted as KIO
> slaves.

Forcing apps that uses QPixmaps to convert QImages to QPixmaps is wasteful, 
though.  I don't see how that can be considered best.

- -- 
Neil Stevens - neil at qualityassistant.com
"The shepherd drives the wolf from the sheep's throat, for which the
sheep thanks the shepherd as a liberator, while the wolf denounces him
for the same act as the destroyer of liberty." -- Abraham Lincoln
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+6Eumf7mnligQOmERAgG/AJ4sfndbo3HYA7oribKYLnBFGZI5rQCgjjkI
GyJ/PWgIB5x4MWJtxaaVDno=
=ERFT
-----END PGP SIGNATURE-----