HI Tanibata-San, "Please let me know your ideas; It is acceptable by community? Ivi-shell supports ivi-application.xml and some parts of xdg-shell.xml?"
On my side, it looks totally acceptable. As Janos suggests, maybe it should just be a compile-time option (such as "--enable-xdg-shell-compatibility", or something like this). Regards, Manuel 2014-09-16 1:56 GMT+02:00 Tanibata, Nobuhiko (ADITJ/SWG) < [email protected]>: > Hi Manuel-san and Dominig-san, > > "If community allows us to support multiple shell in one compositor and > xdg-shell became standard shell in Weston, I can support fall back feature > to xdg_shell when client doesn't support ivi-application. In this case, > get_xdg_surface and other main protocol can be supported." > > >That would be great ! Thanks a lot for your proposal. (regarding upstream > XDG-Shell, it is supposed to be totally stabilized in Weston 1.7. I > effectively have read messages were it was said that xdg-shell would > replace wl_shell someday ; the current pro is that it has a lot more > features). > > Please let me know your ideas; It is acceptable by community? Ivi-shell > supports ivi-application.xml and some parts of xdg-shell.xml? > > BR, > Nobuhiko Tanibata > > > From: Manuel Bachmann [mailto:[email protected]] > Sent: Monday, September 15, 2014 8:49 PM > To: Tanibata, Nobuhiko (ADITJ/SWG) > Cc: Counihan, Tom; Dominig ar Foll (Intel OTC); [email protected]; > Ishikawa, Tetsuri (ADITJ/SWG) > Subject: Re: [RFC] IVI-Shell, Wayland, and middleware API unification > > Hi Janos, Tanibata-San, and thanks for your very detailed responses ! > > Janos, > > "In the ICO paradigm applications should not be able to show themselves, > get on the top, or go full-size unconditionally, without the approval of > the managing authority, ie. the HomeScreen /system-controller. > From this respect executing those request unconditionally in IVI shell > does not appear to be very wise. Those request should be forwarded to the > managing authority for consideration rather than execute them > unconditionally. The ivi-controller interface is quite suitable for this." > > "do not implement any hardwired policies for the wl- and xdg-shell calls, > eg. map the xdg_surface_set_minimized => ivi_layout_surfaceSetVisibility, > deliver the requests to the managing authority over ivi-controller > interface." > > Thanks to your answer, I think I understand ; and this explains better the > separation between the "ivi-shell" and "ivi-layout" modules. > The map call of "xdg_surface_set_minimized()" was arbitray on my part, and > could very well be delivered to ivi-controller component as you describe. I > will take a look at it ; until then, I just disabled the call in my code > base. > > "convince upstream folks about the multiple shell support (once it has > been already there but it was removed). If GENIVI folks do not want it we > could make the wl- and/or xdg-shell support as compile-time option." > > Sure, a flag such as "--enable-xdg-shell" or "--enable-xdg-wrapper" could > easily be implemented. I also get the feeling that this would help ICO > integration in the future (because if I understand correctly, wl_shell > support in only in the Tizen repository currently ; having a fallback shell > upstream would reduce the delta). But Tanibata-San, who develops and > maintains IVI-Shell, may also have an opinion on this :-). > > Tanibata-San, > > " - If xdg-shell support, I would be great to merge them into one. > - ivi-application.surface_create(ivi_id,surface) to map ID with > wl_surface > - allow to load ivi-layout module to add ivi-features. > - security model not to allow client application to use a part of > xdg-shell protocol; interface to control e.g. position/size like > xdg_surface_set_minimized. > - In the future, ivi-controller shall be bound by only authorized > manager like murphy or else. This is one of suggestion from Intel graphic > engineer you may know." > > Such a model may be elegant but also complicated for a first step. > Regardind ivi-controller and murphy, I will take a look at it. > > "If community allows us to support multiple shell in one compositor and > xdg-shell became standard shell in Weston, I can support fall back feature > to xdg_shell when client doesn't support ivi-application. In this case, > get_xdg_surface and other main protocol can be supported." > > That would be great ! Thanks a lot for your proposal. (regarding upstream > XDG-Shell, it is supposed to be totally stabilized in Weston 1.7. I > effectively have read messages were it was said that xdg-shell would > replace wl_shell someday ; the current pro is that it has a lot more > features). > > "But other interface to control position or resize of the shell surface > shall not be supported because of security reason e.g. application can > control." > > I totally understand your concern of not allowing direct access to the > shell surface. It was an error on my side. I just disabled the call to > "ivi_layout_surface_set_Visibility" in the demo code ( > https://github.com/Tarnyko/weston-ivi-shell/commit/1e121f1e1a55553b6e1aa9afc7f73f06f774270a) > so people do not get confused by this. > Best regarrds, > > 2014-09-15 2:29 GMT+02:00 Tanibata, Nobuhiko (ADITJ/SWG) < > [email protected]>: > Hi Manual-san, Tom-san, Janos-san and Dominig-san, > > Motivation of IVI-shell(ivi-application+ivi-layout internal > apis)+ivi-controller is to fit requirement and use case in automotive, > GENIVI. > So if a proposal can cover it, I think there is no concerning from > GENIVI. > Use case > - Layer/surface can be identified by Numeric ID. In automotive, it shall > be under stringently control by e.g. car maker to avoid malware. > - ivi-controller interface shall be bound by only authorized central > controller. Ivi-application protocol and ivi-controller protocol shall > be divided into two. > I think the second is a little mentioned by Janos-san feedback. > > So my proposal if I take account into Manual-san suggestion. > - If xdg-shell support, I would be great to merge them into one. > - ivi-application.surface_create(ivi_id,surface) to map ID with > wl_surface > - allow to load ivi-layout module to add ivi-features. > - security model not to allow client application to use a part of > xdg-shell protocol; interface to control e.g. position/size like > xdg_surface_set_minimized. > - In the future, ivi-controller shall be bound by only authorized > manager like murphy or else. This is one of suggestion from Intel > graphic engineer you may know. > > Another option is the same as Janos-san, > If community allows us to support multiple shell in one compositor and > xdg-shell became standard shell in Weston, I can support fall back > feature to xdg_shell when client doesn't support ivi-application. In > this case, get_xdg_surface and other main protocol can be supported. But > other interface to control position or resize of the shell surface shall > not be supported because of security reason e.g. application can control > them by itself. > > BR, > Nobuhiko Tanibata > > > -----Original Message----- > > From: IVI [mailto:[email protected]] On Behalf Of Counihan, > Tom > > Sent: Saturday, September 13, 2014 1:06 AM > > To: Dominig ar Foll (Intel OTC); [email protected] > > Subject: RE: [RFC] IVI-Shell, Wayland, and middleware API unification > > > > Hi Dominig, > > > > > -----Original Message----- > > > From: IVI [mailto:[email protected]] On Behalf Of Dominig > ar > > > Foll (Intel OTC) > > > Sent: Friday, September 12, 2014 2:55 PM > > > To: [email protected] > > > Subject: Re: [RFC] IVI-Shell, Wayland, and middleware API > unification > > > > > > Tom, > > > > > > our motivation in investigating such option is driven by the fact > that > > > the acceptance of the IVI shell by the Wayland/Weston community, in > > > view of its integration upstream, is at best fairly remote at worse > > > unlikely, while XDG has already been adopted by the community and > accepted > > upstream. > > > > The motivation has logic based upon the assumption you describe. > However, > > when observing the wayland traffic, particularly the great work Manuel > and > > Tanibata have been pushing, I came away with a different opinion re > upstream > > acceptance. > > I confess I could be totally wrong, but would gladly take your input > to correct > > my understanding - the "worse unlikely" is a pretty grave scenario. > Can you > > direct me to where you base your opinion on? Did you mean for a > particular > > version, or in general you are skeptical of upstream acceptance? > > > > > > > > > > Manuel proposition would enable to expand the compatibility of > Genivi > > > (IVI-shell) to standard application. > > > The immediate interesting side effect is that tool kit such as Ozone > > > (crosswalk), efl or qt could work out of the box with their XDG > extensions. > > > > I was under the impression that Ozone was receiving some ivi shell > support > > - which would be very useful? Am I wrong? > > > https://github.com/01org/ozone-wayland/commit/a034a018b6ec317ec5559dcce6 > > efec916ec40512 > > > > > > > > I personally only see benefit, but a sorer look from a greater > > > community is valuable as we might have missed some hidden side > effect. > > > > Janos has followed with a compressive reply after this mail. > > > > Warm Regards > > Tom. > > -------------------------------------------------------------- > > Intel Shannon Limited > > Registered in Ireland > > Registered Office: Collinstown Industrial Park, Leixlip, County > Kildare > > Registered Number: 308263 Business address: Dromore House, East Park, > > Shannon, Co. Clare > > > > This e-mail and any attachments may contain confidential material for > the > > sole use of the intended recipient(s). Any review or distribution by > others > > is strictly prohibited. If you are not the intended recipient, please > contact > > the sender and delete all copies. > > > > > > _______________________________________________ > > IVI mailing list > > [email protected] > > https://lists.tizen.org/listinfo/ivi > _______________________________________________ > IVI mailing list > [email protected] > https://lists.tizen.org/listinfo/ivi > > > > -- > Regards, > > Manuel BACHMANN > Tizen Project > VANNES-FR > -- Regards, *Manuel BACHMANN Tizen Project VANNES-FR*
_______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
