Where do we validate surface attributes?
kevin.gunn at canonical.com
Wed Jul 1 16:12:47 UTC 2015
But one question about putting things in client side, can we always assume
that any policy we have can be isolated to a per client attempt to act on
surfaces ? in the instance you might want to have a broader view of the
entire scene being composed (other clients and their surfaces and states),
the server side would be better in that instance. Maybe that's overkill
since i can't think of a good example...
On Wed, Jul 1, 2015 at 8:51 AM, Andreas Pokorny <
andreas.pokorny at canonical.com> wrote:
> On Tue, Jun 30, 2015 at 6:21 PM, Cemil Azizoglu <
> cemil.azizoglu at canonical.com> wrote:
>> Invalid combinations of attributes will generate errors and logged so
>> clients can figure out what they are doing wrong.
>> A problem I see is that this would require clients to be aware of which
>> shell they are running on so they generate attribute settings that conform
>> to that particular shell. That doesn't sounds like a good thing. An
>> application running perfectly on a particular shell may start getting
>> errors on a new shell. Not sure what we can do there. Anybody have ideas?
> This sounds like a good motivation to put the validation inside
> libmirclient, hence make it independent of the mirserver. We currently do
> not intend to make the protocol itself easily extensible. So the the set of
> things to do and configure by a client is limited by libmirclients API.
> Just weakening the requirements of that fixed set of client requests does
> not create playground for freely definable window management concepts. So I
> believe that would end up being a bad compromise. So we should keep
> libmirclient strict, and motivate anyone interested in extending those
> concepts to simply extend libmirclient.
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mir-devel