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

Re: screen/display switching

On Mon, 2003-03-17 at 19:03, Owen Taylor wrote: 
>  - Never hurts to include a timestamp (for the current
>    server/display)

Any particular reason why?

Anyway, after reading your comments, I think using a window property and
passing the property atom in a client message is a fine idea.  So, the 
toolkit would then get the property, which would just be a string of
key/value pairs.  We could have the following keys:

HOST:  host to move the window too, assume current host if absent.

DISPLAY: display number to move to.  If absent, assume 0 if moving a
window to another host, otherwise use the current value.

SCREEN: screen number to move to.  Same assumptions as DISPLAY.

MOVEAPP: if present, move the entire application, not just the target

One of HOST, DISPLAY, SCREEN would be required.

So, the equivalent of "foo.com:0.1" would be:
HOST="foo.com" SCREEN="1"

Regarding transients, I agree that a rule of "always keep transients and
parent windows together" is a good policy.  So window managers should
not attempt to move transients separately, and it's up to the toolkit to
make sure they stay together.

I'm unsure whether or not we should include the error-handling stuff. 
If we can get away with letting the toolkit popup error messages, I
would rather do that.


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