Re: [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  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

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

[Coroutines]

# 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