The first thing I thought about with full-window is how, in fullscreen mode, Firefox puts up a status bar when you put your mouse to the top of the window, assuming there's a screen edge there.
You are totally allowed to lie -- and that doesn't really need to be "proposed" at all -- you just have to write a compositor to let you do that. But you have to be prepared to deal with the consequences -- applications may rely on assumed behavior or placement. On Tue, Dec 22, 2015 at 4:43 AM, Coroutines <corouti...@gmail.com> wrote: > # Summary > > Wayland compositors like weston have the freedom to display > 'fullscreen'-selected content in 3 ways (that I can think of): > > - full-window > - fullscreen > - multi-display fullscreen > > # The Problem > > Something that I've always wanted to have control over is how an > application is shown in in its fullscreen state. Typically when I'm > watching a video on youtube in a web browser I want the player to > instead fill the existing window dimensions and not the screen. In > this example I am looking for full-window behavior. I can of course > propose this to Google's devs, but I'd have to do this for every app > where I want full-window. I'd much rather have a wayland compositor > that gives me this ability to 'abuse' the fullscreen state. > > # What I propose: > > The compositor has the freedom with xdg-shell to "lie" to the client > about the geometry of the screen in the configure event, when a > surface sets itself as fullscreen. > > In this way, the compositor can show the surface in 3 modes that give > the user more choice/convenience: > > - fullscreen (traditional) > - full-window (same size, placed at the same x, y) > - multi-display "fullscreen" (think Far Cry playing across 3 displays) > > I also imagined the compositor would have options for dimming the > areas between fullscreen clients (think theater-mode). Or immediately > turn off all other displays ~ > > # Why abuse fullscreen? > > 1) It seems perfectly legal per xdg-shell with no bad side-effects. > > 2) I was thinking about something said over and over in #wayland, that > xdg-shell is not about providing mechanisms/primitive operations like > X. It's about providing requests for clients to convey intent. In my > opinion, the intent of fullscreen behavior is to enlarge and focus > content. To display specific content from a window in a way that the > user will not be distracted by other apps and activities they're > doing. > > If I want to convey "intent" I'm bringing *select* content to the > forefront of what the user has open on screen. > > In my opinion, the user should be the one choosing how large this > selected content appears and where - and if other clients are still > visible. > > I avoided calling this 'focused' content, if not 'fullscreen'. I was > thinking maybe it could be called a 'forefront' or 'foreground' state > - or even just 'closer'. From a protocol perspective, if wayland > compositors were to support this greater level of control over the > fullscreen state, I think it should be renamed in the future. > > Anyway, I just wanted to write about this and put the idea in the > heads of people shaping our future desktop experience on Linux. If > you work on mutter or kde plasma, or shape xdg-shell's mechanics... > This is something we can't do on Mac/Windows (across all clients), and > imo it'd be pretty cool. :> I personally wish I were prompted by the > compositor to confirm which fullscreen mode I want a client to conform > to, but others might want a default of the 3 modes ~ > > Thanks for reading ~ > > Disclaimer?: I don't expect anyone to do anything for me. I think I > come up with original ideas so I'm simply trying to share it. > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel