Hi Marius,
my 2c worth
- support for hybrid cases like CarPlay or Android Auto
Absolutely we're already building for CarPlay using flutter so this would be very warmly welcomed.
As for Android - Auto/Automotive we would not build on our own dime as it doesn't support Carplay
On a side note I regularly get questionnaires from Android and Flutter dev teams and I fill it out just to reiterate my perspective on autos
(Android) - Would you consider building automotive apps using Android Auto/Automotive
No android native is not cross platform
(Android) Kotlin is cross platform. Would you consider swapping to kotlin
No, why would I when there are other good cross platform products including your own "flutter"
(Flutter) - If there were 3 things you'd like the flutter team to consider what they would be,
extend Flutter for Auto/Automotive
extend Flutter for Auto/Automotive
extend flutter for Auto/Automotive
3 1/2 - Provide a solution for the “1P Linux GTK Plugins” issue
As soon as you "open the CarPlay and Automotive door", you're inviting the App and Play stores; this changes the dynamics forever.
As an app developer I welcome this as it takes a lot of worry off my shoulders as they manage rollout / distribution of my app completely - I just ensure I'm building to whatever new mobile app policy requirements they and OEMS come up with "that which constitutes a well architected and secure auto app".
But for apps like mine that hope to monitise based solely upon what the IC / Dashboard is relaying back from the vehicle, who is my master?
yes to following
- arbitrary positioning and z-order of windows/applications
- some kind of panel expansion happening automatically if they do
not match the entire width
- animations for the panels; presumably user-controllable
- support multiple-touch gestures for panels (3 finger swipe)
- some kind of panel expansion happening automatically if they do
not match the entire width
- animations for the panels; presumably user-controllable
- support multiple-touch gestures for panels (3 finger swipe)
On Tue, Oct 18, 2022 at 9:36 PM Marius Vlad <marius.vlad@xxxxxxxxxxxxx> wrote:
Hello all,
A while back, in the IVI PR call we had an open discussion about
potential improvements and features we could add to the AGL compositor
[1] as to make it more appealing to OEMs and other Tier participants in
the AGL project.
This week, at the AGL F2F Meeting, we've lunched this topic again and
we've further decided to extend this request for comments to gather more
feedback over the mailing list on the matter.
The idea is to figure out what kind of features are useful to have in
the AGL compositor, what features you've been using and you believe
you'd require to have in the AGL compositor.
So with that in mind, feel free to comment, bring in examples,
potential use-cases that need to handled in the AGL compositor so we can
translate those into actionable development plans. We'd like to use this
occasion to try to engage as many people as possible, and keep this
discussions always open.
For example, some of suggestions we have gathered so far, mostly from Joel
Winarske mentioned back then were the following:
- support for hybrid cases like CarPlay or Android Auto as well as
supporting native IVI.
- a rules based engine
- arbitrary positioning and z-order of windows/applications
- some kind of panel expansion happening automatically if they do
not match the entire width
- animations for the panels; presumably user-controllable
- support multiple-touch gestures for panels (3 finger swipe)
Some of these are, in some form, already present in the compositor but
their usage is fairly limited, having either literally no users, or
being used sporadically. So I suppose here we might actually need demos
and some further specific use-cases to exercise those code paths and
to verify how much of these are actually useful or need feature
improvements.
For instance we have support for integrating with a rule based engine in
the compositor [2], support for arbitrary positioning and activation using a
private extension [3], with a design plan to switch to
using another channel of communication (gRPC) for manipulation and
management of windows and their properties [4].
ivi-shell [5] and wayland-ivi-extension [6] has been a predominant part
of IVI, and some of it is still is, but contributions to maintain it and
improving it has been for some years quite low. The most important
change upstream has seen in a while is to be able to use xdg-shell
clients applications to run on ivi-shell. All toolkits implement the
xdg-shell underneath so that's the de facto window management protocol
in use.
Nevertheless the ability to perform additional management of windows --
the arbitrary positioning and z-order of windows/applications item list,
mentioned already above, is exposed in some form when using the AGL
compositor, with some plans in-flight to further improve the way
this works in terms of client API but also internally, in the
compositor.
The follow-up from this would be what other features from the
ivi-shell/wayland-ivi-extension would be good to have -- or maybe a
requirement -- in the AGL compositor? Uses-cases or examples would be a
good candidate to try to understand what are the bits missing and are
useful for people developing IVI systems.
[1] https://docs.automotivelinux.org/en/needlefish/#5_Component_Documentation/1_agl-compositor/
[2] https://docs.automotivelinux.org/en/needlefish/#5_Component_Documentation/3_rba/
[3] https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/agl-compositor.git;a=blob;f=protocol/agl-shell-desktop.xml;h=e4445bd071f242b229789c68dc71d04ea2eed140;hb=refs/heads/master
[4] https://jira.automotivelinux.org/browse/SPEC-4503
[5] https://gitlab.freedesktop.org/wayland/weston/-/tree/main/ivi-shell
[6] https://github.com/COVESA/wayland-ivi-extension
_._,_._,_
Links:
You receive all messages sent to this group.
View/Reply Online (#10213) | Reply To Group | Reply To Sender | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [list-automotive-discussions82@xxxxxxxxxxx]
_._,_._,_
