D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> broulik wrote in ktoolbar.cpp:908
> I just realized this is false-y deprecated. The feature adds the 
> configuration options for toolbar buttons.
> What needs to be done here for proper deprecation is port that over to 
> `customContextMenuRequested` or checking for policy being not `NoContextMenu` 
> or so.

For reference:

Deprecation of custom context menu enabling methods in favor of 
QWidget::contextMenuPolicy was done 2007: 
R446:41c7dd48afbf2794dbe260466d569d808d851c04 

And implementation code wrapped in 2010: 
R446:52905e8d94ee6d7a08ff1b793c5dd226f0c3fbc1 


Guess best is to add a TODO into the code for now, unless you are already on it?

REPOSITORY
  R263 KXmlGui

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: broulik, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Kai Uwe Broulik]

broulik added inline comments.

INLINE COMMENTS

> ktoolbar.cpp:908
>  {
> -#ifndef KXMLGUI_NO_DEPRECATED
> +#if KXMLGUI_BUILD_DEPRECATED_SINCE(5, 0)
>  if (mainWindow() && d->enableContext) {

I just realized this is false-y deprecated. The feature adds the configuration 
options for toolbar buttons.
What needs to be done here for proper deprecation is port that over to 
`customContextMenuRequested` or checking for policy being not `NoContextMenu` 
or so.

REPOSITORY
  R263 KXmlGui

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: broulik, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R263:808bd05b37e4: Use ECMGenerateExportHeader to manage 
deprecated API better (authored by kossebau).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D24466?vs=67733=68160#toc

REPOSITORY
  R263 KXmlGui

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D24466?vs=67733=68160

REVISION DETAIL
  https://phabricator.kde.org/D24466

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/kactioncollection.cpp
  src/kactioncollection.h
  src/kkeysequencewidget.cpp
  src/kkeysequencewidget.h
  src/kmainwindow.cpp
  src/kmainwindow.h
  src/kshortcutseditor.cpp
  src/kshortcutseditor.h
  src/kshortcutwidget.cpp
  src/kshortcutwidget.h
  src/ktoolbar.cpp
  src/ktoolbar.h
  src/kxmlguibuilder.cpp
  src/kxmlguibuilder.h
  tests/kmainwindowrestoretest.cpp

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> kossebau wrote in kactioncollection.h:308
> Fixed to `KXMLGUI_ENABLE_DEPRECATED_SINCE`, as `slotActionHighlighted` is a 
> virtual method, which the compiler needs to always know about.

Eh, fixed to KXMLGUI_BUILD_DEPRECATED_SINCE actually :)

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> kactioncollection.h:308
>  
> +#if KXMLGUI_ENABLE_DEPRECATED_SINCE(5, 0)
>  /**

Fixed to `KXMLGUI_ENABLE_DEPRECATED_SINCE`, as `slotActionHighlighted` is a 
virtual method, which the compiler needs to always know about.

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[David Faure]

dfaure accepted this revision.
dfaure added a comment.


  Yep all good from my point of view.

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added a comment.


  @dfaure Any remaining issues from your side, or is your +1 available as well 
now? :)

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[David Faure]

dfaure added a comment.


  For the record, I get
  
WARNING: QObject::connect|main QObject::connect: Connecting from COMPAT 
signal (Object::signalIt())
  
  But indeed that's because I build my Qt in debug mode. The only mode that 
truly matters for developers :-)
  
  Maybe Qt shouldn't use QT_NO_DEBUG for this. But oh well, as you noticed all 
of this only matters for the Qt4 macro. Yet another reason to use PMF connect 
instead

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D24466#547084 , @dfaure wrote:
  
  > check_and_warn_compat does not warn for this testcase because the slot is 
deprecated too.
  >  Try a deprecated signal and a non-deprecated slot :-)
  >
  >   2714│ if (signal.attributes() & QMetaMethod::Compatibility) {
  >   2715│ if (!(method.attributes() & QMetaMethod::Compatibility))
  >   2716│ qWarning("QObject::connect: Connecting from COMPAT 
signal (%s::%s)",
  >   2717│  sender->className(), 
signal.methodSignature().constData());
  
  
  Ah, missed that combination condition in the code. Though actually, I had 
tested all combinations before, disabling all or either of the QT_MOC_COMPAT 
(as you can see, blackbox testing without looking at the Qt code ;) ) , same 
with Q_DECL_DEPRECATED.  And then read that configure --release sets 
QT_NO_DEBUG, at which point I stopped looking more.

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[David Faure]

dfaure added a comment.


  Thanks for the investigation.
  
  check_and_warn_compat does not warn for this testcase because the slot is 
deprecated too.
  Try a deprecated signal and a non-deprecated slot :-)
  
2714│ if (signal.attributes() & QMetaMethod::Compatibility) {
2715│ if (!(method.attributes() & QMetaMethod::Compatibility))
2716│ qWarning("QObject::connect: Connecting from COMPAT signal 
(%s::%s)",
2717│  sender->className(), 
signal.methodSignature().constData());

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D24466#546952 , @dfaure wrote:
  
  > Maybe Qt doesn't have any deprecated signals?
  
  
  That would be nice :) A few there are though, e.g. see here some for 
QComboBox, only using `QT_DEPRECATED_SINCE` & `QT_DEPRECATED_VERSION_X`, but 
not `QT_MOC_COMPAT`:
  https://code.woboq.org/qt5/qtbase/src/widgets/widgets/qcombobox.h.html#223
  
  Perhaps people forgot about it, the macro also not being documented anywhere.
  
  Now finally got around to do some test code to check deprecation with 
signal/slots:
  
#include 
#include 
#include 

class Object : public QObject
{
Q_OBJECT

public Q_SLOTS:
Q_DECL_DEPRECATED
QT_MOC_COMPAT
void slotIt() {
qDebug() << "handling signal";
}

Q_SIGNALS:
Q_DECL_DEPRECATED
QT_MOC_COMPAT
void signalIt();
};

int main(int argc, char *argv[])
{
QCoreApplication app(argc, argv);

Object object;
QObject::connect(, SIGNAL(signalIt()), , SLOT(slotIt()));
QObject::connect(, ::signalIt, , ::slotIt);

emit object.signalIt();

return 0;
}

#include "main.moc"
  
  When building this gives:
  
main.cpp: In function ‘int main(int, char**)’:
main.cpp:29:40: warning: ‘void Object::signalIt()’ is deprecated 
[-Wdeprecated-declarations]
   29 | QObject::connect(, ::signalIt, , 
::slotIt);
  |^~~~
main.cpp:20:10: note: declared here
   20 | void signalIt();
  |  ^~~~
main.cpp:29:68: warning: ‘void Object::slotIt()’ is deprecated 
[-Wdeprecated-declarations]
   29 | QObject::connect(, ::signalIt, , 
::slotIt);
  |
^~
main.cpp:13:10: note: declared here
   13 | void slotIt() {
  |  ^~
main.cpp:31:26: warning: ‘void Object::signalIt()’ is deprecated 
[-Wdeprecated-declarations]
   31 | emit object.signalIt();
  |  ^
main.cpp:20:10: note: declared here
   20 | void signalIt();
  |  ^~~~
  
  and when running just
  
handling signal
handling signal
  
  so no runtime warning about the compat signal or slot. Possibly as 
QT_NO_DEBUG is said to be defined for Qt release builds, so 
`check_and_warn_compat` will not be run.
  
  So having a _DEPRECATED with signal makes sense also for consumers connecting 
to the signal with memberfunction-pointer based connect. Will adapt the other 
patches accordingly.
  
  Not sure what to do about the QT_MOC_COMPAT, so far it should not hurt to 
keep them, but the question is how useful adding new ones is and whether this 
is future-proof.

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[David Faure]

dfaure added a comment.


  Maybe Qt doesn't have any deprecated signals?

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> kossebau wrote in kactioncollection.h:314
> Okay, so "QT_MOC_COMPAT" is still a (just undocumented) thing, and thus 
> something we should use for deprecated signal/slots then as before, right?
> 
> Had now another look based on your info, and found that the magic to map 0x10 
> onto 0x1 happens in the getter of the method attributes:
> 
>   int QMetaMethod::attributes() const
>   {
>   if (!mobj)
>   return false;
>   return ((mobj->d.data[handle + 4])>>4);
>   }
> 
> So that mystery seems solved :)
> 
> For adding deprecation attributes via _DEPRECATED to signals, yes, would 
> agree to do this consistently then, following your argumentation. Will add 
> this to the howtodeprecateallkindsofapi text I yet have to write, so far 
> delayed to first gather experience.

Just remembered though: seems that Qt code itself no longer uses QT_MOC_COMPAT? 
At least I had no hits for actual usages in Qt classes when searching in my 
local Qt headers, via code.woboq.org or github search, there only for the old 
unsplit qt repo (which once made me think this is a Qt3 relict).

And given the `#ifndef QT_NO_DEBUG` does this warning land in normal Qt builds? 
(sorry, not build Qt in a decade). 
till have to test with my openSUSE TW, will do later today.

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> dfaure wrote in kactioncollection.h:314
> Taking this from the other side: warnings when connecting to deprecated 
> signals actually work. They happen in check_and_warn_compat in qobject.cpp
> 
> ... this does support warning about connecting to compat slots, so my comment 
> was bogus, this is fine.
> 
> For the usual case, compat signals, the code checks `signal.attributes() & 
> QMetaMethod::Compatibility`.
> 
> Ah and I found where `MethodCompatibility` (which has the value 0x10) is 
> actually set...
> the generated moc code says
> 
>   6,2,   89,2, 0x06 /* Public */,
>   8,2,   94,2, 0x16 /* Public | MethodCompatibility */,
> 
> See the second line, it has the 0x10 value in there, which means 
> `MethodCompatibility` is set by value, not by name.
> 
> I'm just still a bit confused about the relation between the 0x10 metaobject 
> flag and the signal attribute which has value 0x1...
> 
>   enum Attributes { Compatibility = 0x1, Cloned = 0x2, Scriptable = 0x4 };
> 
> But it must work, tst_qobject.cpp tests that QT_MOC_COMPAT ends up setting 
> `QMetaMethod::Compatibility` in attributes().
> 
> Anyhow, I still believe that using the *_DEPRECATED macro on a signal only 
> makes sense if we want to prevent subclasses from emitting the signal. 
> Theoretical possibility, extremely unlikely for KActionCollection, but... why 
> not. We can do this consistently everywhere without the need to consider the 
> likeliness of subclasses, I suppose.

Okay, so "QT_MOC_COMPAT" is still a (just undocumented) thing, and thus 
something we should use for deprecated signal/slots then as before, right?

Had now another look based on your info, and found that the magic to map 0x10 
onto 0x1 happens in the getter of the method attributes:

  int QMetaMethod::attributes() const
  {
  if (!mobj)
  return false;
  return ((mobj->d.data[handle + 4])>>4);
  }

So that mystery seems solved :)

For adding deprecation attributes via _DEPRECATED to signals, yes, would agree 
to do this consistently then, following your argumentation. Will add this to 
the howtodeprecateallkindsofapi text I yet have to write, so far delayed to 
first gather experience.

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[David Faure]

dfaure added inline comments.

INLINE COMMENTS

> kossebau wrote in kactioncollection.h:314
> No idea. I started a few times to look up what QT_MOC_COMPAT actually is 
> about, but never had quick results, so delayed into the future.
> 
> Just had a look again, but as before stranding with `MethodCompatibility` 
> from qmetaobject_p.h, which seems though nowhere really used.
> 
> So far my guess has been this is some relict from Qt3 times no-one ever 
> properly cleaned up?

Taking this from the other side: warnings when connecting to deprecated signals 
actually work. They happen in check_and_warn_compat in qobject.cpp

... this does support warning about connecting to compat slots, so my comment 
was bogus, this is fine.

For the usual case, compat signals, the code checks `signal.attributes() & 
QMetaMethod::Compatibility`.

Ah and I found where `MethodCompatibility` (which has the value 0x10) is 
actually set...
the generated moc code says

  6,2,   89,2, 0x06 /* Public */,
  8,2,   94,2, 0x16 /* Public | MethodCompatibility */,

See the second line, it has the 0x10 value in there, which means 
`MethodCompatibility` is set by value, not by name.

