the new surface type get/set for client api looks ok to me
The acceptance test takes quite a while on the galaxy nexus, perhaps it can be shortened by using less iterations in line 757?
[ RUN ] DefaultDisplayServerTestFixture.surface_types
[ OK ] DefaultDisplayServerTestFixture.surface_types (1384 ms)
(i see about 180ms on my desktop)
small nit but with
615 +int ms::Surface::configure(MirSurfaceAttrib attrib, int value)
the name 'configure' didn't make it obvious what is going on in the function.
Also with this function, (related to the comment in it) is the surface type something that mir cares about, or the shell? This is tricky to talk about without a 'shell api', but its still a bit hazy to me what our requirements for tracking the data that the shell cares about.
although the tests look good, they do have multiple testing expectations in them because they are long.
the new surface type get/set for client api looks ok to me
The acceptance test takes quite a while on the galaxy nexus, perhaps it can be shortened by using less iterations in line 757? erverTestFixtur e.surface_ types erverTestFixtur e.surface_ types (1384 ms)
[ RUN ] DefaultDisplayS
[ OK ] DefaultDisplayS
(i see about 180ms on my desktop)
small nit but with :configure( MirSurfaceAttri b attrib, int value)
615 +int ms::Surface:
the name 'configure' didn't make it obvious what is going on in the function.
Also with this function, (related to the comment in it) is the surface type something that mir cares about, or the shell? This is tricky to talk about without a 'shell api', but its still a bit hazy to me what our requirements for tracking the data that the shell cares about.
although the tests look good, they do have multiple testing expectations in them because they are long.