El mar., 28 ene. 2020 a las 12:55, Pekka Paalanen (<ppaala...@gmail.com>) escribió: > > On Mon, 27 Jan 2020 16:13:41 +0100 > Guillermo Rodriguez <guillerodriguez....@gmail.com> wrote: > > > Hi, > > > > El lun., 27 ene. 2020 a las 14:21, Pekka Paalanen > > (<ppaala...@gmail.com>) escribió: > > > > > > On Mon, 27 Jan 2020 12:58:13 +0100 > > > Guillermo Rodriguez <guillerodriguez....@gmail.com> wrote: > > > > > > > El lun., 27 ene. 2020 a las 12:53, Pekka Paalanen > > > > (<ppaala...@gmail.com>) escribió: > > > > > > > > > > On Mon, 27 Jan 2020 12:36:27 +0100 > > > > > Guillermo Rodriguez <guillerodriguez....@gmail.com> wrote: > > > > > > > > > > > Thank you for your answer. This is an embedded fullscreen > > > > > > application, so no > > > > > > window management. > > > > > > > > > > Fullscreen is one of the modes where you need to be careful with your > > > > > window size and synchronise correctly to obey the compositor's > > > > > demands. > > > > > > > > Can you elaborate on this? > > > > > > Hi, > > > > > > the xdg-shell extension suite has some rules on when the client must > > > obey compositor constraints and when it is free to pick any window size > > > it wants. > > > > > > I am assuming that you are using the xdg-shell extension suite for > > > window management. If you are using some other extension for window > > > management, that changes things. In any case, you must be using some > > > window management extension, because otherwise the window will not > > > appear on screen. > > > > I'm using wl_shell. > > Ok, the deprecated one. Even wl_shell has > wl_shell_surface.set_fullscreen you could use. I must note though that > the special features of fullscreen method and preferred framerate are > not implemented in Weston. > > If possible, I would recommend migrating to the xdg-shell extension > suite which is maintained both protocol and implementation wise. > > > > > btw I said fullscreen but this is actually a toplevel shell surface > > > > with the same > > > > size as the current video mode (so that it occuppies the whole screen). > > > > > > That is not fullscreen but a floating window with a peculiar size. > > > Position of the window could be anywhere, and does not prevent UI > > > components like desktop panels from displacing it or showing on top of > > > it. > > > > Yes, that's why I clarified that it is not really a fullscreen > > surface, but a toplevel surface with the dimensions of the screen. > > (I know that position of the window is not specified by the protocol, > > but Weston is always placing the surface at 0,0) > > That is an accident you should not rely on. Weston generally uses > random() to position floating windows at the moment, but currently does > attempt to keep the whole window visible. > > > Also this is an embedded system where there are no other components > > such as desktop panels... > > Sure, but you risk it breaking on a Weston update if you don't use the > protocol to ensure you get what you want. > > IIRC the user can use a key-mouse-combination to force-move or rotate > any floating window but not a fullscreen window.
Just tried this but found that fullscreen windows seem to be made fully opaque (black surface behind), which does not work for me. I have two "pseudo full screen" windows, one is stacked on top of the other, and the topmost window needs to have transparent areas. So I guess I will need to stick with a toplevel surface and rely on Weston keeping the whole window visible.. BR, Guillermo Rodriguez Garcia _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
