This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
20170612_ui_gra_telco_mm_review [2017/06/19 06:22] tmatsuzawa |
20170612_ui_gra_telco_mm_review [2017/06/26 00:48] (current) tmatsuzawa |
||
---|---|---|---|
Line 6: | Line 6: | ||
* Takashi Matsuzawa | * Takashi Matsuzawa | ||
* The document should describe which part of it is mandatory and which parts are optional/selectable (e.g. I understand that 2 windows up/down layout is just one example of OEM profile - though it is very good that we have one example OEM profile and demo homescreen/window manager is written for it.) | * The document should describe which part of it is mandatory and which parts are optional/selectable (e.g. I understand that 2 windows up/down layout is just one example of OEM profile - though it is very good that we have one example OEM profile and demo homescreen/window manager is written for it.) | ||
- | * Regarding the API calls apps make, the document (or manual document) should clarify them into the following two categolies, so that audience can know which part is AGL specific. | + | * Regarding the API calls apps make, the document (or manual document) should clarify them into the following two categories, so that audience can know which part is AGL specific. |
* API calls/actions that ordinal wayand-ivi apps will do (not specific to AGL) | * API calls/actions that ordinal wayand-ivi apps will do (not specific to AGL) | ||
- | * API calls/actinos that are specific to AGL | + | * API calls/actions that are specific to AGL |
* Graphics toolkits (e.g. Qt or others) here are expected to hide such API details from application developers or not, including AGL additions? | * Graphics toolkits (e.g. Qt or others) here are expected to hide such API details from application developers or not, including AGL additions? | ||
+ | |||
+ | * Takashi Matuszawa | ||
+ | * I think the spec should describe what are the concepts that are shown to the end-user and the actions (use-cases) that are provided. And vendors can freely implement their HMIs but providing what the spec specifies. | ||
+ | * e.g. | ||
+ | * HMI should provide following set of applications. | ||
+ | * 1) "all applications" | ||
+ | * 2) "currently running applications" (subset of 1, multiple can exist) | ||
+ | * 3) "currently visible applications" (subset of 2, multiple can exist) | ||
+ | * 4) "currently active application" (subset of 4, only 1 almost can exist) | ||
+ | * And HMI should provide actions as follows | ||
+ | * Show list of all applications, and optionally allow | ||
+ | * Select (make active) one of them. | ||
+ | * Show list of currently running applications, and optionally allow | ||
+ | * Select (make active) one of them. | ||
+ | * Quit one of them. | ||
+ | * Show currently visible applications, and optionally allow | ||
+ | * Select (make active) one of them. | ||
+ | * Quit one of them. | ||
+ | * HMI spec should describe if there are class of applications that needs special treatment and what they are | ||
+ | * e.g. | ||
+ | * Navigation | ||
+ | * Audio | ||
+ | * Rear-camera | ||
+ | * HMI spec should describe common operations (if there are any, as AGL HMI standard feature) | ||
+ | * e.g. | ||
+ | * "back" operation | ||
+ | * Press "back" button | ||
+ | * Swipe screen to right | ||
+ | * (what button/gesture is bound to "back", and how this "back" is interpreted may be implementation specific?) | ||
+ | |||
+ |