Could you please add this to the test case. IIRC we have already a few tests for force temporary.

In practice I fear force and force temporary are the same on Wayland nevertheless. I don't think that unmap will we be used a lot - unlike on X11 where e.g. minimizing a window results in it being unmapped.

In D18494#399196, @graesslin wrote:

Could you please add this to the test case. IIRC we have already a few tests for force temporary.

I already added them. :-)

See test*ForceTemporarily in shell_client_rules_test.cpp

In practice I fear force and force temporary are the same on Wayland nevertheless. I don't think that unmap will we be used a lot - unlike on X11 where e.g. minimizing a window results in it being unmapped.

Hmm, so when should we discard the force temporarily rules?

Hmm... I would say we need to figure out the intention behind force temporarily and whether this concept can be mapped to Wayland.

I think the history of this type could be kstart.

In D18494#399327, @graesslin wrote:

Hmm... I would say we need to figure out the intention behind force temporarily and whether this concept can be mapped to Wayland.

As a concept, I think it's still applicable on Wayland, e.g. force the opacity for as long as the window is mapped. Though to be honest I can't imagine any real world usages.

May I ask your advice about implementing rules in ShellClient?

sure!

I currently try to implement Position and Size rules. Would it be feasible to implement them as follows?

• At the start of ShellClient::init, we block requesting geometry;
• When we are about to finish initializing ShellClient, we do something like

void ShellClient::init()
{
    if (!m_internal) {
        blockRequestGeometry(); // Similar to the constructor of RequestGeometryBlocker
    }

    ...

    if (!m_internal) {
        QTimer::singleShot(0, this, &ShellClient::finishInitialization);
    }
}

• When finishInitialization will be called, ShellClient most likely will have all necessary information to match window rules against it, so we can check window rules with init=true in finishInitialization

void ShellClient::finishInitialization()
{
    evaluateWindowRulesInit(); // see D18550

   // Send the configure event.
   unblockRequestGeometry(); // Similar to the destructor of RequestGeometryBlocker
}

(I'm still not quite sure how to apply both rules correctly if a client is mapped back again or if a client changes app id after we send the configure event)

Answer to my question: nope, we should wait until the surface is committed.