[Development] important: upcoming rename of _qpa.h to _p.h

[Girish Ramakrishnan]

Hi Paul,

On Tue, Apr 17, 2012 at 1:34 AM, Paul Olav Tvete <paul.tvete at nokia.com> wrote:
> On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote:
>> As per the previous discuss, I renamed all the _qpa.h to _p.h with a
>> couple of helper scripts
>
> I just added the following "-1" comment on gerrit:
>
> I do not agree with this change. We have made a difference between public API
> and plugin API, and this is different from private implementation detail.
>
> The rest of the Lighthouse team are also skeptical. The main issue, as far as I
> can see, is documentation. This can be solved much in a much simpler way by
> using the \internal tag, as discussed earlier. There should also be a warning in
> the _qpa.h files, but it shouldn't be the "don't even think of using this file"
>  warning from the _p.h file; these files are there for platform plugin authors
> to use.
>

I marked them all as internal, preliminary and ingroup qpa for qdoc
with a718a99438aaca7d4cd4379726a8e131d3c4bf89. I also added the 'we
mean it' header (the one which you don't want) in
5369f506867532b039c7b2300d8319ff925b1434. I can change that header
depending on the outcome of this discussion :)

The current problems are:
1. _qpa.h ends up the QtGui master file. This means code completion in
qt-creator. Since we have handle(), this means users will use these
functions without thinking about the impact.
2. _qpa.h is now a new convention that end users need to be aware of.
qdoc also creates the forwarding header #include <ClassName> for these
files.

What is the QPA team's suggestion to solve the above problems? (Fix
syncqt, add pragmas to tell creator to stop processing them and/or
educate people about _qpa headers? Do you guys also want people to
develop plugins using creator? Do you guys even think the current
state of affairs is not acceptable?).

Girish