From quanta-devel Sun Apr 03 18:34:38 2005 From: Eric Laffoon Date: Sun, 03 Apr 2005 18:34:38 +0000 To: quanta-devel Subject: Re: [quanta-devel] HEAD requirements? Message-Id: <200504031134.38202.sequitur () easystreet ! com> X-MARC-Message: https://marc.info/?l=quanta-devel&m=111255316017722 On Sunday 03 April 2005 11:28 am, Paulo Moura Guedes wrote: > On Sunday 03 April 2005 16:27, Eric Laffoon wrote: > > Is there a reason not to support back to the past version as we have in > > CVS. Do we want HEAD to require 3.4? If so I should read my mail more > > often and get in the discussion, and if not Moura should look at ifdefing > > some code I think. ;-) > > LOL > But I did: > #if KDE_VERSION >= KDE_MAKE_VERSION(3,4,0) > /** > * We need this information in order to know if queued actions should > be applied. > * It's public because it can be activated by other classes if there > are any queued actions. > */ > virtual bool slotActionActivated(KAction::ActivationReason reason, > Qt::ButtonState state); > #endif > > #if KDE_VERSION >= KDE_MAKE_VERSION(3,4,0) > connect(this, SIGNAL(activated(KAction::ActivationReason, > Qt::ButtonState)), SLOT(slotActionActivated(KAction::ActivationReason, > Qt::ButtonState))); > #else > connect(this, SIGNAL(activated()), SLOT(slotActionActivated())); > #endif > > Weird... I will try to compile this in a 3.3 machine to see what happens :) Due to being pretty busy I have not yet upgraded and I did get this error. I'm okay with having to upgrade as I planned to anyway but I thought I should mention this. Andras' statement of our past policy is correct, but we typically waited a little while into the version to implement it and then announced it on the list. I have some unread mails so I could have missed it. I just wanted to make sure we're consistent. I'll try to get to the news system for kdewebdev.org today or tomorrow too. Eric _______________________________________________ quanta-devel mailing list quanta-devel@kde.org https://mail.kde.org/mailman/listinfo/quanta-devel