Merge lp:~alan-griffiths/mir/more-surface-resize into lp:mir
| Status: | Merged |
|---|---|
| Approved by: | Alan Griffiths on 2015-04-29 |
| Approved revision: | 2526 |
| Merged at revision: | 2523 |
| Proposed branch: | lp:~alan-griffiths/mir/more-surface-resize |
| Merge into: | lp:mir |
| Diff against target: |
1181 lines (+634/-172) 14 files modified
examples/server_example_canonical_window_manager.cpp (+115/-58) examples/server_example_canonical_window_manager.h (+6/-2) include/client/mir_toolkit/mir_surface.h (+53/-0) include/server/mir/scene/surface_creation_parameters.h (+5/-0) include/server/mir/shell/surface_specification.h (+6/-0) src/client/mir_surface.cpp (+34/-0) src/client/mir_surface.h (+6/-0) src/client/mir_surface_api.cpp (+48/-0) src/client/symbols.map (+6/-2) src/protobuf/mir_protobuf.proto (+14/-0) src/server/frontend/session_mediator.cpp (+26/-0) src/server/shell/canonical_window_manager.cpp (+115/-55) src/server/shell/canonical_window_manager.h (+6/-2) tests/acceptance-tests/test_surface_modifications.cpp (+194/-53) |
| To merge this branch: | bzr merge lp:~alan-griffiths/mir/more-surface-resize |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| PS Jenkins bot | continuous-integration | Approve on 2015-04-28 | |
| Alexandros Frantzis (community) | Approve on 2015-04-28 | ||
| Kevin DuBois (community) | Approve on 2015-04-28 | ||
| Alan Griffiths | Abstain on 2015-04-28 | ||
| Alberto Aguirre | 2015-04-21 | Approve on 2015-04-27 | |
| Andreas Pokorny (community) | Approve on 2015-04-27 | ||
| Daniel van Vugt | Needs Fixing on 2015-04-24 | ||
|
Review via email:
|
|||
Commit Message
shell: handle size increments and aspect ratios
Description of the Change
shell: handle size increments and aspect ratios
| Daniel van Vugt (vanvugt) wrote : | # |
This seems a bit odd and smells fishy:
examples/
Why any change to examples? The policy and logic for resize constraints should be entirely in src/server/. Nothing should need to be implemented by consumers of CanonicalWindow
The default policy should just use best fit and modify any requested dimensions so that they satisfy the constraints. For example:
* Policy is 16:9 aspect ratio and shell tries to set 80x80 -> new size is 80x45
* Policy is increments of 8x16 (a terminal) and shell tries to set 812x323 -> new size is 808x320 or 816x336 (depending on the previous dimensions and direction of resize).
So the goal is policy enforcement with the simplest interface possible, which is no code change required to any shell.
| Alan Griffiths (alan-griffiths) wrote : | # |
The changes to examples are because the team decided that me::CanonicalWi
| Daniel van Vugt (vanvugt) wrote : | # |
(1) Setting aspect ratio the user usually just wants it fixed (video players) or completely free (say zeros). So it would ease usability if these were a single function with five parameters:
458 +bool mir_surface_
470 +bool mir_surface_
Similarly, when you set the resize granularity, it should be a single function instead of two:
236 +bool mir_surface_
249 +bool mir_surface_
Arguably all the resize constraints should be bundled into a single structure, but I think that would contradict the new design too much.
| Alan Griffiths (alan-griffiths) wrote : | # |
*Needs Discussion*
> (1) Setting aspect ratio the user usually just wants it fixed (video players)
> or completely free (say zeros). So it would ease usability if these were a
> single function with five parameters:
>
> 458 +bool mir_surface_
> unsigned x, unsigned y)
> 470 +bool mir_surface_
> unsigned x, unsigned y)
>
> Similarly, when you set the resize granularity, it should be a single function
> instead of two:
>
> 236 +bool mir_surface_
> width_inc);
> 249 +bool mir_surface_
> height_inc);
>
> Arguably all the resize constraints should be bundled into a single structure,
> but I think that would contradict the new design too much.
I'm not a fan of interfaces that use "magic values" (say zeros) but will go with what the majority prefers.
- 2514. By Alan Griffiths on 2015-04-27
-
merge lp:mir
| Andreas Pokorny (andreas-pokorny) wrote : | # |
Nit: + 240 s/hight/height
Maintaining ABI compatibility of caller stored structures seems harder than having separate functions. Given the use cases I can think of right now, most clients might only use the width/height increment functions or the aspect ration functions. Hence those could be combined to single functions. Then again most of the existing setter 'methods' are unary.
- 2515. By Alan Griffiths on 2015-04-27
-
Nitfix
| Kevin DuBois (kdub) wrote : | # |
I have a slight preference for more a well-defined functions in the api as opposed to one function that rolls a lot of tasks in.
I'd be okay with the api as-is, or reducing to 3 new functions seems good to me as well:
mir_surface_
mir_surface_
mir_surface_
needs-info:
Do we need a way to reset the width_inc/
| Alan Griffiths (alan-griffiths) wrote : | # |
> I have a slight preference for more a well-defined functions in the api as
> opposed to one function that rolls a lot of tasks in.
> I'd be okay with the api as-is, or reducing to 3 new functions seems good to
> me as well:
> mir_surface_
> mir_surface_
> mir_surface_
I think this needs to be consistent. If we take this approach we should also merge:
mir_surface_
mir_surface_
> needs-info:
> Do we need a way to reset the width_inc/
Good question!
One that should also apply to [min|max]
| Alberto Aguirre (albaguirre) wrote : | # |
I think the 4 apis are just fine. It's just a surface spec, so the value are not in flight until it's commited.
Having them separate is consistent with other existing API's ( set_width and set_height, etc.)
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2514
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Alan Griffiths (alan-griffiths) wrote : | # |
I think the majority view is that this API is fine.
~~~~
But we may need another MP to add a bunch of "reset" functions for surface properties that can be set.
Or, alternatively, have some values that give default behavior:
mir_surface_
mir_surface_
mir_surface_
etc.
| Gerry Boland (gerboland) wrote : | # |
As outside perspective, I like this api. I modify the MirSurfaceSpec one property at a time, and know if each modification was allowed or not. When ready, commit.
While on that subject, is there a possibility of a race between me calling mir_surface_
Nitpick:
Mir never shied away from long descriptive function names. Why abbreviate "increment" to "inc"? My first guess for the meaning of "inc" is not increment.
| Alan Griffiths (alan-griffiths) wrote : | # |
> As outside perspective, I like this api. I modify the MirSurfaceSpec one
> property at a time, and know if each modification was allowed or not. When
> ready, commit.
>
> While on that subject, is there a possibility of a race between me calling
> mir_surface_
> and the client changing those values?
Well, by definition, that is a race. What will happen is that the server will handle the requests in some order. The resulting surface size could depend upon the order.
> Nitpick:
> Mir never shied away from long descriptive function names. Why abbreviate
> "increment" to "inc"? My first guess for the meaning of "inc" is not
> increment.
Fair. I'll fix.
- 2516. By Alan Griffiths on 2015-04-27
-
Don't abbreviate increment in function names
| Kevin DuBois (kdub) wrote : | # |
> But we may need another MP to add a bunch of "reset" functions for surface
> properties that can be set.
So, after the discussion today, I think that its something we might need, but could come once the need arises.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2515
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Alan Griffiths (alan-griffiths) wrote : | # |
101: [ RUN ] AndroidInputRec
101: /mir/tests/
101: Expected: (duration) > (1ms), actual: 8-byte object <C7-2B 0F-00 00-00 00-00> vs 8-byte object <01-00 00-00 00-00 00-00>
101: [ FAILED ] AndroidInputRec
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2516
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Kevin DuBois (kdub) wrote : | # |
needs-fixings:
122+ auto const error = new_size.
c-cast
264+ * \param [in] x numerator
265+ * \param [in] y denominator
Its obvious from context that the ratio is x/y, but might make it clearer that that the ratio is x/y (and also if the ratio gets affected by 90 degree rotation requests)
around l383, should we check that the min aspect ratio is less than the max?
227+ * Defines an arithmetic progression of sizes starting with min_width (if set, otherwise 0)
would a default of 1 be better? That way the server wouldn't be stepping over the clients default of 0 by default. (zero seems to be a request to fix the surface size to min_width, min_height)
| Alexandros Frantzis (afrantzis) wrote : | # |
267 + * \note The requested aspect ration is a hint only. The server is not guaranteed
279 + * \note The requested aspect ration is a hint only. The server is not guaranteed
408+ struct AspectRation { unsigned x; unsigned y; };
Typo 'ration'.
261+ * Set the minimum aspect ratio
262+ *
263+ * \param [in] spec Specification to mutate
264+ * \param [in] x numerator
265+ * \param [in] y denominator
I think it would be clearer to express the aspect ratio in terms of width and height, not x and y.
715+ auto const error = new_size.
716+
717+ if (error > 0)
Should this be the other way around?
error > 0 => W*y-H*x > 0 => W/H > x/y => the new aspect ratio is larger than the min aspect ratio so we shouldn't need to touch the W,H values, or am I misunderstanding what "min aspect ratio" means?
Needs fixing/info
- 2517. By Alan Griffiths on 2015-04-28
-
Renames for typos and clarity
- 2518. By Alan Griffiths on 2015-04-28
-
Another pass of x => width, y => height
- 2519. By Alan Griffiths on 2015-04-28
-
Another pass of x => width, y => height
- 2520. By Alan Griffiths on 2015-04-28
-
Final pass of x => width, y => height
- 2521. By Alan Griffiths on 2015-04-28
-
No C-stype casts
- 2522. By Alan Griffiths on 2015-04-28
-
Fix interpretation of aspect ratio (with a clearer test expectation)
- 2523. By Alan Griffiths on 2015-04-28
-
merge lp:mir
| Alan Griffiths (alan-griffiths) wrote : | # |
> 267 + * \note The requested aspect ration is a hint only. The server is
> not guaranteed
> 279 + * \note The requested aspect ration is a hint only. The server is
> not guaranteed
>
> 408+ struct AspectRation { unsigned x; unsigned y; };
>
> Typo 'ration'.
>
> 261+ * Set the minimum aspect ratio
> 262+ *
> 263+ * \param [in] spec Specification to mutate
> 264+ * \param [in] x numerator
> 265+ * \param [in] y denominator
>
> I think it would be clearer to express the aspect ratio in terms of width and
> height, not x and y.
>
> 715+ auto const error = new_size.
> new_size.
> 716+
> 717+ if (error > 0)
>
> Should this be the other way around?
>
> error > 0 => W*y-H*x > 0 => W/H > x/y => the new aspect ratio is larger than
> the min aspect ratio so we shouldn't need to touch the W,H values, or am I
> misunderstanding what "min aspect ratio" means?
>
> Needs fixing/info
fixed
| Alan Griffiths (alan-griffiths) wrote : | # |
> needs-fixings:
> 122+ auto const error = new_size.
> new_size.
> c-cast
fixed
> 264+ * \param [in] x numerator
> 265+ * \param [in] y denominator
> Its obvious from context that the ratio is x/y, but might make it clearer that
> that the ratio is x/y (and also if the ratio gets affected by 90 degree
> rotation requests)
I'm not clear what this is asking for.
> around l383, should we check that the min aspect ratio is less than the max?
We could, but would we handle it any differently?
> 227+ * Defines an arithmetic progression of sizes starting with min_width (if
> set, otherwise 0)
> would a default of 1 be better?
I don't follow. If min_width isn't set the series is:
0, width_inc, 2*width_inc, ...
You're suggesting this:
1, 1+width_inc, 1+2*width_inc, ...
> That way the server wouldn't be stepping over
> the clients default of 0 by default. (zero seems to be a request to fix the
> surface size to min_width, min_height)
And I don't follow this.
| Alexandros Frantzis (afrantzis) wrote : | # |
122+ auto const error = new_size.
123+
124+ if (error > 0)
125+ {
126+ if (new_size.
127+ {
128+ new_size.width = new_size.width + DeltaX(
129+ }
130+ else
131+ {
132+ new_size.height = new_size.height - DeltaY(
133+ }
134+ }
Some questions (Aw=aspect W, Ah=aspect H):
1. In this case, since W/H < Aw/Ah, we can either increase W or decrease H to increase the ratio, as is done in the two branches of the if statement. What's the rationale behind using the relation between W and H to decide whether to change W or H?
2. What's the logic behind the formula in DeltaX (and DeltaY respectively)? If we want W/H to reach Aw/Ah we could increase W by error/Ah, so it's not clear why we need the other terms (the proposed formula leads to an increase of error/Ah + 1 + 1/Ah).
It would be good to add a comment documenting how the proposed computations and decisions work.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2523
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Kevin DuBois (kdub) wrote : | # |
> > 227+ * Defines an arithmetic progression of sizes starting with min_width
> (if
> > set, otherwise 0)
> > would a default of 1 be better?
>
> I don't follow. If min_width isn't set the series is:
>
> 0, width_inc, 2*width_inc, ...
>
> You're suggesting this:
>
> 1, 1+width_inc, 1+2*width_inc, ...
>
> > That way the server wouldn't be stepping over
> > the clients default of 0 by default. (zero seems to be a request to fix the
> > surface size to min_width, min_height)
>
> And I don't follow this.
So, I was suggesting that min_width is always set and gives the sequence:
min_width, min_width + 1*width_inc, min_width + 2*width_inc, etc
And, with that 1 would be a good default value, because then you get:
min_width, min_width+1, min_width+2, etc.
effectively, saying that the server can resize to any width and still fit within the client's setting.
If min_width is set to zero, then the client's sequence is:
min_width, min_width, min_width, etc...
and the client requests no server resizes.
| Kevin DuBois (kdub) wrote : | # |
> > 264+ * \param [in] x numerator
> > 265+ * \param [in] y denominator
> > Its obvious from context that the ratio is x/y, but might make it clearer
> that
> > that the ratio is x/y (and also if the ratio gets affected by 90 degree
> > rotation requests)
>
> I'm not clear what this is asking for.
Just some more comments in the vein of:
261+ * Set the minimum aspect ratio
to
* Set the minimum aspect ratio. Aspect ratio is defined as the ratio of the x direction over
* the y direction. Aspect ratio is not inverted/affected by mir_surface_
(or how the ratio is treated if its rotated 90/270 degrees)
| Alan Griffiths (alan-griffiths) wrote : | # |
> Some questions (Aw=aspect W, Ah=aspect H):
>
> 1. In this case, since W/H < Aw/Ah, we can either increase W or decrease H to
> increase the ratio, as is done in the two branches of the if statement. What's
> the rationale behind using the relation between W and H to decide whether to
> change W or H?
I admit it is arbitrary. And now I examine it, probably wrong.
My (misguided) thought was that changing the smaller one leads to a bigger effect on the ratio for a smaller change. But suppose we want a ratio of 10:1, but have 10:20. Then my approach leads to 200:20 when 10:2 would probably be better.
> 2. What's the logic behind the formula in DeltaX (and DeltaY respectively)? If
> we want W/H to reach Aw/Ah we could increase W by error/Ah, so it's not clear
> why we need the other terms (the proposed formula leads to an increase of
> error/Ah + 1 + 1/Ah).
It's to ensure rounding up. (I didn't think common incantation in integer arithmetic needed explaining - I was wrong.)
> It would be good to add a comment documenting how the proposed computations
> and decisions work.
And even better to get it right. ;)
| Alexandros Frantzis (afrantzis) wrote : | # |
> It's to ensure rounding up. (I didn't think common incantation in integer arithmetic needed explaining - I was wrong.)
Yes, this will benefit from being more explicit (I missed it even though I have used/implemented it in the past [1]).
[1] src/platforms/
| Alan Griffiths (alan-griffiths) wrote : | # |
> > > 227+ * Defines an arithmetic progression of sizes starting with min_width
> > (if
> > > set, otherwise 0)
> > > would a default of 1 be better?
> >
> > I don't follow. If min_width isn't set the series is:
> >
> > 0, width_inc, 2*width_inc, ...
> >
> > You're suggesting this:
> >
> > 1, 1+width_inc, 1+2*width_inc, ...
> >
> > > That way the server wouldn't be stepping over
> > > the clients default of 0 by default. (zero seems to be a request to fix
> the
> > > surface size to min_width, min_height)
> >
> > And I don't follow this.
>
> So, I was suggesting that min_width is always set and gives the sequence:
> min_width, min_width + 1*width_inc, min_width + 2*width_inc, etc
> And, with that 1 would be a good default value, because then you get:
> min_width, min_width+1, min_width+2, etc.
OK, I think you're writing "*min_width* is always set" when you're suggesting a default for *width_inc*.
So, we're actually talking about the same behavior except, possibly, in cases where the client applies a spec to a surface that has previously had width_inc set:
What we have is a surface spec where width_inc is optional and only if that is set by the client will it update the width_inc on the server.
Are you suggesting that the surface spec should always have a width_inc (default 1) and that this should override the server setting if not set by the client? I don't think that is right.
- 2524. By Alan Griffiths on 2015-04-28
-
Better clearer min/max size logic
- 2525. By Alan Griffiths on 2015-04-28
-
Better clearer min/max aspect ratio doc comments
- 2526. By Alan Griffiths on 2015-04-28
-
merge lp:mir
| Alan Griffiths (alan-griffiths) wrote : | # |
> And even better to get it right. ;)
fixed
| Kevin DuBois (kdub) wrote : | # |
cleared up my confusion over irc (re the width_inc, height_inc), lgtm
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2526
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Daniel van Vugt (vanvugt) wrote : | # |
(1) Still not a fan of the extraneous functions and longer names. And "inc" is better than "increment" because the former is actually more common in programming circles and less likely to take you off the edge of the screen when typing.
(2) Does anyone know why having two aspect ratios is useful? I know X has it, but why? In my experience in building toolkits only two options (one ratio) are useful:
(a) Fixed aspect ratio (e.g. video player); or
(b) No fixed aspect ratio (although the toolkit will feed back and modify the min/max dimensions according to how well its widgets fit, that's not an aspect thing).
| Alan Griffiths (alan-griffiths) wrote : | # |
> (1) Still not a fan of the extraneous functions and longer names. And "inc" is
> better than "increment" because the former is actually more common in
> programming circles and less likely to take you off the edge of the screen
> when typing.
"Do not use abbreviations unless they are extremely well known outside your project"
http://
It is a fine line - "min" and "max" have been accepted as common abbreviations whereas "inc" isn't common enough.
> (2) Does anyone know why having two aspect ratios is useful? I know X has it,
> but why? In my experience in building toolkits only two options (one ratio)
> are useful:
> (a) Fixed aspect ratio (e.g. video player); or
> (b) No fixed aspect ratio (although the toolkit will feed back and modify
> the min/max dimensions according to how well its widgets fit, that's not an
> aspect thing).
No, but following established practice in the domain seems prudent.

PASSED: Continuous integration, rev:2513 jenkins. qa.ubuntu. com/job/ mir-ci/ 3576/ jenkins. qa.ubuntu. com/job/ mir-android- vivid-i386- build/2131 jenkins. qa.ubuntu. com/job/ mir-clang- vivid-amd64- build/2130 jenkins. qa.ubuntu. com/job/ mir-mediumtests -vivid- touch/2081 jenkins. qa.ubuntu. com/job/ mir-vivid- amd64-ci/ 1573 jenkins. qa.ubuntu. com/job/ mir-vivid- amd64-ci/ 1573/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 2081 jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 2081/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ mir-mediumtests -runner- mako/5011 s-jenkins. ubuntu- ci:8080/ job/touch- flash-device/ 19824
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/mir- ci/3576/ rebuild
http://