[Development] api changes

[Samuel Rødal]

On 04/13/2012 07:08 PM, ext Girish Ramakrishnan wrote:
> Hi,
> I am going through all the new apis. I have a couple of more changes
> to the public apis already. I am not submitting them to api_changes
> branch. I think Lars and co are having enough trouble as-is with
> getting api_changes to merge to master :-) All the commits will have
> the "api:" prefix in the commit message (so it's easy to see on my
> dashboard). I will stage them only after api_changes is merged.
> 
> My current understanding of the "qpa" plan is this, correct me if I am wrong:
> 1. Files with _qpa in them are supposed to be used by plugins and
> plugins only. If you see, _qpa.h being used in application code, they
> are using a binary and source incompatible Qt. _qpa.h also lacks the
> 'we mean it' header which I will add.

Mostly, though I guess an application might use QPlatformNativeInterface
to get access to a platform specific resource (such as the X display or
the wayland display or window handles etc). Maybe we'll need to make a
public API front-end for that down the line.

> 2. No public Qt include files should have _qpa.h in them
> 3. _qpa.h files are installed only so that we can allow development of
> plugins outside of qt source. I would like to see them not getting
> installed at all but I don't know if this is an oversight or
> intentional.
> 4. Also, I would like to see all the handle() functions in public api
> die. Or make them protected and make all the classes friends (as such
> they are all mostly friends anyway). handle() encourages writing
> binary incompatible code in userland. Note that handle() in qpa land
> is very different from handle() in the old qt4 land (where it just
> implied being binary compatible but platform specific).

The handle() that gets the QPlatformWindow etc? Yeah, I guess those
serve no great purpose in the public API.

--
Samuel