[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.

[Jason Ekstrand]

On Thu, Oct 31, 2013 at 3:37 PM, Bill Spitzak <spitzak at gmail.com> wrote:

> Jason Ekstrand wrote:
>
>  Yes, in theory they could read the configuration of the compositor.
>>
>
>  I really don't want to build this kind of inconsistency into the system
>> and I don't see why it's justified.
>>
>
> I think I see what you are getting at. I think a scheme that allows simple
> applications to obey the global setting without thinking, but still allows
> applications that have a good reason to do tricks with the focus, and also
> matches the raise proposal, is this:
>
> - The compositor sends an "I want you to activate" event, as you propose.
> - The client can respond to this with an "activate" request. Or it could
> send an "activate" request at other times if it wants.
> - The compositor responds to the "activate" request by either ignoring it
> or actually doing the activation.
> - The compositor sends an "activated" event that the client can respond to
> by redrawing to show the fact that they are activated.
>
> If a client just echoes the "I want you to activate" event then it will
> work as you expect. A client could also wait after the event until the
> mouse enters a correct location or clicks on the right thing. It could also
> try to generate spurious activates but the compositor may ignore them.
>
>
I still don't understand why a client would want to not activate.  I can
see not wanting to raise, but why not activate?


>
>      I agree with you here, we have that exactly same use case in EFL. Not
>>     being able to set where the transient surface will be is going to
>>     prevent us to implement that behavior. Unless some other kind of
>>     surface should be used for this purpose.
>>
>> One thing worth noting here is that the client doesn't know where the
>> window is, so it can't always properly place these transient windows (in
>> the case of toolboxes).
>>
>
> The location of transient windows is *relative* to the parent's transform,
> not absolute.
>
> There are already proposed and implemented apis to discover if a rectangle
> in the parent's space is clipped by output edges and panels, so a client
> can choose a different rectangle.


See below for an idea on how to make this happen.


>
>
>  I know, Bill, that you have advocated many times in the past that the
>> compositor give the client the full transformation matrix of the window at
>> all times.  However I don't think this is going to happen.  It wasn't my
>> decision.
>>
>
> Yea I give up on this as well, and relative transforms of transient
> windows avoids this problem for now.
>
>
>  Now, concerning other pop-up type things such as tooltips, speech
>> bubbles, arrows, etc.  Perhaps they aren't the same as a standard transient
>> window.  I would want a toolbox to not show up in a task bar (not toplevel)
>> but to also move independent of its parent.  Perhaps there is another
>> category in here.  Maybe we want four types: toplevel, transient (toolboxes
>> etc.), tooltip (position relative to parent), and popup (tooltip + grab
>> semantics).  It would be good to talk to Giulio Camuffo about this as he
>> spent quite some time banging his head on menus in Qt.
>>
>
> I think this will have to be a bunch of flags or you will end up with 2^N
> different window types. Flags I can see:
>
> - Locked transform (whether the window moves when the parent does)
> - Show in task bar (I'm not convinced this is ever wanted)
>

Why not?  Maybe we're missing each other on this one.  By "show in task
bar" I don't mean as a tray icon.  I mean that it's toplevel and it shows
up as an independently user-activateble window.  In windows, this means it
has a button in the task bar.  In gnome shell, it shows up in the list of
windows when you right-click a dock icon.  In KDE it shows up in whatever
they call their task bar.  However, I think this is covered by toplevel
(which I think we should keep.)


> - Show in thumbnail (may be same as locked transform?)
> - Whether it is a subsurface, or a window, or a window above the panels.
> - Clipped to parent (this has been requested a bunch and may be necessary
> if client cannot absolutely control the location).
> - Grab
>

You raise a good point here.  There is a real possibility that we will end
up with too many different window types.  It does seem somewhat reasonable
to have "toplevel" and "transient" and let grab symantics, parent position
locking, etc. be flags.  We already have a bunch of flags for toplevel
windows such as maximize/fullscreen, etc.

*if* we decide to go with flags, I would recommend a set_relative_position
request and an unset_relative_position.  Attaching a buffer with a non-zero
x and y would change the position but otherwise leave the lock intact.  The
xdg_shell.move request or anything similar would automatically release the
lock.  Does this seem reasonable?  Another option would be to just set it
at (0, 0) relative to the parent and use the next buffer attach to
determine the position.

All this being said, I don't think it's a stopper.  As I discussed with
Rafael on IRC, as long as we remove the position arguments from
set_transient, we can always add these flags later.  So I don't think this
needs to get solved before he starts implementing.


>
> The current grab I don't like. It seems that the surface is always
> unmapped on a click outside it. Also there is an entire somewhat parallel
> grab mechanism for normal surfaces. I am pretty certain this can and should
> all be merged. A popup transient would be a normal transient except the
> client also grabs the pointer. Losing the grab would work like Windows (if
> press + release are both outside the grab surface then the grab is
> cancelled after the release is delivered to the client).
>
>
I'm not 100% familiar with all the issues here.  I'll look into it more.


>
>  I do think we want some sort of a tree.  I think it's reasonable to make
>> the toplevel windows roots (no parent) and make all the other little window
>> types (popup, transient, tooltip) take a parent parameter which does not
>> have to be toplevel.
>>
>
> This sounds identical to what I want.
>
>
>  However, I would also like there to be some sort of "commit" operation
>>  so it can be don atomically.  One idea would be to simply make that commit
>> operation the same as the raise.
>>
>
> As I see it, the client can change the tree all they want with no visible
> effect (even though the current stacking may be "wrong"). The only thing
> the tree does is that when a raise happens, it also atomically raises all
> child surfaces along with it. Thus the raise acts as the "commit".
>

Yup, I think we agree on both of the above two.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131031/db9b75b9/attachment-0001.html>