I'm just still a bit confused about the relation between the 0x10 metaobject 
flag and the signal attribute which has value 0x1...

  enum Attributes { Compatibility = 0x1, Cloned = 0x2, Scriptable = 0x4 };

But it must work, tst_qobject.cpp tests that QT_MOC_COMPAT ends up setting 
`QMetaMethod::Compatibility` in attributes().

Anyhow, I still believe that using the *_DEPRECATED macro on a signal only 
makes sense if we want to prevent subclasses from emitting the signal. 
Theoretical possibility, extremely unlikely for KActionCollection, but... why 
not. We can do this consistently everywhere without the need to consider the 
likeliness of subclasses, I suppose.

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> dfaure wrote in kactioncollection.h:278
> Does this work? It's a signal. Won't this only warn at emit time? (while 
> QT_MOC_COMPAT is what leads to a warning at connect time)
> 
> Asking because you didn't do this in D24465 
>  for the windowChanged() signals, so 
> something seems inconsistent.

This being one of my experimental repos chance is I forgot to remove the 
KXMLGUI_DEPRECATED_VERSION here, and was blind when I checked the patch before 
uploading.
Let me check again if the deprecated attribute actually gets triggered on 
memberfunction-pointer based connect, not sure right now,

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> dfaure wrote in kactioncollection.h:314
> (pre-existing) QT_MOC_COMPAT for a slot? Any idea what this might do?

