[IDEA] Support several fullscreen behaviors - potentially rename 'fullscreen'

[Jasper St. Pierre]

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 <coroutines at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



-- 
  Jasper