Application activation area cannot be adjusted without using panels
Description
Environment
Activity
Close for NN 14.0.2
I've left my comments on the original gerrit MR, and I have to admit I've never assumed this to be a case, as the output area used for activation serves multiple reasons.
A follow up from this I'll have to catch up is to see if the background and application z-order is the same and make it so background is always behind the applications, just to be on the safe si
This proves problematic with single window based UI engines/toolkits like Flutter or web engines, as it is resource intensive to spawn multiple engines for the panels and then have to do extra IPC if making them interact in any way is desired.While that is true, toolkits like these underneath only maintain a single surface, while our uses case is to have an always on top surfaces. The change here is a hackish way of faking that, it doesn't solve the original problem. You do not need to have an independent drawing loop for each of your surface, or come up with an IPCs to synchronize correctly. Flutter at this point is far better integrated to support multiple surfaces, but they both lack of a way to supply application data in a way that doesn't look you are writing multiple independent applications – which you do not. Yeah, it is probably rather inefficient to spin-up a flutter instance for each surface, while for WAM you don't even own the underlying window primitive to make use it, but that's what we worked with. Just that is far more easier do to this at our end as we own these components rather than change the entire paradigm in the toolkits.
A more desirable model is to have a single fullscreen background application with the panel(s) statically present (as always present "chrome") and then have other applications surfaces overlayed in a constrained area (i.e. usually what would be the "background" when using panels, but not necessarily always so).Now, I'm wondering now if others doing this type of UIs, actually behave this way or not.
Yeah, it's a bit hackish but in the same this solves our problem far more easier than fixing the toolkits to support multiple surfaces, at the right level, given the amount of man power we have to handle it, this seems like a good change to have.
Details
Details
Assignee
Reporter
Fix versions
Contract ID
Components
Affects versions
Priority
Major
The subject line is perhaps a bit unwieldy, but the general issue is that with the current state of agl-compositor and the agl-shell protocol API it is not possible to control the activation area of applications unless panel surfaces are specified. This is because the activation area is inherently assumed to be the full size of the background surface unless panels are configured, doing so contrains the area based on the panel size(s). This proves problematic with single window based UI engines/toolkits like Flutter or web engines, as it is resource intensive to spawn multiple engines for the panels and then have to do extra IPC if making them interact in any way is desired. A more desirable model is to have a single fullscreen background application with the panel(s) statically present (as always present "chrome") and then have other applications surfaces overlayed in a constrained area (i.e. usually what would be the "background" when using panels, but not necessarily always so).
Based on discussion last week on IRC with @Marius Vlad and on the production IVI EG call, I am opening this and assigning it to myself to cover the prototype that I'm working up to work with the Flutter homescreen. It is likely that Marius may need to take over at some point to productize my proposed change in line with his plans for agl-compositor and the agl-shell protocol.