[dialer app] + [window management] movement on screen in window mode

[kevin gunn]

somewhat related to bug 1488852

so the dialer app is currently treated like any other window in terms of movement, you can move the dialer app to the point where the dialer application window is not seen "hanging of the screen" so only the title bar of the application is visible.
Also, if the device reboots, this will be the remembered location of the window.

Concern was that the user might move offscreen and struggle to find it quickly for "ending call" or entering numbers at a prompt or changing from loudspeaker to earpiece or wanting to hit mute.

It was discussed whether or not the dialer application should become a "special" application/surface to disallow having any portion of the window being moved offscreen ? Or is this completely ok - e.g. the user wanted to do it and should be allowed to.
Or should the green banner of the dialer app in the shell be used to bring the dialer app back on screen ?

[Olga Kemmet (olga-kemmet)]

@kevin:
I had a chat with Matthew who is working on the MIR spec. One of the suggestions I had was to reposition the windows after a reboot. The ideal case would be to show the full window to the user, positioned as close as possible to its previous "off-screen" position. Many people, myself included, close and re-open apps because a window was moved too far out of view. In most cases this window is displayed fully on screen, close to the previous position.

That might solve part of the problem, at least after a reboot of the device. The indicator issue is part of an other bug, as mentioned above.

[Matthew Paul Thomas (mpt)]

Per spec, Mir will require that every window have a minimum amount of width+height on-screen. Currently there's no allowance for apps to keep a window *entirely* on-screen, and nor is there any larger minimum width+height when relaunching an app.

But even if there was, that wouldn't solve this problem at all. While a call is in progress, another window might open in front of it; you might minimize it; or you might move it to another workspace, and then switch back to the previous workspace. So there are several ways that the call window could be invisible while the call is in progress.

You could reduce this by setting the call window as a floating regular window, so that it floats on top of most other windows. (But that would be impractical if the app ever allowed screen sharing.) Or you could just rely on the Launcher, switcher, or call banner to return to the app.

[kevin gunn (kgunn72)]

the dialer app is special in this case - i can't think of any other app that has a special visual shell effect like the "green call banner"
What if the "green call banner" were always to activate in the instance the phone window has any pixels offscreen or occluded by another window? clicking or touching on the green banner in windowed mode could result in a consistent placement of the dialer app window (e.g. upper left corner or lower right corner)

does this seem like a reasonable approach?

[Olga Kemmet (olga-kemmet)]

@kevin:
I think this is a very reasonable approach, we just need to figure out how to deal with the indicators. There seem to be an issue in therms of click & touch interactions.
Just to clarify: the dialer will come back into view every time user clicks or taps on the indicators. I would say ideally in full screen mode, or the minimum mode one needs to interact with all controls.
Would it be possible to always centre the dialer window?