[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [patch] request for review - apidox for kdelibs/kdeui (long)
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2003-09-09 1:20:08
[Download RAW message or body]

Sorry to having made a confusion! It is the other way round. Of course, you 
define KDE_NO_COMPAT in a program only when you do *not* want compatibility.
You make sure that it is not defined if you want compatibility to the previous 
major version.

So the problem with KOffice was that it was compiled with KDE_NO_COMPAT and 
somebody had put some functions that it needed depending on #ifndef 
KDE_NO_COMPAT, which of course broke KOffice.

I hope that this time I have stopped confusing you.

Have a nice day!

On Sunday 07 September 2003 18:51, Nicolas Goutte wrote:
> I am sorry to have not been precise enough. I am also sorry to have written
> compatibility again with a c too much (the symbol is KDE_NO_COMPAT.)
>
> I am going to answer your second question first.
>
> Defining KDE_NO_COMPAT is a "tool" for compatibility between major KDE
> versions. So let take for example the near future: KDE 4. In KDE 4, there
> will be functions that will be considered deprec(i)ated and these will be
> conditional with KDE_NO_COMPAT so that KDE 4 application do not use these
> functions. Of course, a KDE 3 porgram will probably still need these
> functions and therefore will need to define KDE_NO_COMPAT.
>
> KDE_NO_COMPAT is not meant to exclude functions between say KDE 3.1 and KDE
> 3.2. The reason is that an application that is not part of the basic
> modules of KDE (for examples: KOffice, KDE ExtraGear...) will not define
> KDE_NO_COMPAT, as they are adapted to run on KDE 3. (Defining
> KDE_NO_COMPACT would mean that they need compatibility functions from KDE
> 2.)
>
> KDE_NO_COMPAT comes from a similar symbol in Qt: QT_NO_COMPAT, which is
> also used for compatibility between major Qt versions.
>
> As for your first question, the answer is there should be not any new
> KDE_NO_COMPAT conditioned functions before KDE 4. (And as soon as KDE 4.0
> is out, the next ones will not be until KDE 5.)
>
> I hope that I explained it a little better.
>
> Have a nice day!
>
> On Sunday 07 September 2003 13:48, Brad Hards wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Sun, 07 Sep 2003 21:17 pm, Nicolas Goutte wrote:
> > > I do not think that adding #if KDE_NO_COMPACT is allowed.
> > >
> > > KDE_NO_COMPACT is only for major version KDE 2, KDE 3, future KDE 4.
> > > Inside a major version (KDE 3.0, 3.1, 3.2..), it should *not* be added.
> > > (Someone has already broken KOffice this way, so please do not start
> > > that again!)
> >
> > I'm not following you.
> > 1. Are you saying that there should not be any dependencies on
> > KDE_NO_COMPAT at all? Or are you saying that could can be excluded
> > (#ifndef KDE_NO_COMPAT), but not included (#ifdef KDE_NO_COMPAT)?
> > 2. What is the purpose of KDE_NO_COMPAT? When it is used, what does that
> > mean?
> >
> > Brad
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.0.7 (GNU/Linux)
> >
> > iD8DBQE/WxsLW6pHgIdAuOMRAthqAJ9ZB88mxmMyA0clEGdfdLIoEoW9EACgnJHF
> > AkuAxGQT5S5+DYx1y+AN5fE=
> > =yFbu
> > -----END PGP SIGNATURE-----
> >
> > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> > >> unsubscribe <<
> >>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]