ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

On 11.01.2016 22:50, Peter Bittner wrote:
> *applaud*
> 
> Very nice post, Stephen. Thank you.
> 
> [ What I am wondering is (maybe that was already mentioned in the
> myriad of messages) what the programming API will look like ("... app
> may need to know its display surface has changed size"). Is there a
> spec or draft spec somewhere already? ]
> 
> The problem that a few of us, all smart programmers, probably have: Is
> it really all about "what is the size of the display surface" that
> defines the "form factor" and decides whether window decorations are
> to be used, or a mouse pointer is shown, etc.? (--> I fear *this* is
> the "is it desktop, tablet or smartphone?" question.) -- Probably the
> API will (have to) tell the app what "form factor" the system decided
> to use for the app, in addition to the display surface dimensions
> passed to the app.
> 
> In other words: Switching back and forth from whatever behavior the
> display device is inducing, is the operating system's business and the
> app shall sit there patient and wait for being notified. It shall be
> none of the app's business to sniff around for information and
> understand when to change appearance. I think this is also important
> in order to have a coherent behavior (and simpler source code!) of all
> the apps.
> 
> tl;dr -- The operating system (window manager?) shall decide how the
> apps are expected to present themselves. Apps should not try to do
> that, they shall wait for being notified about that their appearance
> changed.


IMO the app should not switch anything (with some *very* rare exceptions
I guess). It gets a surface assigned where it can render to, and it will
get input from different devices. Those input devices are not mutually
exclusive. A tablet won't lose its touch capabilities just because a
Bluetooth mouse is connected. If you make all ui elements tiny just
because a mouse is connected, you break the users touch screen. The user
should able to choose if he'd rather tap on something or use the mouse
to click on it, not the developer. The app's ui should work just fine
any of them at any point in time.

The chosen layout (as example, 1 column vs 2 column layout) should
really be dependent of the available space. There is no reason to choose
a 1 vs 2 column layout based on available input devices, the presence of
an accelerometer or whatever else.

If we're talking about the example of a TV where the user is much
further away from the display, the shell would change the DPI (or rather
pixels per grid unit in our case) which would all the app's content
caused to be painted bigger. Still we can't make any assumptions on the
input stuff. The user could have Bluetooth mouse connected or also
something like a Wii controller, which kinda behaves like a touch screen
again. The increase of px/gu would cause the app's overall available
surface space to shrink, which is where the decision for 1 vs 2 column
layout can be made again.

So IMO it's really only about presenting things on different surface
sizes and testing the complete app with a mouse/keyboard *and* with
touch/OSK.


> 
> Peter
> 
> 
> 2016-01-11 21:57 GMT+01:00 Stephen M. Webb <stephen.webb@xxxxxxxxxxxxx>:
>> On 16-01-11 03:08 PM, Lorn Potter wrote:
>>>
>>>
>>> On 12/01/16 05:35, Robert Park wrote:
>>>> But the point is that you can't have coffee that says "if desktop: x; if
>>>> phone: y" because it can change at any time and you can't rely on that.
>>>
>>> Yes this desktop/phablet mode thing would be dynamic. It can change at any time, which is why it needs to be detected
>>> dynamically.
>>
>> Input and output devices may appear or disappear dynamically.  They may change other properties dynamically (keyboard
>> layout, display size or resolution). None of those is a "system mode".  Yes, they are things that applications need to
>> adjust for.  That has been the case for a number of years already on the desktop and does not requires a "system mode."
>>
>>> When you connect bt keyboard & external display, phone is now in desktop mode. When you flip back your laptop's
>>> touchscreen, it's it now phablet mode. It already does the first one except there is no API to let developers know for
>>> certain what mode it is in.
>>
>> When you connect an external keyboard, you now have an external keyboard.  Unless you are writing a keyboard
>> configuration settings app, there is usually no reason for an application to be aware of how many keyboards I have
>> connected.  The shell may need to know, so it can display the OSK or not as appropriate (configurably).  Apps shouldn't
>> normally be aware of changes to keyboard layout or IM selection either.  An argument can be made that an application may
>> need to know certain kinds of input devices are present and adapt accordingly:  a game controller is not a mouse and
>> vice versa, a drawing tablet and a mouse are not the same, and so on.  That's not a desktop vs. phone thing, it's a
>> feature detection thing.
>>
>> When you connect an external display, the shell needs to know.  It may choose to enter windowed mode (or it may not,
>> depending on configuration).  The app may need to know its display surface has changed size.  Neither of those is a
>> desktop/phone mode thing and apps should not go around acting like they're on a desktop just because I'm cloning my
>> phone to a projector for a presentation.  It's not a desktop vs. phone thing, it's a feature detection thing.
>>
>> When connecting external monitors, if the hardware supports it, I want to be able to run some apps on the phone display
>> as if they were on a phone display and on the external monitors using a windowed display as if they're on a desktop
>> screen, and I want to run them both at the same time.  Is my phone in desktop mode or phone mode when I do that?
>>
>>>> **MUCH** better user experience if you do feature detection, eg "if
>>>> push_notifications_available: enable_push_notifications()", this way
>>>> they work everywhere they exist, rather than trying to guess whether or
>>>> not they exist by making assumptions about what is a "phone" vs what is
>>>> a "desktop".
>>>
>>> It really depends on what you are doing.
>>
>> What would you be doing where a feature availability check would not do the right thing every time?
>>
>>> We can either provide an API to do so or developers will try and guess these things on their own.
>>
>> We can't stop developers from writing crappy software.  What we can do is not aid and abet them.
>>
>> We need APIs for feature detection.  Apps need feature detection.  Apps don't need "system mode" detection.  We don't
>> want apps to have "system mode" detection because we don't want to have a "system mode."
>>
>> --
>> Stephen M. Webb  <stephen.webb@xxxxxxxxxxxxx>
>

Attachment: signature.asc
Description: OpenPGP digital signature