Test xdg-popup vs xdg-toplevel
Description
Environment
relates to
Activity
Walt Miner July 10, 2020 at 3:14 PM
Close for JJ RC1
Marius Vlad May 13, 2020 at 10:54 PM
Series merged.
Marius Vlad April 27, 2020 at 9:43 AM
Added for tracking input focus stuff and this task will be only for the pop-up side of things.
As a minor update, found some minor glitches with the activation/de-activation of the pop-ups and submitted
version 2 for it.
Marius Vlad April 20, 2020 at 10:58 AM
So I've "kept" that passing of data using notifications events sent when application roles changes. I think that this these could be helpful when having that split roles/fullscreen added.
So the notification can carry out additional data which are set when activating the application, but also when the application state changes, like transitional states between split a fullscreen or something like that. The implementation is not fully, but it is servers the purpose and I plan on adding some further policy hooks to avoid any misuse.
As it stands now the input will not be affected by the pop-up (obviously the input region of the pop-up will receive focus when clicked touched) but the same will have with the background application. For the moment this will probably be the same, and I'll probably branch out into a new Jira Task.
Marius Vlad April 13, 2020 at 4:33 PM
You might be aware I've extended the agl-shell-desktop protocol as to allow setting additional roles to windows. With it surfaces can behave like floating pop-ups and can be positioned independently.
I'm going over the onscreenapp/onstestapp and I've noticed a couple of things that I'd like to clarify a bit better:
The first one is about input regions, specifically about active input regions. Once the pop-up is activate will the underneath surface still have/receiving input? Should it not? Should this be decided by the policy engine (and implicitly have some kind of policy hook in the API to verify it).
The second one is about passing data between windows. onstestapp will handle over a JSON to onscreenapp which will display it on the screen. That data passing is done using libhomescreen service, specifically using int LibHomeScreen::showWindow(const char* application_id, json_object* json). For now I've faked this event straight in onscreenapp, but I'm trying to figure what would be the best place to hang off this information. Should we add this out-this-band information using the compositor? If we go with this direction, this kind of surfaces (with the pop-up role) will need to use wayland protocol and bind to a interface that will handle that information off. There's no other way to get the data on the receiving end. Should we instead assume there's a proxy kind of daemon that does this instead?
what is your take on these?
Placeholder task for testing out xdg-popups and to see if there's a special need for handling them.