Re: Review: FULLSCREEN_MONITORS Hint

[Grant Patterson <grantp vmware com>]

Hi Folks,

I'd like to restart this discussion. We at VMware had some discussions and have 
several ideas for how to specify what the window should cover. Pros and cons are 
my own; you may have more.

1. List all the indices in the data element of the X client message, as in the 
last spec patch I sent out.  If we do byte-sized formatting, that's a maximum of 
18 monitors that can be listed. Seems like enough to me, but maybe I'm not 
forward-thinking enough. Slightly less elegant would be to make the data element 
a bitfield, where each bit corresponds to a monitor that should be included or not.
Pros: We can specify any set of monitors the app can dream up; works with RandR; 
easy for the app to specify; easy for WMs to implement.

2. The window specifies x, y, width, height in the root window and the WM 
complies as much as it wants to. It could just do it (rather dangerous), or 
round the geometry to the nearest monitor boundary, or just ignore if the 
geometry isn't along monitor boundaries.
Pros: Window can just ask for what it wants. Allows for all crazy monitor 
configurations
Cons: Harder for WM to implement, or we introduce a hint that lets a window do 
whatever it wants--glorified override-redirect.

3. Specify top-left and bottom-right monitors and a flag to indicate whether the 
window should also stretch over any monitors overlapped by the bounding box 
created from the lop-left/bottom-right.
Pros: Simple to specify.
Cons: Doesn't cover all crazy monitor configurations; I don't like flags; harder 
for WM to implement

4. Make FULLSCREEN_MONITORS just stretch the window over _all_ monitors and use 
shaped windows to get what the window wants.
Pros: Easy on the WM side; Window does the work of setting its shape properly 
(and that code already exists?).
Cons: Window could cover whatever it wants; Window has to shape itself, which is 
annoying code to write for each app.


Preferences? I'm still leaning towards 1--it makes it easy to put a window on 
any combination of monitors, but not give it any arbitrary shape. It's pretty 
easy for both the app and the WM to implement.


grant


Havoc Pennington wrote:
> Hi,
>
> I don't think the pager could set the FULLSCREEN_MONITORS property 
> directly. There can be only one client (app or WM) able to modify a 
> property at a time, IMO. If we want pagers to be able to change this, we 
> should use the client message, or it's just asking for race conditions 
> and even infinite loops.
>
> Look at the _NET_WM_NAME example as you mention. _NET_WM_NAME is defined 
> as what the _app_ requested, so any non-app client changing it is just 
> wrong. In fact, we have a property _NET_WM_VISIBLE_NAME for exactly this 
> reason, because we distinguish the state (_NET_WM_VISIBLE_NAME) from the 
> app's request (_NET_WM_NAME). We had to add VISIBLE_NAME because people 
> end up wanting to know not only what was requested, but what the WM did.
>
> Geometry is not a full substitute because it's a separate state from 
> FULLSCREEN_MONITORS, much as STATE_FULLSCREEN itself (or maximized or 
> minimized) are separate states from geometry (even though they affect 
> geometry).
>
> An example of why it's a separate state is that a FULLSCREEN_MONITORS 
> state exists even when the window is not in fact fullscreen. If for 
> example I had a FULLSCREEN_MONITORS UI in the pager, it would be 
> legitimate to allow setting the FULLSCREEN_MONITORS for a movie app, 
> even when that app was not in fullscreen mode at the time. And to have a 
> UI I need to know the current state.
>
> In theory, a WM could also use a 
> not-exactly-the-same-size-as-the-monitor geometry for a fullscreen app. 
> For example I think it would be legitimate to have some kind of border 
> or toolbar even in fullscreen mode, if a WM really felt like it, or 
> legitimate to honor the size increment (grid) hints of something like a 
> terminal app even in fullscreen mode.
>
> As you say the app (or pager) should always adapt to the geometry it 
> gets, but that is for geometry-related matters. For any app or pager UI 
> that displayed or allowed you to edit FULLSCREEN_MONITORS, it would be 
> wrong to use the geometry; instead, the FULLSCREEN_MONITORS values 
> should be used, since that state will exist even when the geometry does 
> not match it, due to e.g. not being in fullscreen state, or just some 
> strange WM policy.
>
> The request+state-property approach is a superset of a just-a-property 
> approach that allows several additional things to work right, if those 
> things ever come up. That makes it more future-safe. It seems to have 
> little downside to do things in a more future-safe way.
>
> If we don't do request+state-property, then down the line we might end 
> up adding the equivalent of _NET_WM_VISIBLE_NAME, something like 
> _NET_WM_ACTUAL_FULLSCREEN_MONITORS.
>
> Havoc
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list