A good time for breaking the miral API and ABI?

Mir
1

In order to keep the miral ABI stable we’ve used a slightly inelegant design for the WindowManagementPolicy interface: implementers of this policy can, optionally, implement a number of addenda (these are detected “under the hood” by dynamic_cast).

Last year, as we were preparing for Unity8 desktop I was aware of a number of features that we would need to support for desktop this way and I’ve just implemented the last these for Wayland clients as WindowManagementPolicyAddendum4.

There are no more extensions known in my “pipeline” and I’ve wondered about the impact of cleaning this up and moving these features directly into the WindowManagementPolicy interface.

At present there are a fairly limited set of projects using miral. The ones I know of are:

But are there more I don’t know about?

Regardless of changing libmiral QtMir is going to have to deal with a libmirserver ABI break in the next release of Mir, so I think the additional impact will be small. I own egmde and am prepared to fix it. And I doubt anyone cares about bad-shell.

I think this is a reasonable time to consider this change. Does anyone think differently?

2

Well as the guy who used to own QtMir, my response to any Mir API change was always: I can deal with it as long as no functionality is lost.

When you have prepared a branch with the API/ABI changes, I can have a look to see how much work QtMir would need to adopt it.
-G

3

For qtmir I think this should be fine as long as it don’t remove any functions. I agree now it’s probably the best time to do it.

4

Mir 0.31 (released a few weeks ago) has the new “MirAL 2.0” API. This is just a status update on the downstream projects called out above: