this sounds like it's all co-operative. since an app itsdelf determines via metadata (manifest) what its purpose is. i assume you could download/replac your reverse camera app with another one, (maybe it's better at guiding you into parking spots?), so in the end it's really up to the developer to identify the class of app.
but an app may have more than one window. one window may play video - another may not. so don't use manifest. use window properties. in x11 it'd be some extended atoms you add indicating window purpose - in wayland, a protocol extension to do that to a surface. the compositor would then decide what gets displayed or hidden based on these properties. the compositor would know/track current state (reversing, moving, still etc.) and enforce this policy. this is the "correct" solution. On 11/27/2014 05:42 PM, Puustinen, Ismo wrote: > Hi Casey, > > In IVI domain the car manufacturers may want to place "regulations" that > limit the applications that can be shown on the screen in different car > use cases. For instance: > > * When the car is moving, applications that play video are not allowed > on the screen. > * When the car is in reverse gear, the application that shows reverse > camera video must be shown on the screen. > * When the car is not moving, all applications are allowed on the > screen. > > You can easily think up a large number of possible use cases such as > these ones. > > It's "easy" to enforce similar audio policies since we have a pretty > good idea who is playing audio to PulseAudio. In order to do such screen > policy enforcement (even in collaborative way, when the application is > announcing it's true capabilities in the manifest file) we have to > somehow know which surface belongs to which application. > > Ismo > > > On Wed, 2014-11-26 at 17:00 +0000, Schaufler, Casey wrote: >> Why does the package name get used to determine if a window gets >> displayed? What policy do you really want to enforce? There has got to >> be a less convoluted way to get what you want than this. >> >> >> >> >> >> From: Dev [mailto:dev-boun...@lists.tizen.org] On Behalf Of Manuel >> Bachmann >> Sent: Wednesday, November 26, 2014 5:10 AM >> To: dev@lists.tizen.org >> Subject: [Dev] [RFC] AUL UI request for multi-process applications >> (ICO/Crosswalk...) >> >> >> >> >> Hi folks, >> >> >> This RFC is about bug TC-1691, TC-159... >> >> >> >> >> >> (The problem happens with Crosswalk today, but it could happen with >> any other application) >> >> >> AUL provide somes function calls, like "aul_app_get_pkgname_bypid >> ()", which permit to get the application package name associated with >> a running PID. >> >> >> Under IVI, the ICO Homescreen (profile/ivi/ico-uxf-homescreen) uses >> these calls to determine if it should show a window, by getting the >> PID of its process, and then comparing it will the package name. If if >> does not match, the window stays hidden. >> >> The problem is : >> >> >> In Crosswalk, the process which creates the window (the GPU process) >> is *not* the same that the one (the browser process) which registers >> itself as a Tizen application. >> >> >> Crosswalk has a dedicated process for UI operations, which is >> different of the one that does the application logic. >> So, the name is never found, and Web applications never show. >> >> >> >> >> >> In this respect, we need a way for an application to "pass" its >> application identifier to the graphical layer (in this case, ICO).Here >> are 2 options : >> >> 1) in Crosswalk itself, have a package name passed from application >> layer to the UI/GPU one (won't probably be upstream). Then, have a >> Weston plugin "receive" and store the information. When requested by >> the "aul_app_get_pkgname_bypid ()" call, AUL will also request the >> plugin for this information and respond. >> >> >> Requires modifications in : 3 packages (crosswalk, weston, aul-1) >> >> >> >> >> >> 2) in Crosswalk itself, have a package name passed from application >> layer to the UI/GPU one (won't probably be upstream). Then, store this >> data in a local database or specific tmpfs. When requested by the >> "aul_app_get_pkgname_bypid ()" call, AUL will also request this base >> or tmpfs for this information and respond. >> >> >> Requires modification in : 2 packages (crosswalk, aul-1) >> >> >> >> >> >> The 2nd idea modifies less packages but may be trickier to implement. >> Any opinion on this ? >> >> >> >> >> -- >> >> Regards, >> >> Manuel BACHMANN >> Tizen Project >> VANNES-FR >> >> >> _______________________________________________ >> Dev mailing list >> Dev@lists.tizen.org >> https://lists.tizen.org/listinfo/dev > _______________________________________________ > Dev mailing list > Dev@lists.tizen.org > https://lists.tizen.org/listinfo/dev > -- The above message is intended solely for the named addressee and may contain trade secret, industrial technology or privileged and confidential information otherwise protected under applicable law including the Unfair Competition Prevention and Trade Secret Protection Act. Any unauthorized dissemination, distribution, copying or use of the information contained in this communication is strictly prohibited. If you have received this communication in error, please notify the sender by email and delete this communication immediately.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
