_NET_MOVE_RESIZE [was wm-spec 1.9f]



----------  Forwarded Message  ----------
              Subject: wm-spec 1.9f
              Date: Thu, 6 Jul 2000 11:11:24 -0500
              From: Sasha_Vasko@osca.state.mo.us


            >
              >Remaining comments:
              >_NET_MOVE_RESIZE still has a PDW comment - "what are the
click
              co-cordinates
              >relative to ?" This needs to be answered. Implementers ?

              Two possible approaches here:

              1)
              Actually when moving/resizing windows what you need is not
acoordinates of
              mouse click, but coordinates difference vector between two
adjucent mouse
              click
              events. For example user clicks in (530, 180) and then
moves mouse into
              (535, 170).
              In that case all you need to know is that difference is
(+5,-10), and you
              can then go about applying it to whatever
corner/hotpoint/grip you want.

              2)
              Otherwise you must have an events that indicates
beginning, and ending
              of move/resize process.
              For example first _NET_WM_MOVERESIZE received by window
manager will not
              cause any actuall moves/resizes - it will put WM into
waiting mode, and it
              will
              wait for following events to do actuall move/resize
relative to the point
              in first event. Accordingly, it will stay in wait mode
untill special
              message
              arrives, signaling that process is complete. It seems to
be a good idea,
              for this last message to have coordinates same as previous
message.

              Approach #2 has advantage that it allows window manager to
change cursor
              when
              it enters move/resize mode, thus indicating user that it
is actually doing
              something. Disadvantage is that it makes protocol more
complicated, and
              there is
              a possibility that client will initiate process, without
correctly
              terminating it
              ( like segfault in the middle ), thus leaving WM in
undefined state.

              Advantage of approach #1 is that the communication
protocol is fault proof
              and is
              much simplier, althou it adds neccessity for client to
provide indication
              to user,
              about  the fact that we are moving/resizing atm.


              Cheers
              Sasha Vasko



  There is a still simpler approach. IIRC _NET_MOVE_RESIZE was designed
to allow clients to initiate a move. Client here I believe intends
mainly "widget set" not any client. Using this a widget set / client
could add a grip to (e.g.) the bottom right corner to enable easier
resizing etc, rather than having to grab the very corner. 

In order to maintain WM consistency the client would not actually handle
the move it would just send this message. The WM could then track the
mouse buttons / pointer movement, and handle it as a WM initiated move.

Perhaps the spec needs additional text to this effect. (Or perhaps I'm
wrong!)

I'm guessing now, but the click coordinates are probably client (i.e.
relative to the top left of the client window), as it's client
initiated. Or does this not make sense from the implementation point of
view ?

Julian




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]