Change Details

There are rules that have to be applied only once, e.g. every Remember and Apply Initially rule, as well any rule that involves configuring the client. In the best scenario the compositor would evaluate such rules when the client is about to be mapped. This change limits window rules only to xdg-shell clients because right now only this protocol lets compositors intervene in the client initialization process. Also, it makes things a bit easier for us on the compositor side. Though not all issues are addressed with xdg-shell protocol. There is no way for a client to express its intent to be mapped. Thus if a client is mapped more than once, then the compositor won't be able to re-evaluate remember rules for example. In order to make this work we need changes in the protocol.

There are rules that have to be applied only once, e.g. every Remember and Apply Initially rule, as well rules that need to configure the client, e.g. size, etc. In the best scenario the compositor would evaluate such rules when the client is about to be mapped. This change limits window rules only to xdg-shell clients because right now only this protocol lets compositors intervene in the client initialization process. Also, it makes things a bit easier for us on the compositor side. Even though xdg-shell satisfies most of ours requirements to implement window rules, it's still not perfect. For example, if the client is about to be mapped for the second time, the compositor needs somehow to configure it, otherwise the next frame may be not "perfect".

There are rules that have to be applied only once, e.g. every Remember and Apply Initially rule, as well any rules that involvesneed to configuringe the client, the cliente.g. size, etc. In the best scenario the compositor would evaluate such rules rules when the client is about to be mapped. This change limits window rules only to xdg-shell clients because right now only this protocol lets compositors intervene in the client initialization process. Also, it makes things a bit easier for us on the compositor side. Though not all issues are addressed with xdg-shell protocol. There is no way for a client to express its intent to be mapped. Thus if a client isEven though xdg-shell satisfies most of ours requirements to implement mapped more than oncewindow rules, it's still not perfect. For example, thenif the compositor won't be ablelient is about to re-evaluatebe remember rules for example.mapped for the second time, In order to make this work we need changesthe compositor needs somehow to configure in the protocolit, otherwise the next frame may be not "perfect".