And legal issues? A lot of online services do have a definition of a phone.
Like streaming services. Music share holders have other arrangements for a
phone and a desktop. (Even tho I think it's wrong)
I don't know what there definition of a phone is, but apps like Deezer will
have to follow them.
> Op 11 jan. 2016 22:51 schreef "Peter Bittner" <peter.bitt...@gmx.net>:
>
>> *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.
>>
>> Peter
>>
>>
>> 2016-01-11 21:57 GMT+01:00 Stephen M. Webb <stephen.w...@canonical.com>:
>> > 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.w...@canonical.com>
>>
>> --
>> Mailing list: https://launchpad.net/~ubuntu-phone
>> Post to : ubuntu-phone@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~ubuntu-phone
>> More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