No idea. I started a few times to look up what QT_MOC_COMPAT actually is about, 
but never had quick results, so delayed into the future.

Just had a look again, but as before stranding with `MethodCompatibility` from 
qmetaobject_p.h, which seems though nowhere really used.

So far my guess has been this is some relict from Qt3 times no-one ever 
properly cleaned up?

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[David Faure]

dfaure added inline comments.

INLINE COMMENTS

> kactioncollection.h:278
>   */
> +KXMLGUI_DEPRECATED_VERSION(5, 0, "Do not rely on")
>  QT_MOC_COMPAT void removed(QAction *action);

Does this work? It's a signal. Won't this only warn at emit time? (while 
QT_MOC_COMPAT is what leads to a warning at connect time)

Asking because you didn't do this in D24465 
 for the windowChanged() signals, so 
something seems inconsistent.

> kactioncollection.h:314
> +KXMLGUI_DEPRECATED_VERSION(5, 0, "Use 
> KActionCollection::slotActionHovered()")
>  QT_MOC_COMPAT virtual void slotActionHighlighted();
> +#endif

(pre-existing) QT_MOC_COMPAT for a slot? Any idea what this might do?

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Laurent Montel]

mlaurent accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau updated this revision to Diff 67733.
kossebau added a comment.


  - disable KF group deprecation macros for now
  - set DEPRECATED_BASE_VERSION=0, to not disable any API by default

REPOSITORY
  R263 KXmlGui

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D24466?vs=67429=67733

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/kactioncollection.cpp
  src/kactioncollection.h
  src/kkeysequencewidget.cpp
  src/kkeysequencewidget.h
  src/kmainwindow.cpp
  src/kmainwindow.h
  src/kshortcutseditor.cpp
  src/kshortcutseditor.h
  src/kshortcutwidget.cpp
  src/kshortcutwidget.h
  src/ktoolbar.cpp
  src/ktoolbar.h
  src/kxmlguibuilder.cpp
  src/kxmlguibuilder.h
  tests/kmainwindowrestoretest.cpp

To: kossebau, #frameworks, dfaure
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added a comment.


  If no-one objects, would be pushing on Monday evening, Oct. 14th.

REPOSITORY
  R263 KXmlGui

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau created this revision.
kossebau added reviewers: Frameworks, dfaure.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  Allows
  
  - projects linking to KXmlGui to hide deprecated API up to a given version or 
silence deprecation warnings after a given version, using
- -DKXMLGUI_DISABLE_DEPRECATED_BEFORE_AND_AT
- -DKXMLGUI_NO_DEPRECATED
- -DKXMLGUI_DEPRECATED_WARNINGS_SINCE
- -DKXMLGUI_NO_DEPRECATED_WARNINGS
  
  or
- -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT
- -DKF_NO_DEPRECATED
- -DKF_DEPRECATED_WARNINGS_SINCE
- -DKF_NO_DEPRECATED_WARNINGS
  - to build KXmlGui optionally with deprecated API excluded from the build, 
using "EXCLUDE_DEPRECATED_BEFORE_AND_AT" cmake argument.

TEST PLAN
  Builds with EXCLUDE_DEPRECATED_BEFORE_AND_AT set to 0, 4.1.0, 5.0.0,
  CURRENT.

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/kactioncollection.cpp
  src/kactioncollection.h
  src/kkeysequencewidget.cpp
  src/kkeysequencewidget.h
  src/kmainwindow.cpp
  src/kmainwindow.h
  src/kshortcutseditor.cpp
  src/kshortcutseditor.h
  src/kshortcutwidget.cpp
  src/kshortcutwidget.h
  src/ktoolbar.cpp
  src/ktoolbar.h
  src/kxmlguibuilder.cpp
  src/kxmlguibuilder.h
  tests/kmainwindowrestoretest.cpp

To: kossebau, #frameworks, dfaure
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns